Swiss Government SharePoint Hack Hits 200 Accounts

Switzerland's Federal Office for Information Technology and Communications spent about a week chasing anomalies on its own servers before saying anything publicly. On August 4, 2026, the agency known as BIT confirmed roughly 200 compromised accounts on its on premises SharePoint platform, human users and technical service accounts alike. Its reassurance was that nothing beyond the login credentials appears to have been touched. Read that clause again. The reassuring half and the alarming half are the same words.

Key Takeaways

• Switzerland's Federal Office for Information Technology and Communications disclosed on August 4, 2026 that roughly 200 user and technical accounts on its on premises SharePoint servers were compromised.
• BIT states there is "no indication that any data beyond the compromised login credentials" was accessed, and that no particularly sensitive personal data sits on the platform.
• The intrusion is attributed to SharePoint flaws fixed in Microsoft's July 2026 Patch Tuesday, among them CVE-2026-56164, rated CVSS 9.8 and added to CISA's Known Exploited Vulnerabilities catalog on July 14, 2026.
• CISA warns that attackers exploiting these flaws extract IIS machine keys, letting them forge valid requests and keep access after the patch lands.
• BIT cut SharePoint off from the internet on detection day and is reinstalling the affected servers; the actors remain unidentified.

What Exactly Was Compromised at BIT?

About 200 accounts on BIT's on premises SharePoint servers, split between human users and technical service accounts, with no evidence so far that attackers reached the content those accounts could open.

BIT is not a departmental help desk. It is the shared IT provider for large parts of the Swiss federal administration, which makes an account list held there a cross agency artefact. The Record's reporting on the disclosure notes anomalies surfaced roughly a week before the August 4 statement, with the National Cyber Security Centre and Microsoft involved in the analysis.

The phrase worth pausing on is "technical accounts." Service accounts authenticate machine to machine: backup jobs, integrations, scheduled syncs. Their passwords rotate rarely, they are routinely exempt from multifactor prompts, and their permissions run broader than any employee's. Two hundred credentials is a modest number. Two hundred including service accounts at a national IT provider is not.

Why Do On Premises SharePoint Servers Keep Getting Hit?

Because a self hosted farm faces the public internet, runs on IIS, and inherits every patch delay its operator accumulates, while the cloud version gets fixed centrally before most customers hear about the bug.

July 2026 was a bad month to fall behind in. Microsoft's Patch Tuesday on July 14 covered 569 CVEs, the largest release in company history according to Field Effect's breakdown. Buried in it were SharePoint issues attackers were already chaining. Tenable's FAQ on the exploitation cluster maps it: CVE-2026-32201, spoofing at CVSS 6.5; CVE-2026-45659, remote code execution at 8.8; and CVE-2026-56164, elevation of privilege at 9.8, exploitable remotely without authentication. We covered the middle link when Microsoft's severity call aged badly.

Then comes the part that makes patching insufficient. CISA has observed attackers pulling IIS machine keys off compromised SharePoint hosts. Those keys sign and validate ASP.NET view state, so whoever holds them can forge requests the server accepts as legitimate, long after the hole they entered through is closed. CISA is explicit that rotating keys fixes nothing while the harvesting artefacts remain on disk.

What Can Attackers Do With 200 Government Logins?

Reuse them, which is exactly why a credential only breach is not the mild outcome it sounds like.

In a typical federal deployment, SharePoint keeps no separate password list. It authenticates against the same directory that governs mail, chat, file shares and remote access. A credential harvested from a SharePoint farm is rarely a SharePoint credential. It is an identity, and the server was just the room it happened to be standing in.

Stolen machine keys widen it further. Forged tokens skip the login step, so multifactor prompts never fire because no authentication event occurs, a failure mode familiar to anyone who followed adversary in the middle attacks that hijack Outlook sessions after MFA. BIT reset the affected passwords and pulled SharePoint offline, closing the simplest reuse path. No reset covers the window before detection, and reinstalling entire servers suggests BIT is not confident that window was clean.

What This Means for Government Email

To be precise: BIT reports no indication anything beyond credentials was accessed, and no federal mailbox compromise has been reported. Nothing here says government email was read. What the incident establishes is that working federal logins left the building, and stolen logins are the ordinary route into a mailbox.

That matters because of what federal correspondence holds. Civil servants exchange draft policy, procurement discussions, legal advice, and messages from citizens, journalists and whistleblowers who assumed a government address was safe to write to. None of it needs to sit on a SharePoint site to be exposed by a SharePoint intrusion. It only needs to sit in an inbox reachable by a credential that did. Europe keeps repeating the pattern, from the breach of France's government messaging platform Tchap to the theft of Council of Europe member data.

There is a scale argument nobody is making out loud. Swiss federal IT is centralised, well funded and backed by a national cyber security centre, and it still took a week to characterise this intrusion. Cantonal governments, municipalities and public hospitals run the same stack with a fraction of that capability. If BIT needed a week, operators without a security operations centre should assume they have not finished looking.

What Is Still Unknown

Three things: who did it, how long they were inside, and whether any of the 200 credentials were used before the reset. No threat group has been named, and SecurityWeek's coverage of the CISA advisories describes broad opportunistic exploitation rather than one tidy campaign. Detection is not intrusion either: if these flaws were the entry point, the earliest plausible opening is mid July.

What Defenders Should Do This Week

If you run SharePoint Server on your own hardware, treat the July updates as the start of the work, a point Help Net Security makes about the exploitation wave too.

• Apply the July 2026 updates, then verify build numbers rather than trusting the dashboard.
• Hunt for key harvesting artefacts and web shells before rotating anything; rotating on a host the attacker controls just hands over the new keys.
• Rotate IIS machine keys and restart IIS across the whole farm, not only the server that alerted.
• Enable AMSI integration for SharePoint and set request body scanning to Full.
• Inventory every service account with SharePoint access, rotate its secret, and check whether it also reaches mail or VPN.
• Search authentication logs for successful sessions with no matching sign in event, the signature of a forged token.

The Takeaway

Most coverage will settle on the comforting framing that only credentials were taken. That framing is accurate and backwards. Documents are a snapshot of what an organisation knew on one day; credentials are an ongoing capability, and at a shared federal IT provider they reach far past the server they came from. BIT responded fast and in public, and the swissinfo report records the sequence plainly: detect, disconnect, patch, reinstall. The open question is not what the attackers took. It is what they did with it during the week nobody was watching.