Swiss Government SharePoint Breach Compromises 200 Federal Accounts

Attackers broke into SharePoint servers operated by Switzerland's federal IT office and stole the login credentials of roughly 200 accounts. The Swiss government disclosed the SharePoint breach on August 4, a week after security specialists first noticed irregular activity. The compromise hit both regular user accounts and technical service accounts.

The Federal Office for Information Technology and Telecommunication, known as BIT, runs the affected servers inside the government's own data centres. Investigators have found no evidence that any data beyond those credentials left the network. Analysis of the SharePoint breach continues inside the Swiss government, and no ransomware or extortion group has claimed responsibility.

How the Swiss Government SharePoint Breach Unfolded

Microsoft disclosed several SharePoint vulnerabilities in mid-July. BIT started installing the security updates on its own systems as soon as they became available. The attackers moved faster.

On Tuesday, July 28, security specialists spotted anomalies on the SharePoint servers. BIT confirmed the intrusion, cut off internet access to the platform, and closed the flaws. Three days later, analysts found that credentials for multiple accounts had already fallen into the attackers' hands. The office reset every affected password immediately.

BIT is now rebuilding the affected servers from scratch rather than returning them to service. External internet access stays blocked until that work finishes. Federal employees can still reach their documents and share them with outside partners through other channels.

The Swiss Government Patched Fast, and the SharePoint Breach Happened Anyway

Nothing disclosed so far suggests BIT was slow to react. The office began patching the moment Microsoft published the updates. Attackers, however, reached the servers first. That gap is the real problem here, and it extends well beyond one federal agency. Enterprise patch cycles take days. Exploitation of internet-facing SharePoint now takes hours.

Four separate SharePoint flaws came under active exploitation during July. In at least one case, working exploit code appeared publicly and attacks followed within hours. US federal agencies received only three days to fix one of them.

Which Vulnerability Attackers Used Remains Unclear

BIT has not named the flaw behind the intrusion. Two candidates from the July 14 update fit the timeline.

The first, tracked as CVE-2026-56164, lets an unauthenticated attacker escalate privileges over the network with no user interaction. Its severity score of 5.3 looks modest. But incident responders discovered it during live attacks, and it joined the US catalogue of known exploited flaws the same day Microsoft patched it. Automated patch queues push a medium-rated flaw behind dozens of critical ones.

The second, CVE-2026-50522, carries a 9.8 rating and stems from unsafe deserialization. Attackers have used it to pull IIS machine keys off compromised servers with a single request. Those keys let an intruder forge valid authentication tokens and impersonate legitimate users long after administrators install the patch.

Investigators cannot rule out a third flaw from the same release. The Swiss government has not attributed the SharePoint breach to any known actor, and analysts are working alongside Microsoft and the Federal Office for Cyber Security.

Why Technical Accounts Matter More Than the Number

Two hundred compromised credentials sounds contained for a national administration. The composition matters more than the count. The Swiss government has not published a split between the two types, but the SharePoint breach reached both.

Technical accounts, meaning the service accounts that applications and automated processes use, carry broad permissions. They rarely sit behind multi-factor authentication. They run unattended, so nobody flags a login at three in the morning. Their passwords change infrequently, and their activity blends into normal system traffic.

BIT says confidential information and particularly sensitive personal data are not permitted on the affected SharePoint platform. That policy caps the damage from document exposure. It does nothing to limit where a compromised service account can travel next.

Turning an Incident Into National Defence

Swiss information security law required the government to report the SharePoint breach quickly. BIT notified the Federal Office for Cyber Security and the State Secretariat for Security Policy inside the deadline. It then went further.

The office pushed every relevant technical indicator from the attack out to Swiss critical infrastructure operators through the national cyber security platform. That choice deserves attention. Organisations under active investigation often hold indicators back while legal and communications teams review the disclosure.

Releasing them early gives every other potential target a chance to hunt for the same activity in their logs. Swiss authorities recorded 28 cyberattacks against the federal administration over the past year. Sharing attack data turns one incident into defensive intelligence for hundreds of other organisations.

What On-Premises Operators Should Do Now

Patching closes the entry point. It does not evict an attacker who already holds credentials or machine keys, so any organisation running SharePoint on its own hardware should assume both.

Rotate ASP.NET machine keys after applying the July updates. Reset passwords across user and service accounts on affected farms. Review IIS and SharePoint logs for unexpected requests, new accounts, and configuration changes that predate the patch.

The Swiss government rebuilt its servers instead of restoring them after the SharePoint breach, and that instinct travels well. Internet-facing SharePoint deserves the same operational urgency as a VPN gateway or a domain controller. Many organisations still treat it as an internal file store that happens to face the web.

A Response Worth Copying

The Swiss government handled the SharePoint breach through a clean sequence: contain, patch, reset, rebuild, and share. Each step limited what the attackers could do with what they already held.

They still got in ahead of a patch that was on its way. Teams running the same software should plan for that gap rather than assume a fast patch cycle closes it.