Microsoft 365 misconfigurations that cause breaches and outages

Most Microsoft 365 incidents are not zero-days. They are settings: the Conditional Access policy that locked out its own admins, the legacy protocol that let a password spray through, the OAuth grant nobody reviewed, the audit log that was never on. This page walks through 14 misconfiguration families behind real breaches and outages, what breaks, why it happens, and the exact checks that catch each one before it hurts.

Every check linked below is one of the 672 documented Siemserva checks for Microsoft 365, Intune, Defender, and Entra ID, each with its risk, remediation, and SCuBA, CIS, NIST, HIPAA, and SOC 2 mappings.

First, the other side's view: how an attacker finds these misconfigurations. Then the fourteen families:

How an attacker finds these misconfigurations

Reference: CISA cybersecurity advisories · Microsoft MSRC: Midnight Blizzard (a real intrusion that followed exactly this shape).

Locked out by your own Conditional Access policy

The classic Friday-afternoon incident: a new Conditional Access policy requires MFA or a compliant device for all users, and "all users" includes every administrator, including the account someone would use to turn the policy off. The tenant locks its own admins out, and recovery means a support case with Microsoft, measured in hours or days, while nobody can sign in.

Microsoft's own guidance is blunt: keep at least two emergency access (break glass) accounts, exclude them from every Conditional Access policy, protect them with phishing-resistant credentials, and alert on any use of them. Most lockouts happen in tenants that skipped one of those four steps.

Why it happens: New policies get tested against ordinary users, not against the admin path. Break glass accounts get created once, then quietly disabled, password-expired, or swept into a new policy by an "all users" assignment months later.

Reference: Microsoft: manage emergency access accounts

Legacy authentication still enabled

Legacy protocols (POP, IMAP, SMTP AUTH, older Office clients) cannot do MFA, so a password is all it takes. Microsoft's identity team has reported for years that the overwhelming majority of password spray attacks ride legacy authentication, and that accounts with MFA resist over 99 percent of automated attacks. Attackers know this, which is why spray campaigns hunt specifically for the mailboxes and tenants where legacy auth still answers.

The January 2024 Midnight Blizzard intrusion at Microsoft itself started exactly this way: a password spray against an account on a legacy, non-production test tenant that lacked MFA, followed by abuse of an old OAuth application with elevated access. Two misconfigurations, no zero-day required.

Why it happens: Old multifunction printers, scripts, and line-of-business apps kept legacy auth alive "temporarily", and the block-legacy-auth policy stayed in report-only mode. Exceptions outlive the systems they were made for.

Reference: Microsoft MSRC: Midnight Blizzard attack · Microsoft: one simple action blocks 99.9% of attacks

OAuth consent phishing and overprivileged app grants

The user never types a password on a fake page. Instead, a mail titled "Document shared with you" asks them to approve an app that wants to "read your files and mail", and one click grants a malicious application durable, MFA-proof access through legitimate OAuth tokens. Microsoft documents this as the illicit consent grant attack, and it works because tenants leave user consent wide open.

The overprivileged-app problem is the quieter sibling: applications accumulate broad Graph scopes (Mail.Read for every mailbox, Sites.Read.All, full_access_as_app) that nobody reviews. When one of those apps or its credential leaks, the attacker inherits everything it was ever granted.

Why it happens: User consent defaults were permissive for years, and admins granted broad scopes to unblock a project. Nobody owns the quarterly review of what every app can actually reach.

Reference: Microsoft: detect and remediate illicit consent grants

MFA gaps and token theft

MFA that exists but does not cover everyone is a map of your weakest accounts. Attackers enumerate which users and which protocols skip MFA, then go straight there. And where MFA does apply, adversary-in-the-middle (AiTM) phishing kits proxy the real login page, let the victim complete MFA, and steal the resulting session token: Microsoft has tracked AiTM campaigns against tens of thousands of organizations since 2022.

A stolen token replays from the attacker's infrastructure until it expires or is revoked. Defenses are configuration: phishing-resistant methods (FIDO2, Windows Hello), Conditional Access that binds tokens to devices, and risk policies that catch anomalous token behavior.

Why it happens: MFA rollouts stall at "most users", per-user MFA and Conditional Access get mixed, and the anomalous-token detections that Identity Protection already raises are not wired to any response.

Reference: Microsoft: AiTM phishing and BEC · Microsoft: token protection in Conditional Access

Standing Global Admins and unused PIM

Every standing Global Administrator is a permanent, always-armed skeleton key: phish one and the tenant is gone. Microsoft's own best practice is fewer than five Global Admins, with privileged roles held as PIM-eligible assignments that activate just in time, with MFA and justification, instead of sitting active around the clock.

Tenants that license PIM and never turn it on are common. So are tenants where the Global Admin count crept from three to eleven, one "temporary" grant at a time, and where PIM's own too-many-admins alert has been firing unread for months.

Why it happens: Role assignments are easier to grant than to reclaim, and nobody is accountable for the number. PIM feels like friction until the first incident report asks why eleven accounts could do everything.

Reference: Microsoft: Entra RBAC best practices

App secrets that expire (outage) or never expire (breach)

Both directions of the same misconfiguration hurt. A client secret that expires unnoticed takes the integration with it: sync stops, the line-of-business app throws 401s at 2 a.m., and the outage postmortem reads "credential expired, no owner, no alert".

A secret set to never expire avoids the outage by accepting the breach instead: a long-lived credential in a config file, a repo, or a former contractor's laptop keeps working for years. Long-lived app credentials are exactly what the Midnight Blizzard OAuth abuse leaned on.

Why it happens: Secrets are created at project speed with no expiry policy and no owner recorded. The person who set the calendar reminder left.

Reference: Microsoft MSRC: Midnight Blizzard attack

Copilot surfaces files it should never see

Copilot does not leak data; it reveals the oversharing that was already there. It answers with anything the signed-in user can technically reach, which in most tenants includes the payroll spreadsheet shared to "Everyone except external users" in 2019 and the M&A folder with inherited permissions nobody audited. The first week of a Copilot rollout is when years of permission sprawl become searchable in plain English.

Microsoft's own Copilot deployment blueprint makes oversharing remediation a prerequisite: restrict broad sharing defaults, label sensitive content, and fix inherited permissions before the assistant makes them discoverable. The same applies to custom AI agents, which inherit the permissions of what they are wired to.

Why it happens: SharePoint permissions accumulate for a decade, default sharing settings stay permissive, and sensitivity labels cover a fraction of the estate. Copilot just holds up the mirror.

Reference: Microsoft: Copilot oversharing blueprint

The audit log that was not on

You cannot investigate what you did not record. In the 2023 Storm-0558 intrusion, a federal agency spotted the compromise only because it had access to specific mailbox audit events, and the industry backlash over that logging being a premium feature pushed Microsoft, working with CISA, to expand free cloud logging for everyone. The lesson stands: audit log availability is a security control, not an accounting detail.

Tenants still turn up with the unified audit log returning nothing, retention shorter than the average intrusion dwell time, or key workloads excluded. Every one of those is a blind spot you discover at the worst possible moment.

Why it happens: Logging defaults changed across years of tenant generations, nobody verifies the log actually returns records, and retention is left at whatever the license defaulted to.

Reference: CISA and Microsoft: expanded cloud logging

Email protections turned partly off

Business email compromise remains one of the costliest crime categories the FBI's IC3 tracks, measured in billions of dollars per year, and most of it starts with a message that better filtering would have stopped. Safe Links disabled "because it rewrites URLs", anti-phishing impersonation protection never configured, malware filtering on defaults from 2018: each is a single setting, and each is a door.

CISA's SCuBA baselines for Exchange Online exist precisely because these settings drift; U.S. federal agencies are now directed (BOD 25-01) to align with them, and they are a sensible bar for everyone else.

Why it happens: Protections get disabled during a false-positive incident and never re-enabled, and nobody compares the tenant against the SCuBA baseline afterward.

Reference: CISA: SCuBA project · FBI IC3 reports

Anyone links leaking SharePoint and OneDrive data

An "Anyone with the link" share is an unauthenticated, unexpiring URL to your data. Forward the mail, paste it in the wrong channel, or let a crawler find it, and the document is public. Tenants routinely discover thousands of live Anyone links created over years, many with edit permission, none with an expiry.

The fix is configuration, not training: restrict the default link type, force Anyone links to expire, and make them view-only where they must exist at all.

Why it happens: The permissive default made sharing frictionless, so people used it. Every link that solved a Tuesday problem is still valid three years later.

The lost laptop without BitLocker

A laptop left in a taxi is an anecdote if the disk is encrypted and a reportable data breach if it is not. Disk encryption is the difference between "we lost hardware" and regulator notifications, and it is enforced (or not) by an Intune compliance policy that either requires BitLocker or does not.

The adjacent failure is the compliance policy that exists but is assigned to nobody, or the environment where a quarter of devices have not checked in for months and their state is anyone's guess.

Why it happens: Policies get built in a pilot group and never assigned tenant-wide, and stale devices age out of attention but not out of access.

Guest access sprawl

Every guest invited to a Teams channel is an identity in your directory, and it stays after the project ends, the vendor contract closes, or the guest's own account at their employer is compromised. Guests holding directory roles, guests without MFA, guests in groups that grant application access: each is external risk with internal reach.

The pattern repeats because invitations are one click and reviews are a process nobody scheduled.

Why it happens: Collaboration defaults favor openness, guest MFA depends on the guest's home tenant unless you enforce it, and no owner exists for "who are all these people".

Risk alerts nobody triages

Entra Identity Protection already flags leaked credentials, anonymized-IP sign-ins, and anomalous tokens. In many tenants those detections accumulate for months with nobody assigned to look: the breach announcement was sitting in the risky users list the whole time.

A risk signal with no response policy and no human owner is indistinguishable from no signal at all.

Why it happens: The license includes the detections, but nobody wired them to Conditional Access risk policies or to a triage rotation. Alerts without owners rot.

Configuration drift: the change nobody made

The tenant that passed its audit in March fails the same checks in July, and nobody changed anything, or rather, four people changed fourteen things, each reasonable, none recorded. Drift is how hardened tenants quietly become soft: an exception here, a troubleshooting toggle there, a vendor's "just disable it to test" that stuck.

Point-in-time assessments cannot catch drift by definition. The control is continuous: rescan, compare against the last known-good state, and alert on the delta.

Why it happens: Settings have many editors and no baseline. Without scheduled re-verification, every manual fix is one incident away from being silently undone.

Common questions