PK Softech Akira Attack: Swiss Pension Data a Vendor Kept Too Long

PK Softech AG, a Swiss supplier of pension administration software, was hit by ransomware in late September 2026, and member data from several pension funds, including the federal fund Publica, left its systems. The regulator opened a formal investigation on 22 October. Members should expect convincing phishing; funds should check what every vendor still holds.

Publica says the stolen records sat in a separate supplier environment, not in its production system. Swiss press reporting says Publica had asked the vendor to delete its legacy data after the 2023 Xplain breach and received written confirmation in January 2026. The data was there anyway. That gap between a signed deletion statement and what is actually on a server is the subject of this post.

We work from Publica's notices and FAQ, the Federal Data Protection and Information Commissioner (FDPIC, in German EDÖB), the Bernese funds' statements, the FDPIC's 2024 Xplain report and the US advisory on Akira. German sources are our translations. PK Softech has not said how the attackers got in, and we do not guess.

What happened

According to Publica, its software supplier told it at the end of September 2026 that it had been the victim of a cyber attack. Publica's FAQ names the supplier: PK Softech AG of Reinach, Basel-Landschaft. Inside IT reports that PK Softech has supplied Publica's pension management application since 2017, under a contract worth CHF 12.6 million covering up to 16 years of licences and services including options, a detail it credits to watson.

Polizei.news, citing the Canton of Bern and the two Bernese funds, says malware was introduced into PK Softech's systems on 29 September and encrypted data. PK Softech said, as quoted by Inside IT, that unknown parties used malware to reach part of its IT infrastructure, and that it disconnected the affected environment, brought in external specialists, informed authorities and filed a criminal complaint. It said it had been fully available to customers again since 2 October.

On 8 October PK Softech notified the FDPIC of a cyber attack and possible data security breaches, according to the FDPIC. The same day Publica emailed members under the subject "Cyber attack on software supplier", saying personal data had presumably leaked. The Office of the Attorney General of Switzerland (Bundesanwaltschaft) opened a criminal investigation.

More funds followed. The Bernische Pensionskasse (BPK) said on 15 October that its supplier now assumed personal data had left the company, and the Bernische Lehrerversicherungskasse (BLVK) confirmed on 16 October, according to Polizei.news. The City of Zurich pension fund (PKZH) and the Migros pension fund also reported breaches, according to finews. On 22 October the FDPIC opened a formal investigation against PK Softech, and Inside IT, summarising Tamedia's research, reported the January 2026 deletion confirmation.

Timeline

swissinfo, writing on 24 October, says the formal investigation was opened "yesterday", which would be 23 October. The FDPIC's own release dates the opening to 22 October and the announcement to 23 October. We follow the FDPIC.

What is still unknown

• How the attackers got in. No initial access vector has been published.
• How many people are affected. Publica gives no number. The "well over 100,000" current and former federal employees figure comes from Tages-Anzeiger, relayed by it-markt, watson and Inside IT. No official figure exists.
• Which fields left for each fund. Published lists say what "could be" affected.
• Why the data was still there. Publica says it is investigating. Inside IT reports PK Softech did not answer, saying it does not comment on individual customer relationships.
• The data volume. Swiss press has quoted a size we could not confirm from an accessible source, so we do not repeat it.

Who is affected

Fund size is context, not an affected count. Publica had about 70,000 insured persons and 41,600 pension recipients at the end of 2025, according to Inside IT and cash.ch. The Canton of Bern gave BPK figures of 42,145 active insured and 18,321 pensioners, and BLVK figures of 21,417 active insured and 10,259 pensioners, as of 31 December 2025. Polizei.news stresses these totals do not say how many people are affected.

The FDPIC says data was taken from "several significant" second pillar funds and names only Publica. Inside IT reports that, per the federal government, Publica is the only federal body with a business relationship with PK Softech. Publica's FAQ says former members may also be affected and that it has written to them. Old data about people who left years ago is exactly what a deletion request is meant to remove.

Technical details

Every value below comes from a source linked at the end.

Where the data sat

• Production. Publica's productive pension system holds members' original data and runs on Publica's own IT infrastructure. Publica says it is not affected and pensions are paid as usual.
• The supplier's environment. Publica's FAQ describes a test environment at PK Softech, separate from Publica's productive system. This is where Publica's exposure sits.

PK Softech drew the same line. cash.ch quotes the company, via the AWP agency, as saying the data left PK Softech's own IT infrastructure, not its customers' systems.

PKZH shows a second route by which production data reaches a vendor: according to finews, it planned to move to PK Softech's administration system at the start of 2027 and had already sent data to prepare that migration. Pensionskasse Post shows the alternative. IPE reports Post says the data PK Softech holds for it is anonymised, and that sensitive data such as disability insurance information is not stored by the provider.

Data fields, by source

The lists differ, and the differences show what changed after 8 October.

BPK and BLVK stress that theft of their data from their own systems has not been shown.

What the Swiss identifiers look like

• OASI or AHV number. A 13 digit number beginning with the country prefix 756, usually written 756.XXXX.XXXX.XX.
• Swiss IBAN. 21 characters, starting with CH and two check digits. Publica's FAQ notes the IBAN alone does not normally give access to e-banking, but extra data makes a fake call more convincing.

Both formats are regular enough to search for, which is how a fund or vendor can test whether "deleted" data still exists. Commands are in the remediation section.

Official channels members can check

Publica warns sender addresses can be faked and suggests logging in directly through its website. BPK sends myBPK registration documents only by regular mail, according to Polizei.news.

The attacker, as named by authorities

Inside IT reports, citing Tamedia, that the Office of the Attorney General confirmed the data was taken by the ransomware group Akira, which threatens to publish or sell it. it-markt, citing Tages-Anzeiger, reports a ransom demand and says the authorities advised against paying. Publica's messages to members do not mention Akira or a ransom.

PK Softech's initial access vector is not public. The table below is general background from CISA advisory AA24-109A on Akira, first published 18 April 2024 and updated 13 November 2025. It describes Akira activity elsewhere, not this incident.

CISA warns against treating legitimate admin tools as malicious without evidence of attacker use, and publishes the indicator files in STIX format on the advisory page.

What the regulator is examining

The FDPIC says its formal investigation targets suspected breaches of data protection rules by PK Softech and will establish:

1. A full picture of the personal data the affected funds gave the software company.
2. The legal framework for those transfers and how they were actually carried out.
3. The extent of the information taken.

It says it cannot give further information on pending proceedings.

The deletion confirmation that did not hold

This point comes from press reporting, so we attribute it carefully.

According to Inside IT, summarising Tamedia's research, Publica asked PK Softech to delete all legacy data, including the 2019 migration data, and linked the request to the Xplain case. In January 2026 PK Softech confirmed in writing that it held no personal data in plaintext and had deleted the 2019 data. Publica told Tamedia: "Die Löschung wurde uns schriftlich bestätigt", meaning the deletion was confirmed to it in writing. According to the same reporting, personal data was nevertheless still on the servers, and Publica is investigating why. 20 Minuten carried the same account, also based on Tages-Anzeiger.

Nobody has said publicly why the data survived; that is for the FDPIC and Publica's review. But the general ways deleted data survives are familiar to anyone who has run a database:

• Copies outside the primary store: migration dumps, exports on a file share, a restored copy for a bug hunt, a developer's local database.
• Backups and snapshots: deleting rows does not touch last month's backup or a VM snapshot.
• Versioned object storage: old versions stay until they expire or are removed.
• Test and staging environments: often seeded from production and refreshed irregularly.
• Scope mismatch: "no plaintext personal data" can be true of one schema and untrue of a migration archive.

A signed statement tells you what someone believes. It does not tell you what is on disk.

This is the second story this month about a vendor holding data a customer thought was gone. Our post on the Trezor and ShipMonk breach covers a similar pattern.

Xplain, three years earlier

Publica itself made the Xplain comparison, according to Inside IT.

Xplain AG, a software supplier to Swiss police, customs and justice bodies, was hit by ransomware in May 2023, and federal data on its systems was later published. The FDPIC opened three investigations in the second half of 2023. Its final report on Xplain, dated 25 April 2024, reads differently in October 2026:

• Production data in a vendor's reference installation. The customs office told the FDPIC that development generally used test data, but some systems also held production data in their integration environment, and for one system production data sat in Xplain's reference installation.
• Contracts already demanded deletion and confirmation. The fedpol contracts quoted in the report required data to be physically deleted from Xplain's systems immediately after return, with written confirmation sent without being asked, and incidents reported within 24 hours.
• The findings. Xplain lacked adequate technical and organisational measures for support and development, had not implemented contractual security requirements, and kept personal data after the fault was fixed instead of deleting it. It informed the federal administration ten days after the incident despite the 24 hour deadline.
• The recommendations. Measures under Article 8 of the revised Federal Act on Data Protection (FADP), an ISMS with certification, risk management, staff awareness, regular audits, building contractual duties into its own processes and, tenth, a deletion concept meeting legal and contractual requirements. The report also cites a National Cyber Security Centre measures plan calling for an inventory and lifecycle management of client data and a deletion procedure for test data after use.

On 4 June 2024 the FDPIC announced that Xplain, fedpol and the customs office had accepted all recommendations, and asked the federal administration and its private processors to review how they work together.

The 2024 lesson was that a written deletion duty, even one requiring unprompted confirmation, does not make data disappear. Whether PK Softech's case shares the same causes is for the current investigation. The pattern of production data in a supplier environment, kept beyond its purpose, is already visible in what Publica and the press have said.

Why production data ends up at software vendors

Pension software encodes contribution rules, conversion rates, vested benefits, divorce splits and home ownership withdrawals. Vendors and funds have honest reasons to want real data: migrating a fund's full history, proving a new release calculates every edge case the same, reproducing a member's wrong statement, and load testing at full size. Each reason is legitimate for a while. The risk comes when the copy outlives the reason, nobody owns the list of copies, and the vendor environment is protected like a development network rather than a system holding salaries, social security numbers and bank details.

Masked or synthetic data removes most of the need. It has to keep referential integrity, keep the shape of salaries and ages so calculations follow the same paths, and be irreversible. Pensionskasse Post's statement that its data at PK Softech is anonymised shows this is achievable in this sector.

The regulatory frame in Switzerland

The revised FADP has applied since 1 September 2023; the FDPIC's Xplain report notes its conclusions would be the same under it. That report ties the vendor's duties to Article 9 on processing by processors and Article 8 on data security. Controllers must report serious breaches to the FDPIC, and here the FDPIC says PK Softech notified it on 8 October and other funds reported later. The current formal investigation is directed at PK Softech; the 14 October inquiry at Publica was informal and preliminary, per the FDPIC. Fund boards also answer to their supervisory authorities for how they choose and oversee suppliers.

What pension members should do now

If you are or were insured with a fund that uses PK Softech, assume someone may hold your name, birth date, AHV number, address, salary and possibly IBAN.

1. A caller who knows your salary is not proof they work for your fund. Hang up and call the number on your fund's website or annual statement.
2. Never confirm or change bank details on request. Publica pays pensions only to an account in the member's name and at their address. Polizei.news lists "your pension is blocked, move it to a new account" as a common scam pattern.
3. Type portal addresses yourself instead of clicking login links.
4. Refuse investment pitches by phone. Cantonal police in Zurich and Bern warned of misuse of the stolen data, according to it-markt, and a caller offering better returns on your pension money fits that risk.
5. Turn on two factor authentication for email, e-banking and pension portals.
6. Check statements and report unfamiliar transactions to your bank, then the police.
7. Tell your partner. Publica does not plan to inform spouses or partners whose details may be in the data.
8. Report suspicious messages voluntarily to Switzerland's National Cyber Security Centre, now the Federal Office for Cybersecurity.

What pension funds should do now

These steps suit any fund that hands member data to a software vendor, administrator, actuary or consultant. They assume nothing about PK Softech's systems.

1. Build the list of who holds your data

One row per supplier and environment (production, test, migration, support, backup): what data, legal basis and contract clause, date received, retention end date, and who at the supplier owns deletion. An empty cell is your first finding. The FDPIC's first question to PK Softech is essentially this table.

2. Ask for deletion evidence, not a deletion letter

Ask the supplier for every environment and storage location where your data was ever loaded, including backups and snapshots; the date, method and owner of each deletion; backup retention, so you know when the last copy ages out; log or ticket evidence; and confirmation that no key or lookup table could reverse masked data.

3. Check for real identifiers in non-production data

Run these on your own systems and ask suppliers to run them. They count matches and never print values.

Find identifier columns in PostgreSQL:

SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE column_name ILIKE ANY (ARRAY['%ahv%', '%avs%', '%ssn%', '%iban%', '%versicherten%', '%sozial%'])
ORDER BY 1, 2, 3;

In SQL Server:

SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE COLUMN_NAME LIKE '%ahv%' OR COLUMN_NAME LIKE '%avs%'
   OR COLUMN_NAME LIKE '%iban%' OR COLUMN_NAME LIKE '%sozial%'
ORDER BY 1, 2, 3;

Count real looking values in a test column. Masked data should return zero:

-- PostgreSQL: count, never select the values
SELECT
  count(*) FILTER (WHERE ahv_nr ~ '^756\.?[0-9]{4}\.?[0-9]{4}\.?[0-9]{2}$') AS real_looking_ahv,
  count(*) FILTER (WHERE iban ~ '^CH[0-9]{2}') AS swiss_iban
FROM test_schema.versicherte;

Scan export and migration folders, listing only file names and counts:

# Linux or macOS, with ripgrep installed
rg --count-matches '756[. ]?[0-9]{4}[. ]?[0-9]{4}[. ]?[0-9]{2}' /srv/exports /srv/migration
rg --count-matches 'CH[0-9]{2} ?[0-9]{4} ?[0-9]' /srv/exports /srv/migration

# Windows file share: file names and match counts only
Get-ChildItem -Path \\fileserver\exports -Recurse -File -Include *.csv,*.txt,*.xml,*.sql |
  ForEach-Object {
    $n = (Select-String -Path $_.FullName -Pattern '756\.?\d{4}\.?\d{4}\.?\d{2}' -AllMatches).Matches.Count
    if ($n -gt 0) { [pscustomobject]@{ File = $_.FullName; Matches = $n } }
  }

4. Look where deleted data survives

# AWS: snapshots you own, and old object versions in a bucket
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[].[SnapshotId,StartTime,Description]' --output table
aws rds describe-db-snapshots --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime]' --output table
aws s3api list-object-versions --bucket migration-archive --prefix 2019/ --query 'Versions[].[Key,VersionId,LastModified]' --output table

# Azure: managed disk snapshots
az snapshot list --query '[].{name:name, created:timeCreated}' --output table

# VMware PowerCLI: snapshots on all VMs
# Get-VM | Get-Snapshot | Select-Object VM, Name, Created

If a snapshot or object version from a migration that should be gone turns up, record it, involve your data protection officer, and delete it under change control so the deletion itself is evidenced.

5. Ask suppliers about Akira-style exposure

Because authorities have named Akira, ask every supplier holding member data the questions AA24-109A raises: is MFA enforced on every VPN and remote access path; are Cisco ASA or FTD, SonicWall and Veeam Backup and Replication patched for the listed CVEs; are backups offline or immutable with a tested restore; are tools like AnyDesk, RustDesk and Ngrok allowed and logged; and are test and migration environments segmented?

On your own estate, quick checks for indicators CISA lists:

# Windows: Akira ransom notes and encrypted file extensions
Get-ChildItem C:\ -Recurse -Force -ErrorAction SilentlyContinue -Include akira_readme.txt,fn.txt,*.akira,*.akiranew,*.aki,*.powerranges |
  Select-Object FullName, LastWriteTime -First 50

# The admin account name the advisory reports
Get-ADUser -Filter "SamAccountName -eq 'itadm'" -Properties whenCreated

# Remote access and tunnelling tools the advisory lists
Get-Service | Where-Object { $_.Name -match 'AnyDesk|RustDesk|LogMeIn|cloudflared|ngrok' }

# ESXi or Linux hosts: notes and extensions
find / -xdev \( -name 'akira_readme.txt' -o -name 'akiranew.txt' -o -name '*.akira' -o -name '*.akiranew' \) 2>/dev/null | head -50

A tool name match is not proof of compromise; these are legitimate tools.

6. Prepare members before the phishing starts

Publish your sender addresses, subject lines and what you will never ask for, as Publica did, and give your call centre a script for members who report a caller who "knew everything".

What software vendors holding client data should do

If you are the vendor in someone else's supply chain, the FDPIC's Xplain recommendations are close to a checklist:

1. Keep an inventory of client data, per client and environment, with a retention date for each.
2. Default to masked or synthetic data in development, test and support. Where real data is unavoidable, isolate it, time limit it and log access.
3. Treat migration data as production data. It is the most complete copy you will ever hold.
4. Write and test a deletion concept covering primary stores, replicas, backups, snapshots, exports and laptops.
5. Make deletion confirmations specific: systems, copies and backup expiry, not one line.
6. Protect test environments like production when they hold production data.

What changed since first reports

• IBAN appeared. Publica's 8 October newsletter did not list IBAN. Its later FAQ does, as does PKZH's list.
• From "cannot be ruled out" to "assumed". On 9 October the Canton of Bern saw no evidence BPK or BLVK data was stolen. By 15 and 16 October both funds said the supplier assumed data had left.
• More funds. Publica was first; BPK, BLVK, PKZH and the Migros fund followed; Post said its data was anonymised.
• Attribution. Later press reports say the Office of the Attorney General confirmed Akira.
• Inquiry became investigation. An informal inquiry at Publica on 14 October became a formal investigation against PK Softech on 22 October.
• The deletion question was first reported on 22 October.
• An unrelated outage. Publica's website was offline on the afternoon of 21 October after vulnerabilities in a widely used web technology; Publica says this was unrelated.

Open questions

• What was the initial access vector, and how long were the attackers inside?
• Which environment held Publica's data: the 2019 migration set, a later copy, or both?
• What exactly did the January 2026 confirmation cover?
• How many people are affected per fund? Publica says affected individuals will be informed directly.
• Will the FDPIC publish a final report with recommendations, as it did for Xplain?

What would have helped

None of this assigns blame to PK Softech, Publica or any other fund. Publica told members on the day the FDPIC was notified, published sender addresses, filed a criminal complaint and has updated its FAQ repeatedly. The question for everyone else is how to make the same event smaller.

Practices any team can use

• Give vendors only the production data you cannot avoid giving them, and mask the rest.
• Set a deletion date when a copy is created, especially migration data and support extracts.
• Verify deletion with evidence naming systems, copies and backup expiry, and check a sample.
• Keep a per supplier data inventory so the regulator's first question has an answer.
• Contract for it: right to audit, specific deletion clauses with unprompted confirmation, and incident notice within 24 hours.
• Hold vendors that keep your data to production grade controls: MFA on all remote access, patched edge devices, immutable backups, segmentation.
• Rehearse an incident with your suppliers, including member communications.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Gold Open Source (gold.safeguard.sh, free, no login) gives searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API.

The limits are large. The way into PK Softech is not public, and Safeguard has no advisory and no patched build related to this incident. The edge devices and backup products in CISA's Akira advisory are vendor appliances and commercial software, outside the open source package ecosystems Zero-Day Discovery covers; their fixes come from their vendors. These capabilities help in the open source libraries and base images that pension software and portals are built from, where pulling patched, signed components and rebuilding fast removes one common way in. They do nothing about how long a vendor keeps data, the main lesson here.

Where Safeguard fits

Safeguard would not have prevented this incident, and it would not have deleted the data or proved it was deleted. What it covers, at GA:

• The Compliance and GRC suite, with Vendors, Questionnaires, Risks and Evidence tabs. A fund can keep its supplier register there, send a questionnaire with the deletion and retention questions above, and record answers, evidence and open risks per supplier. It records what a supplier tells you; it does not see inside the supplier's systems.
• Dependency and image scanning of your own portal and tools, and of SBOMs a supplier gives you, with JSON results under ./output.
• Component search across projects, showing every project containing a given component and version when an advisory lands.
• Vulnerability matching, reachability analysis, and policies and gates, so a build carrying a known exploited vulnerability can be blocked or held for approval.
• Autonomous remediation with tested fix pull requests, off by default.
• The Safeguard CLI assistant, which edits code and runs commands only with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could ask it to write a masking step for a test data refresh, or a check that fails a pipeline when real looking AHV numbers appear in fixtures.

safeguard scan --dir .                 # a repository
safeguard scan --image <name>          # a container image
safeguard scan --sbom <file>           # an SBOM file from you or a supplier

Where Safeguard does not help: it does not detect ransomware, monitor networks or VPNs, delete data, manage retention, or verify what is stored in a vendor's hosted or test environment.

Common mistakes and troubleshooting

If the schema search finds nothing but you still suspect real data, check free text columns, XML or JSON blobs and attachment tables; identifiers often hide there. On a large share, start with folders named for migrations, exports, support or a year.

FAQ

What is PK Softech?

A software company in Reinach, Basel-Landschaft, that supplies pension administration software to Swiss second pillar funds. Inside IT reports it has supplied Publica since 2017.

Which pension funds are affected?

Publica says members' data presumably leaked. BPK and BLVK say the supplier assumes data left. PKZH says insured persons' data was stolen, and the Migros fund reported a breach. Pensionskasse Post says its data at PK Softech is anonymised. The FDPIC names only Publica.

What data was taken?

Funds list data that could be affected: name, birth date, AHV number, address, phone and email, salary and pension assets, marital status, partner details and, for Publica and PKZH, IBAN. ID document copies are in principle not affected, per Publica.

Are pensions and pension assets safe?

Publica, BPK, BLVK and PKZH say their own systems, assets and payments are not affected. The data came from the supplier's infrastructure.

Who carried out the attack?

According to Inside IT, citing Tamedia, the Office of the Attorney General confirmed the Akira ransomware group took the data. Publica's member messages do not name a group.

How did the attackers get in?

Not published. CISA's Akira advisory lists common entry points such as VPNs without MFA, but that is background, not a finding about PK Softech.

Was the data supposed to have been deleted?

According to Inside IT and 20 Minuten, both based on Tamedia reporting, Publica received written deletion confirmation in January 2026, yet personal data was apparently still on the servers. Publica is investigating why; PK Softech has not commented.

What is the FDPIC investigating?

What personal data the funds gave PK Softech, the legal framework and actual handling of those transfers, and how much was taken.

How is this related to Xplain?

Both involve a Swiss software supplier, ransomware and public sector data in the supplier's environment. Publica linked its deletion request to Xplain, and the FDPIC's 2024 Xplain report found the supplier had kept personal data after the purpose ended.

The way into PK Softech has not been published, and data retention is not a patching problem. But CISA reports that Akira affiliates lean on known vulnerabilities, so closing known holes fast still matters for every fund and vendor that ships its own software.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows PK Softech, Publica or any pension system; each is a real Safeguard session applied here to a fund or vendor team.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. A vendor team could run /scan . in the repository that builds its test data refresh job, then ask the assistant to add a masking step for AHV numbers and IBANs and a test that fails if real looking values appear, approving each edit and command.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A fund's IT team could pick the folder holding its member portal, ask for a vulnerable library to move to its fixed version, and approve or deny every change before it lands.

Click through it at your own pace, or open it full screen.

This session connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. A fund's risk team could connect Claude the same way and ask which of its own projects contain a component named in a new advisory, keeping write tools switched off.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI docs. For related reading, see ransomware at a cloud provider and third party risk, finding affected products fast with SBOMs and October 2026 security incidents and what would have helped.

Quick check

Sources

• Publica: Cyber attack on software supplier, FAQ and dated updates
• Publica: Cyber attack on Publica software supplier, data leak confirmed (8 Oct 2026)
• Publica: Newsletter, Cyber attack on software supplier (8 Oct 2026, PDF)
• FDPIC (EDÖB): Investigation opened after cyber attack on software supplier (23 Oct 2026, German)
• FDPIC (EDÖB): Final report and recommendations in the matter of Xplain AG (25 Apr 2024, German, PDF)
• FDPIC (EDÖB): Xplain, three proceedings closed with all recommendations accepted (4 Jun 2024, German)
• CISA: #StopRansomware: Akira Ransomware, AA24-109A (updated 13 Nov 2025)
• Polizei.news: Cyber attack on pension fund supplier, personal data stolen (18 Oct 2026, German)
• Inside IT: Publica wanted pension fund data deleted (22 Oct 2026, German)
• Inside IT: Data leak at the federal pension fund (8 Oct 2026, German)
• it-markt: Federal pension fund Publica reports data leak (8 Oct 2026, updated, German)
• watson: FDPIC starts formal investigation into PK Softech (23 Oct 2026, German)
• swissinfo: Data protection officer launches investigation (24 Oct 2026)
• 20 Minuten: Data disaster despite deletion confirmation (22 Oct 2026, German)
• finews: Hacker attack on IT service provider widens its reach (16 Oct 2026)
• IPE: Swiss pension funds investigate potential data breach (9 Oct 2026)
• cash.ch: Attack on Publica supplier, salary data could be affected (8 Oct 2026, German)

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.