This essay is also published on Mark Shavlik's Substack: subscribe there to get future essays by email.
There is a moment in every Microsoft 365 tenant's life where an administrator, trying to solve a real problem under real time pressure, makes one small change. They exclude a group from a Conditional Access policy to unblock a VIP or a friend in a bind, and they forget to restore it. They grant a role directly because PIM activation felt like friction during an outage. They flip SharePoint external sharing to "Anyone" because a partner could not open a file and the meeting was in ten minutes. I had one admin tell me on a flight they had to turn off the firewall at night so their games worked.
None of these people did anything malicious. Every one of them made the tenant dramatically easier to breach.
That is the defining property of Microsoft 365 security: when an admin gets something wrong, the risk does not go up a little. It multiplies. A normal user's mistake exposes their own files. An admin's mistake silently rewrites the rules for everyone, and nothing in the portal turns red when it happens.
I have been watching this exact failure for more than thirty years, so let me tell you how I know. I started in cybersecurity in 1994 at 3M, after nearly five years on the operating systems team at Microsoft in Redmond, where I worked on Windows NT and was there for its first boots. I gave up a window office looking out on Lake Bill because I needed to get out and work in the field. The first thing the field taught me was that I knew nothing. Five years in an ivory tower of sorts had taught me systems, not the world that runs them, and the field has been teaching me how little I know ever since.
3M was moving from the mainframe to Windows NT, one of the first big companies to make that jump, and they handed me what sounded like a simple task: make sure that when an employee leaves, their accounts get disabled. It was not simple. 3M had domain controllers, and it also had local administrator accounts scattered across sites all over the country. Finding all of those accounts, reliably, and removing them took me a year. That year made me a security configuration person for life after I saw the risk. I went on to write InspectorScan, a well-known scanner in its day, which I sold to George Kurtz, then the CEO of Foundstone. Around 2000 I helped Microsoft fix its patch distribution problem, on an internal project that became WSUS, still the core of Microsoft patching today. And I built HFNetChk and MBSA, whose design is still in use today to secure millions of computers every day, only now under a different name at a different company, since I sold Shavlik Technologies, the company I founded around it, to VMware. Much of the Shavlik Technologies team continues to work on it, 25+ years later.
I am sharing this because that first assignment at 3M never ended for me. Accounts that should be disabled but are not. Admin rights nobody can enumerate. Configuration everybody touches and nobody owns. That was 1994 on Windows NT. It is 2026 on Microsoft 365, and it is the same problem, only now on the cloud, where there is no firewall between the good guys and the bad guys. Just user accounts, or worse, unsecured shared data, intentional and otherwise.
We build security management software for a living. Our engine runs nearly 700 checks across Entra ID, Microsoft 365, Intune, Purview, Sentinel, Defender, and more. Here is the uncomfortable truth from that vantage point: we have never seen a clean tenant. Not large ones, not small ones, not the ones run by good teams. Everyone running M365 has some of these issues right now. The only question is whether you know which ones.
This post walks through the ways it goes wrong, what each problem costs you, and the fix for each one. Then it makes an argument the security industry does not want to hear about AI. And it ends with the good news, because there genuinely is good news.
Why Microsoft 365 security breaks quietly
Microsoft 365 is not one product. It is identity (Entra ID), email (Exchange Online), files (SharePoint and OneDrive), chat (Teams), devices (Intune), applications (app registrations and service principals), and defense (Defender), all bolted to one identity plane and administered by dozens of screens, three generations of admin portals, PowerShell modules, and Graph.
Three structural facts make misconfiguration the default state rather than the exception:
1. Security is assembled, not included. A new tenant does not block legacy authentication, does not require phishing-resistant MFA, does not restrict who can consent to third-party apps, and does not stop anonymous sharing links. Someone has to build each of those controls, correctly, and keep them standing.
2. The permission model is deliberately distributed. Microsoft designed M365 so that resource owners manage their own resources. Every Team has owners. Every SharePoint site has owners. Every group has owners. Every app registration has owners. Those owners can add members, invite guests, change sharing settings, and grant access, all without a ticket, all without the security team ever seeing it. That distribution is why M365 scales, and it is also why nobody in your organization can currently tell you, with confidence, who can read the folder where finance keeps the acquisition model.
3. Configuration drifts. Even a tenant that was hardened correctly last year is not that tenant anymore. Admins change, projects create exceptions, "temporary" test users stay enabled, a migration turns a policy off and nobody turns it back on. Security posture in M365 is not a state you reach. It is a state you keep, or lose.
Now let's get specific. The examples below are representative of the Microsoft 365 misconfigurations our scans surface constantly. For each one: the problem, why it happens to good teams, the fix, and what it costs you if you leave it.
Conditional Access: powerful, complex, and one exclusion away from useless
Conditional Access is the closest thing M365 has to a firewall for identity, and it is the control we see broken most often, because it is genuinely hard to get right. Policies interact. Exclusions accumulate. A policy can look perfect in the portal and be hollow in practice.
Problem: legacy authentication is not fully dead, and the last hole is the one that matters. Older protocols that authenticate with just a password do not understand MFA at all: an attacker with a password walks around it. Microsoft has spent years killing these off in Exchange Online, and IMAP and POP basic auth are finally gone. But SMTP AUTH basic survives to this day: its retirement has slipped from September 2025 to April 2026 to "disabled by default, late December 2026," admins can turn it back on, and the final removal date will not even be announced until 2027. That is a live, password-only endpoint in most tenants right now, and password spray tooling targets it around the clock, against every tenant on the internet, including yours. CISA's SCuBA baseline does not wait for Microsoft's schedule: legacy authentication SHALL be blocked (MS.AAD.1.1v1), by you, with a Conditional Access policy that proves it.
Why it happens: an old multifunction printer, a line-of-business app from 2016, a vendor integration nobody wants to break. So the block never ships, or ships with an exclusion that covers half the company.
The easy fix: one Conditional Access policy blocking legacy authentication for all users. Check sign-in logs first to find the handful of real legacy dependencies, migrate or isolate them, then block. This is hours of work, not weeks.
The risk of not fixing: your entire MFA investment is decorative. Every account is exactly as strong as its password, and some of your passwords are in a breach dump right now.
Problem: the exclusion that ate the policy. We routinely see MFA policies that exclude a "temporary" group created during a rollout years ago, and that group has quietly grown. Or a policy that targets "All users" but excludes service accounts, and admin accounts got sorted into the exclusion for convenience. In a representative scan, nearly a quarter of enabled users could sign in with a password alone, in a tenant whose owners sincerely believed MFA was enforced everywhere. Microsoft's own incident data has said for years that the overwhelming majority of compromised accounts had no MFA at the moment of compromise.
The easy fix: review every Conditional Access policy's exclusions quarterly. Every exclusion needs a name, a reason, and an expiration. Then verify coverage from the data side: not "does the policy exist" but "which enabled users are actually not covered by any MFA requirement." That second question is the one that finds the gap.
The risk of not fixing: account takeover through the exact accounts you thought were protected, followed by everything else in this post, because identity is the front door to all of it.
Privileged access and PIM: most tenants still run on standing admin
Microsoft ships Privileged Identity Management for exactly this problem. Most organizations either do not license it, do not turn it on, or turned it on and then granted permanent assignments anyway. The result is standing privilege: admin rights that are on 24 hours a day whether anyone is doing admin work or not.
Problem: too many Global Administrators, permanently active. A representative finding from our scans: nine Global Administrators, eleven privileged role assignments permanently active instead of eligible, and in one memorable case a guest account from outside the organization holding User Administrator. The SCuBA baseline says two to eight Global Admins, no permanent active privileged assignments, and no privileged roles on external identities. Standing privilege makes every admin credential a standing target: phish any one of those nine people on any day of the year and the attacker is Global Admin the moment the token lands.
Why it happens: roles get granted during projects and never removed. Global Admin gets handed out because finding the correctly scoped lesser role takes research. PIM activation feels like friction, so people quietly convert eligible back to permanent.
The easy fix: inventory every privileged role assignment (there are dozens of privileged roles beyond Global Admin, and the sprawl hides there). Cut Global Admins to two to four humans plus documented break-glass accounts. Convert everything else to PIM-eligible with MFA on activation and approval for Global Administrator. If PIM is not in your licensing, at minimum make privileged accounts cloud-only, separate from daily-driver accounts, with phishing-resistant MFA.
The risk of not fixing: blast radius. This is the difference between an incident report that says "one mailbox was accessed" and one that says "the attacker held Global Administrator for nineteen days." Same phish, same user, wildly different company outcome. When an admin account with standing privilege is compromised, the attacker does not hack your tenant. They administer it.
The distributed data problem: owners everywhere, oversight nowhere
Here is the part that surprises leadership most. Ask who controls access to your most sensitive data and the answer is not "IT." It is hundreds of resource owners, most of whom do not know they are security decision makers.
Problem: anonymous sharing links. SharePoint's "Anyone" links are access control bypasses by design: no sign-in, no audit trail of who used them, no expiration unless you set one. Anonymous links move data outside every access control the tenant has. One employee shares the board deck to review from a personal iPad, and that URL now works for anyone who ever obtains it, forever.
The easy fix: set the default link type to "Specific people," restrict external sharing to the model you actually intend (existing guests, or approved domains), and force expiration on any Anyone links you genuinely need. Then find the links that already exist, because turning off the faucet does not drain the pool.
The risk of not fixing: this is the "one SharePoint site with company financials accidentally shared" scenario, and it is not hypothetical anywhere. It is the breach that requires no malware, no exploit, and no skill. Just a link that should not exist, found by someone it was never meant for.
Problem: external mail auto-forwarding is allowed. After an account is phished, the first thing many attackers do is set a quiet forwarding rule to an external address. The user notices nothing. Every invoice, every contract, every password reset email flows out, for months.
The easy fix: disable automatic forwarding to external domains at the remote-domain level, with a short approved-exception list. Minutes of work.
The risk of not fixing: silent, durable data exfiltration that survives even after the password is reset, because the rule persists when the session ends.
Problem: users can consent to any application. Unrestricted user consent means any employee can grant a third-party app read access to their mail and files with one click on a convincing OAuth prompt. Consent phishing exploits exactly this, and it defeats MFA entirely, because the user legitimately signs in and then hands the attacker a token.
The easy fix: restrict user consent and turn on the admin consent workflow so requests route to someone qualified to read a permissions list. While you are in there, look at your service principals: long-lived password credentials on apps are unrotated secrets waiting to leak. The baseline is certificates or managed identities, and nothing older than 180 days.
The risk of not fixing: a compromise path with no password stolen and no malware dropped, invisible to every tool watching for "suspicious sign-ins," because the sign-in was real.
And the quiet ones. Enabled accounts with no sign-in for 90 days are unmonitored attack surface: nobody notices when a stale account starts authenticating. Audit log retention set to 90 days means that when you finally do investigate, the evidence you need from month four is gone. Unencrypted laptops turn a left-behind bag into a reportable data exposure. None of these is exotic. All of them are findable in an afternoon.
Machine identities: the client IDs, secrets, and service principals holding up your pipelines
There is a whole second population of identities in your tenant that nobody phishes because nobody needs to: the machine ones. Every DevOps pipeline, build agent, deployment script, and integration that touches your cloud authenticates somehow, and the workhorse pattern is an app registration with a client ID and a client secret. This is everywhere. CI/CD is built on it. And a client secret is simply a password for a robot: no MFA challenge, no Conditional Access prompt in most configurations, valid from any IP on earth, working at 3 a.m. without anyone noticing, until someone remembers to rotate it. The complexity is not the concept; it is the sprawl. Those secrets end up in pipeline variables, in YAML files, in scripts on laptops, in wikis, and, fatally, in Git history, where a secret committed once lives on in every clone even after the file is "deleted." Meanwhile the app registrations themselves accumulate permissions the way SharePoint sites accumulate owners, and nobody is reviewing what that forgotten pipeline principal from 2022 can still read.
If you think this is a problem for less capable organizations, consider what happened to CISA itself, the United States' top cyber defense agency and the author of the very baselines cited throughout this post. In May 2026, researchers at GitGuardian found a public GitHub repository named, without irony, "Private-CISA": 844 megabytes of material including plaintext passwords, AWS GovCloud administrative keys and tokens, Entra ID SAML certificates, and credentials for CISA's internal DevSecOps environment, sitting publicly readable since November 2025. Roughly six months of exposure. Once reported, it came down in about 26 hours, which is the one bright spot in the story.
Here is what that breach means, and why it belongs in a post about basics. First, it means this failure mode respects no one: if the agency that writes the secure configuration baselines can leak its own machine credentials into public Git, your organization can too, and probably has somewhere. Second, it shows why machine credentials are the attacker's preferred find: those AWS keys and SAML certificates did not need a phish, a payload, or a single alarm-tripping login anomaly to be usable. Whoever found them first simply was CISA, to every system that trusted them. Third, it demonstrates the Git history problem in the largest possible font: the exposure lasted half a year not because anyone was watching and failed, but because nobody was looking at all.
The fixes are, once again, unglamorous and effective. Inventory your app registrations and service principals and their permissions, and delete the ones nothing uses anymore. Replace client secrets with certificates or, better, with managed identities and workload identity federation, which remove the storable, leakable secret from the pattern entirely. Cap the lifetime of any secret that must exist, and rotate anything old; our scans routinely surface service principals with password credentials untouched for years. And turn on secret scanning wherever your code lives, because the question is not whether a developer will someday commit a credential. It is whether you find it before someone else does.
Patch Tuesday, a quarter million CVEs, and the dormant risk that wakes up
It is worth remembering why Patch Tuesday exists at all, because I watched it happen. In the early days Microsoft released critical security patches whenever they were ready: any day of the week, no warning, sometimes several in one week. Every unscheduled release meant another fire drill, and the CIOs and CTOs at Microsoft's biggest customers got madder and madder about running their operations at the mercy of a random clock. In October 2003 Microsoft gave in to the pressure and consolidated releases into a predictable monthly cadence on the second Tuesday of the month. Patch Tuesday was born as a customer relations fix, and it worked. But notice what it actually did: it made the flood schedulable. It did not make the flood smaller. And what amazes me most, looking back at it now: the flood never stopped. Twenty-five years is a long time in technology. Whole platforms have been born, dominated, and died in that span, and the second Tuesday of every month still arrives with a fresh load of critical fixes. If patching were a problem the industry could ship its way out of, twenty-five years was more than enough time to do it.
Configuration is only half the exposure. The other half arrives on a schedule. Every second Tuesday of the month, Microsoft's Patch Tuesday ships fixes for anywhere from sixty to well over a hundred vulnerabilities at once, each with its CVE identifiers and KB articles that someone in your organization is supposed to map to real machines, test, deploy, and verify. That is one vendor. Across the industry, the CVE catalog now holds well over a quarter of a million entries, with tens of thousands of new ones published every year. Nobody patches all of it, everywhere, immediately. Which means every organization is, at all times, running some set of known vulnerabilities and betting nobody gets around to using them. We track this drumbeat month by month on our Patch Tuesday hub.
Here is the part that bet gets wrong: vulnerabilities do not expire. A CVE that shipped with a fix years ago is not history; it is inventory. Attackers industrialize old vulnerabilities long after release, once exploit code is public, reliable, and cheap, and the CISA Known Exploited Vulnerabilities catalog is full of entries being actively used years after their patches shipped. EternalBlue is approaching its tenth birthday and still finds victims. This is the dormant patch problem: the fix has existed for years, but on some forgotten server or unmanaged laptop it was never applied, and nothing hurts until the day an access broker's scanner finds it. Ransomware crews in particular prefer proven old vulnerabilities to zero days, because they cost nothing and still work. This is why vulnerability prioritization starts with KEV and EPSS exploit probability, not with the raw severity score: the question is never "how bad could this be in theory" but "is anyone actually using this one right now."
And dormancy is not just a patching problem. Remember those enabled accounts with no sign-in for 90 days? Dormant accounts and dormant patches fail the same way: they look like nothing, right up until they wake up. The stale account that suddenly authenticates at 3 a.m. from a new country is not an employee back from sabbatical; it is a credential from an old breach dump finally being tried, against an account nobody was watching because nobody remembered it existed. Dormant risk is the purest form of the unknown unknowns problem from the previous section: it accumulates silently, costs nothing to leave alone this quarter, and converts to an incident without warning. The defense is the same everywhere in this post: enumerate everything, continuously, so that "dormant" becomes a list you manage instead of a surprise you respond to.
Why this takes continuous review, and why that is less work than it sounds
Every problem above shares a shape: it was created by a reasonable person, it produced no alert, and it will sit there until someone goes looking. That is why point-in-time hardening fails. The tenant you secured in January drifted by March, because tenants are alive.
The federal government has already accepted this logic. CISA's Binding Operational Directive 25-01 does not tell agencies to secure M365 once. It mandates the SCuBA secure configuration baselines and continuous assessment against them, because CISA watched agency tenants drift back into exposure after every one-time cleanup.
Here is what practitioners consistently find, and what we see across scans: the first review is the big one. That is where you find the nine Global Admins, the legacy auth exception from 2019, the Anyone links, the forwarding rules. That cleanup is real work: call it days, not months.
After that, the curve collapses. A tenant reviewed continuously produces a short list of new findings each cycle: an exclusion added last sprint, a new app consent, two accounts gone stale. Each one is minutes to fix because it is fresh, small, and has an obvious owner. This is not a lot of work once you do it. The organizations drowning in M365 security are the ones doing it never or annually. The ones doing it continuously spend less total effort and are dramatically harder to breach.
Nearly 700 checks, and counting: why the number is not the point
Our engine runs nearly 700 checks today, and at some point we will double that. Here is the honest part: the count itself is not what matters, other than what it tells you about the terrain. It is a lot, because the terrain is a lot. As one Microsoft Security MVP put it to us, there are thousands of things to check in a Microsoft cloud environment. Thousands. No quarterly review meeting, however diligent, is walking through thousands of settings by hand. The portals do not even put them all in one place.
Here is a detail that puts the growth in perspective. InspectorScan, the product I wrote back in the 1990s, had roughly the same number of checks as my current product does today. Back then, that count covered Windows machines on a corporate network, and it felt exhaustive. Today the same count has to stretch across your Windows, Mac, and Linux machines for patches, configuration settings, access, and activity logs, AND across every cloud property you own: the tenant, the identities, the sharing, the applications, the pipelines. The surface multiplied many times over; the attention mostly did not. Most organizations ignore most of this, and that is not a neutral choice. It is a gamble they place with their company every single day, whether they think of it that way or not.
Another MVP shared a number that should stop you cold: roughly 30 gigabytes of data, in a single customer tenant, just describing who can access what. Not documents. Not mail. Just the access map: permissions, memberships, delegations, sharing grants, role assignments. And buried inside that 30 gigabytes was the finding that mattered: one of the executives at that customer had his email wide open. Not hacked. Not attacked. Just open, through accumulated permissions nobody had ever listed in one place, readable by people who were never supposed to see it. It had presumably been that way for a long time, and it was found only because someone finally enumerated everything instead of spot-checking.
That story is the whole argument in miniature. The misconfigurations you know about are the easy part; you can fix a finding the day you see it. The things we do not know about are the real risk. Every access grant in that 30 gigabytes was made by some person, for some reason, at some moment when it made sense. Nobody made the map. Nobody owns the map. The exec's mailbox was not exposed by an attacker; it was exposed by the accumulation of ten thousand reasonable decisions that no human ever reviewed as a whole.
This is why check coverage grows and why it has to. Each check is a question you would not have thought to ask, asked automatically, every scan, across the whole tenant. The count is not a scoreboard. It is how much of the unknown gets converted into a list you can act on. The tenants that get breached are rarely the ones that failed a check they knew about. They are the ones that never asked the question.
About the AI security pitch you are currently receiving
The security industry has found its next product cycle, and it is "securing your AI." You will be told you need an AI security posture platform, an AI firewall, an AI red team, before Copilot eats your company.
Here is what that pitch skips: your AI is built inside the environment this post just described. Copilot and every M365-integrated AI tool answers with the permissions of the user asking. It reads what that user can read. So when an AI assistant surfaces the salary file or the acquisition model to the wrong employee, that is not an AI vulnerability. That is your SharePoint permission sprawl and your Anyone links, now equipped with a natural-language search interface. The AI did not create the exposure. It found the exposure you already had, faster than an intern with a search bar.
If your identities lack MFA coverage, your admins hold standing privilege, and your sharing model is uncontrolled, then an AI security product is a smoke detector installed in a house with no doors. The vendors selling it are not lying about AI risk existing. They are selling you the advanced course while you are failing the prerequisite, because the prerequisite is not what their product does. Until you manage the basics, the rest does not matter. Secure the tenant and you have secured most of what matters about the AI, for free.
A personal note
I talk with CSOs and business executives all the time. Some call me paranoid. Some just want me to go away, because I am causing them trouble. Harry Truman said it best: "I never did give anybody hell. I just told the truth and they thought it was hell."
And the industry is slowly, profitably, coming around. The big-dollar security companies like CrowdStrike sell patching now, twenty-five years after I did. There is a nice symmetry in that: George Kurtz, CrowdStrike's CEO, bought my first security product back at Foundstone. They sell patching to make money. They sell many products to make money, and the products do help, if used correctly. But notice what just happened: the most advanced security vendors on earth are now selling you the basics. Does their portfolio help? Sure, used correctly. Does doing the basics around your security help more? I think so. The basics were always the product.
The close: the solution exists, and the clock is not neutral
Everything in this post is findable and fixable. The checks are known: CISA publishes the baselines, NIST maps the controls, and continuous posture scanning (this is exactly what we built Siemserva to do, across nearly 700 checks covering identity, privileged access, Conditional Access, applications, email, SharePoint and OneDrive, devices, and logging) turns "constant review" from a staffing problem into a report you read. Find the issues, fix the short list, then let the continuous scan keep the list short. The initial cleanup is honest work. Everything after it is maintenance.
And if you want somewhere to start today without buying anything, use the free tools we maintain at senserva.com and rely on ourselves: the Microsoft Patch Tracker with every current KB exploit-ranked, the Patch Tuesday hub for each monthly release, Exploited This Week for what attackers are actually using right now, the What's Hot ranking across CVEs and KBs, and working guides to the Microsoft 365 misconfigurations and SCuBA baselines covered in this post. They are AI-enhanced, they cite their sources, and they refresh multiple times a day. Free, because the basics should be.
But be clear-eyed about the alternative, because the alternative is not "we will get to it next quarter in peace."
If the unwanted are already in your tenant, they do not look like attackers. They look like your employees. They sign in with real credentials from a phish, through the legacy endpoint you never closed or the account your MFA policy never covered. They read mail through a forwarding rule, browse SharePoint with a user's own permissions, and touch nothing that trips an alarm, because from the tenant's point of view nothing unusual is happening. Organizations discover this months later, from a customer, or from the follow-on fraud, or never.
And if they are not in yet, they are working on it right now. Not during business hours. 7x24, automated, patient, at a cost to them of approximately nothing: spraying passwords at legacy auth, replaying breached credentials, mailing OAuth consent lures, and walking the sharing links that should not exist. They do not need to beat your security program. They need one weakness you have not reviewed. One excluded group. One standing admin. One anonymous link to a spreadsheet named the wrong thing in a site named "Finance."
You cannot make the attempts stop. You can only make them fail. The basics, done and then kept done, are how they fail.
Fix the basics. Keep them fixed. Everything else is noise until you do.
Comments and discussion are open on the Substack version of this essay.