TL;DR - On 6 August, the Swiss federal government confirmed a SharePoint breach that touched around 200 accounts. The post-mortem is still landing, but the failure mode is one I have seen in every M365 tenant I have ever audited: permission sprawl, over-broad sharing, and a handful of sites nobody owns anymore. The same shape fits a 20-seat tenant and a 20,000-seat tenant, because the bug is the process, not the product. What you need to do: run the four-step SharePoint permission audit below this week, treat every "Org-wide" or "Everyone except external users" grant as suspect, and reconnect every active site to a real human owner before quarter-end.
If you look after an M365 tenant, this is the week to check your SharePoint. A 60-page PDF is a lot to send your CEO, but the family-version of the same instinct is what my Personal Security Quick-Start Guide is built around. Same idea, smaller blast radius.
Get my Personal Security Quick-Start Guide - the practical handbook for the controls that actually change your day. 193 pages, no jargon.
Plus: Join 158+ Australians getting one 5-minute security briefing every Friday.
Last Tuesday, a SharePoint site I had not looked at in 18 months
Last Tuesday I was on a call with the operations lead at a 65-person accounting firm in Parramatta. We were working through their quarterly M365 tidy-up, the kind of thing that sits below the noise floor until it does not, and I asked her to open SharePoint admin and show me the list of sites that had not been touched in over a year.
The number was 41. Out of 92 active sites.
A handful were genuine archives, tax records going back to 2014, a folder of board packs the new directors had not needed yet, the kind of thing you can argue for keeping with a one-line justification. The rest were something else. There was a project site for a rebrand the firm had rolled out in 2024. There was a client-collaboration site whose last user left in March. There was an HR folder that still had the original link shared to a recruiter's gmail address because the recruiter had moved on and the link had not.
Every one of those sites was also still showing in Entra ID as belonging to the firm, still inheriting whatever conditional access the tenant had set up, and still in scope for the firm's Microsoft Purview data-loss prevention policies. The thing protecting them was the fact that nobody had bothered to look.
I thought about that audit twice this week. On 6 August, the Swiss federal government confirmed a SharePoint breach that touched around 200 accounts. The post-mortem is still landing in the press, and the BleepingComputer report is short on technical detail, but the failure mode is one I have seen in every M365 tenant I have ever walked through: permission sprawl, over-broad sharing, and sites whose nominal owner left the building a long time ago.
The shape of the failure is identical at 20 seats and 20,000. So is the fix.
A SharePoint breach is rarely a SharePoint bug. It is a permission-sprawl bug wearing a SharePoint costume.
What the Swiss government disclosure actually tells us
The disclosure from the Swiss federal government on 6 August, covered by BleepingComputer, is that around 200 accounts were accessed through a SharePoint compromise. The exact entry vector is not yet public. The post-mortem is still landing in the press.
That is the right level of detail to draw the right lessons from, because the lesson is not about a specific Swiss government SharePoint misconfiguration. The lesson is about the class of misconfiguration that holds across tenants. If you read a handful of post-mortems for this kind of incident, three patterns repeat.
Pattern one: external sharing that nobody remembers enabling. A site owner clicks "share with anyone" for one link in 2022, that link gets forwarded to two more people, both of whom leave the organisation, and the link is now an open door sitting behind a URL nobody can remember creating. The link is still live. The owner has forgotten the site exists. The data inside has not been reclassified since the original share.
Pattern two: "Everyone except external users" doing the work of a real access list. The default permission level on a fresh SharePoint site is "Everyone except external users," which sounds restrictive until you realise that "everyone" in a 200-person firm is every current employee, every past employee who has not been hard-deleted from the directory, every service account, every guest whose tenancy was added for a one-off project, and every device identity that has registered. The site looks "internal-only" to the owner. The actual audience is whatever the directory has grown into.
Pattern three: sites whose owner left the building. When a person leaves an organisation, their personal OneDrive gets a 30-day grace period, and their team sites get reassigned. The sites that get missed are the ones that were shared with that person as a member but where the person was not the primary owner. Those sites stay in the tenant, stay in search, and keep every piece of access they had on the day the person left, including any guest users that person had invited.
These three patterns are not exotic. They are the default state of every M365 tenant I have ever audited that did not have an explicit permission-sprawl program running. The Swiss government's tenant was a 20,000-seat federal estate. The accounting firm in Parramatta was a 65-seat tenant. The same three patterns, same fix.
The audit you can run this week
The fix is a checklist, not a project. Run it on a quiet afternoon, and the whole job fits inside two hours for a small tenant or two days for a 500-seat estate. The four steps are below, in the order I would run them.
Step 1: Find every site with "Everyone except external users" as an effective permission
In SharePoint admin centre, the easiest way to surface this is the "Site permissions" report under Reports. Filter to sites where the "Everyone except external users" group has any access. The list you get is your candidate pool. The candidate pool is the list of sites that look internal-only to a casual owner and global to anyone who actually checks.
The job is not to strip this permission from every site. The job is to walk the list with a real owner, ask "who is the smallest set of people who actually need access to this," and replace the broad group with that answer. Most of the time, the answer is a security group of 6 to 12 named people, which is a thing that already exists in your Entra ID and was just not being used.
Sites to keep "Everyone except external users" on are the ones you would be comfortable showing to any current employee with a corporate device, full stop. Internal comms sites, the company handbook, the lunch menu, things like that. Anything that holds client data, financial records, or HR information does not belong in this group. If you find a "client files" site with this default, that is your top-priority item.
Step 2: Inventory every external sharing link that is still open
In SharePoint admin centre, the "Shared with external users" report is your second stop. This list will be longer than you expect, because external sharing defaults in M365 are permissive and most tenants I see were set up before the "specific people" default existed. For each link, three questions.
First, is the link still needed? A link shared with a client's email address for a 2023 project is, by 2026, a different question. Second, does the link still have the right scope? A "specific people" link with "view only" is different from a "specific people" link with "edit," and a "anyone with the link" link is a different question again. Third, what is the data behind the link? A link to a marketing brochure is one thing. A link to a folder of pre-issue financial statements is something else.
The action is to either re-confirm the link with a new expiry, or to switch it off. The default expiry of 60 days that Microsoft now ships is your friend. Turn it on, then run this same report every quarter.
Step 3: Find sites whose owner has left
PowerShell will give you this answer in one line if you know the trick, but the no-script version is to ask every team lead a single question: "which SharePoint sites do you own, and which of those would still be there if you left the company next Friday?" You will get a useful answer from about 40 percent of them on the first ask. The rest will promise to check, and half of those will forget.
The sites you actually need to find are the ones whose primary owner left the organisation in the last 24 months. For a smaller tenant, that is a manual check. For a larger one, the script is straightforward: pull the list of sites, pull the list of owners, join on UPN, filter to owners whose account is disabled or deleted, and you have your list. For each, the question is the same: who is the live owner now, and is the data inside still needed?
Step 4: Make the audit recurring, not a one-off
The bug with running this audit once is that the next 12 months will undo it. New sites get created. New links get shared. New contractors come and go. The audit you do this week is the audit you have to do again in 90 days, and the audit you have to do again in 180 days, until the cadence is just part of how the IT team operates.
The cheapest way to make it recurring is to set a calendar reminder for the same week every quarter, write the four steps down in a one-page runbook, and assign one named person as the owner. The first run takes the longest because you are also building the runbook. The second run is much faster. By the third run, the answers look very different to a tenant that has never had the audit, and you can feel the difference in the daily noise of "who has access to this" questions.
The framework mapping, in one paragraph
CIS Controls v8 covers this under Control 6 (Access Control Management). The Microsoft Cloud Security Benchmark covers it under Data Protection and Identity and Access. ACSC's Essential Eight treats over-privileged accounts as a maturity-level 2 control. The Australian Privacy Principles and the Notifiable Data Breaches scheme both land here the moment a SharePoint site holds personal information. The four-step audit above covers what every one of those frameworks is going to ask about in this area. The framework mapping is a writeup you do after the audit, not before.
What to do with a tenant that has been left to drift
If you inherit an M365 tenant that has never had this audit run, expect a site list of several hundred, an external sharing list that is longer than you wanted it to be, and a small number of sites that genuinely have no live owner. Triage the highest-risk sites first (anything with "client", "candidate", "contract", "finance", "payroll", "board", or "HR" in the site name), and get the rest onto a recurring cadence. Document the small number of "we have decided to keep this" decisions so a future auditor does not have to redo the thinking.
What to do on Monday
The Swiss government disclosure is real, the investigation is live, and we will probably learn more specific details in the next few weeks. The lesson is not about one specific misconfiguration in Bern. The lesson is that permission sprawl is the default state of every M365 tenant, including yours, and the only fix is a recurring audit with a named owner.
Pick one site in your tenant today. Open its permissions. See who has access. If the answer is "everyone in the company and a few guests I have never met," that is your Monday job.
Forward this to whoever runs your tenant. Two hours of quiet this week is cheaper than a notifiable breach next quarter.
Mathew Clark Founder, SecureInSeconds Currently: walking one client through the external-sharing report for the third quarter in a row and still finding things.
Frequently asked
What actually happened in the Swiss government SharePoint breach? On 6 August 2026, the Swiss federal government confirmed a SharePoint incident that touched around 200 user accounts. The investigation is ongoing and a fuller technical post-mortem is expected.
Could this happen in a 20-seat M365 tenant? The failure mode is the same shape at 20 seats or 20,000. Permission sprawl, over-broad sharing defaults, and orphaned sites exist in any tenant that has not run a recurring audit. The blast radius is smaller, but the entry path is identical.
What is the fastest single check I can do today? Open SharePoint admin centre, go to Reports, then Site permissions, and filter to sites where "Everyone except external users" has any access. The list is your candidate pool. Even just reading the list is a useful first pass.
How often should this audit run? Quarterly for a small tenant, monthly for a mid-size, and as a continuous process in larger estates where the site count is in the thousands. The first run is the longest because you are also building the runbook. Each subsequent run gets faster.
Further reading
- BleepingComputer: Swiss government SharePoint breach compromised 200 accounts - the original disclosure coverage
- Microsoft: SharePoint "External sharing" overview - the platform's own guide to the four sharing models
- Microsoft: Audit external sharing for a SharePoint site - the platform's own audit walkthrough
- Microsoft: Manage access to a SharePoint site - the access management reference
- ACSC: Essential Eight maturity model - the Australian framework this maps into
- CIS Controls v8.1: 06 Access Control Management - the international framework this maps into
- SecureInSeconds: MFA Fatigue and the Playbook for IT Teams - the identity-side cousin of this audit
- SecureInSeconds: Patch Tuesday August 2026: ANZ SMB Priority List - the patching side of the same monthly rhythm
