Switzerland’s Federal Office of Information Technology, Systems and Telecommunication (BIT) — the central IT provider for the Swiss federal administration — has confirmed a breach of its Microsoft SharePoint infrastructure resulting in the compromise of login credentials for approximately 200 accounts.

The timeline:

  • 28 July 2026 — BIT security specialists notice unusual activity on the SharePoint servers.
  • 31 July 2026 — three days later, they determine that login credentials for several accounts had been compromised, affecting both user accounts and technical accounts.
  • Following confirmation, BIT blocked internet access to the platform, closed the exploited vulnerabilities, and reset passwords for all affected accounts.

BIT assesses that the attackers exploited SharePoint vulnerabilities disclosed by Microsoft in mid-July 2026 and fixed in the July Patch Tuesday release — potentially CVE-2026-56164, the actively exploited privilege escalation flaw, or CVE-2026-50522, a remote code execution vulnerability subsequently used to steal SharePoint machine keys and maintain access after servers were patched.

The agency states that no confidential information or particularly sensitive personal data is permitted to be stored on the affected platform, and that there is so far no evidence of data leakage beyond the compromised credentials.

Three elements of this incident generalise, and each is a distinct control failure category.

1. The patch gap that was not a patch failure

The vulnerabilities were disclosed and fixed in mid-July. The intrusion was detected on 28 July. That is a window of roughly two weeks.

By the standards of most patch SLAs, two weeks for a Critical vulnerability is within policy. A 15-day critical patching window — common in government and regulated sectors — would not have been breached. The programme could have been fully compliant with its own documented SLA and still produced this outcome.

We covered the July release when it landed, a record-setting cycle with SharePoint zero-days on the KEV catalog, and the same structural point applies here as in this month’s release: for internet-facing infrastructure with a known-exploited vulnerability, the SLA is the wrong instrument.

SharePoint on-premises is the archetypal asset in this category. It is internet-reachable because collaboration requires it. It holds documents, which is the highest-value target category for exfiltration. It authenticates against the enterprise directory, which makes it a credential harvesting platform. And it has been the subject of a sustained exploitation campaign for over a year.

For an asset with those four properties, “we patch Critical within 15 days” is not a risk statement. The operative question is how many hours elapsed between the vendor advisory and deployment, and whether that number was small enough given that exploitation was already occurring.

2. Machine keys: persistence that survives the patch

The most consequential technical detail is the reference to machine key theft.

SharePoint uses cryptographic machine keys — the ASP.NET validationKey and decryptionKey — to sign and encrypt the __VIEWSTATE payloads that carry page state between client and server. An attacker who obtains those keys can forge valid, signed ViewState payloads, which SharePoint will deserialise and execute.

The security property that makes this severe is that the keys are not invalidated by patching.

Patch the RCE, and the entry point closes. The stolen key still works. The attacker returns through a legitimate, correctly-authenticated code path, submitting payloads the server has every reason to trust, and the vulnerability scanner reports the system as remediated.

This is the same class of problem as a stolen SAML signing certificate or a compromised Kerberos krbtgt hash: the compromise is of a trust anchor, and the only remediation is to rotate the anchor.

Required remediation for any SharePoint server compromised during this campaign:

  1. Patch — necessary but not sufficient.
  2. Rotate machine keys on every affected server, and restart IIS so the new keys take effect. In a farm, keys are shared, so rotation must be farm-wide.
  3. Hunt for pre-existing persistence — web shells in the layouts directories, unexpected .aspx files, scheduled tasks, modified web.config, and unauthorised farm solutions.
  4. Reset credentials for accounts that authenticated to the server during the exposure window, including service accounts.
  5. Only then treat the asset as remediated.

Organisations that ran steps 1 and 5 and skipped 2 through 4 — which is the majority, because patch management tooling reports on step 1 and nothing else — remain compromised while showing as clean.

BIT’s response sequence is notable for getting this broadly right: block internet access first, close the vulnerabilities, then reset credentials. Containment before remediation is the correct order and is frequently inverted under pressure.

3. “No sensitive data is permitted to be stored there” is a policy, not a control

The assurance in BIT’s statement is that no confidential or particularly sensitive personal data is permitted to be stored on the affected platform.

That word carries the entire weight of the reassurance, and it is doing more work than it can bear.

A prohibition on storing sensitive data is a policy. It constrains what users are supposed to do. It becomes a control only when paired with an enforcement or detection mechanism:

  • Data loss prevention scanning of the repository, with quarantine or alerting on classified content.
  • Sensitivity labelling with automatic classification, so that documents carrying protected markings cannot be uploaded or are blocked from the platform.
  • Periodic content audits sampling the repository for policy violations.
  • Technical controls on upload paths, restricting file types or integrating classification checks.

Absent one of those, the accurate statement is “we do not know what is on the platform, and our policy says it should not be anything sensitive.”

Every organisation that has run a DLP scan against a general-purpose collaboration platform for the first time knows how that ends. SharePoint, Teams, and shared drives accumulate exactly the content that policy prohibits, because the alternative to storing a document somewhere convenient is not storing it somewhere correct — it is not doing the work.

For breach assessment purposes this matters enormously. Under GDPR Article 33, and under the Swiss Federal Act on Data Protection (revFADP) which requires notification to the FDPIC as soon as possible where a breach is likely to result in a high risk to the data subject, the notification analysis turns on what data was actually affected. An organisation that cannot enumerate the contents of a compromised repository cannot complete that analysis, and defaults to either notifying on assumption or asserting a negative it cannot evidence.

The action item is simple and unwelcome: scan the platform you just said contains nothing sensitive, before you need the answer.

The technical accounts

One further detail deserves attention: the compromised set included technical accounts as well as user accounts.

Service accounts, application pool identities, and integration accounts are consistently the weakest population in an identity estate. They typically hold elevated permissions, are excluded from MFA because a second factor breaks automation, have passwords that are rarely rotated because rotation risks outages, and are frequently shared across systems.

A SharePoint compromise that yields technical account credentials is therefore not contained to SharePoint. It is a lateral movement enabler into whatever those accounts also authenticate to — which, in a central government IT provider serving many federal offices, is a substantial estate.

The controls, in order of effectiveness:

  1. Managed service accounts with automatic credential rotation, eliminating the stored password entirely.
  2. Per-service credential isolation — one account, one system, so that compromise does not cross boundaries.
  3. Least privilege, actually assessed rather than inherited from an installation guide that recommended domain admin.
  4. Authentication monitoring on service accounts, alerting on source addresses and target systems outside the established pattern. Service accounts have highly predictable behaviour, which makes anomaly detection unusually reliable for them.
  5. Inclusion in the credential rotation scope after any incident touching a system they authenticate to. This is routinely missed because rotating them requires coordination with application owners.

The shared-services concentration point

BIT is the central IT provider for the Swiss federal administration. That structure delivers real efficiency and real standardisation — and it concentrates risk in exactly the way we saw with Ceva Logistics this week in the private sector and with the Romanian land registry earlier this year.

A single SharePoint farm serving many federal offices means one intrusion produces an incident for every office whose data was on it. The individual offices did not select the platform, do not operate it, and depend entirely on BIT’s detection and response — while remaining the accountable parties for the data they placed there.

Shared government IT is a sound model. It requires, as its counterpart, that the consuming departments have contractual or statutory clarity about notification, evidence access, and the data classification limits they are relying on. In practice these arrangements are frequently governed by internal service descriptions rather than by anything with the specificity of a data processing agreement.

The checklist

For any organisation running on-premises SharePoint:

  1. Confirm patch status against the full July and August 2026 releases, not just the most recent.
  2. Rotate machine keys if the server was internet-reachable and unpatched at any point during the exploitation window. Treat this as mandatory, not conditional.
  3. Hunt for persistence independently of patch status — web shells, unexpected ASPX files, modified configuration, unauthorised solutions.
  4. Reset service and technical account credentials that authenticate to or through the platform.
  5. Get the management and authoring surface off the internet. Publish what must be published; do not expose the farm.
  6. Run a content classification scan and find out what is actually stored there.
  7. Confirm your notification analysis is possible — if you could not enumerate affected data today, fix that before an incident forces the question.

Two things follow.

For incident responders: patching an exploited server does not evict an attacker who took a key. Machine keys, signing certificates, and directory secrets are trust anchors, and an incident that touched them is not closed until they are rotated — regardless of what the vulnerability scanner reports.

For compliance functions: a storage policy is not evidence of what is stored. The moment you need to state which data categories a breach affected, the difference between a policy and a scanned inventory becomes the difference between a defensible notification decision and an assertion you cannot support.

This article is provided for informational purposes only and does not constitute legal advice.