Microsoft 365 identity security
readiness checklist.
Twenty-four questions across the six areas current attacks against Microsoft 365 actually use. Every one is answerable from your own admin centres, and every one says why it matters — so you can act on it without buying anything.
Section 01
Authentication flows
The paths that bypass the policies written for browser sign-in. This is where most tenants are weakest, because Conditional Access is usually authored with interactive login in mind.
Is device code flow blocked for all users except break-glass accounts?
Device code phishing does not defeat MFA — the victim completes a genuine Microsoft challenge and the resulting token goes to the attacker. Blocking the flow removes the technique outright.
Did you audit existing device code usage before restricting it?
Some legitimate scenarios use it — shared devices, CLI tooling, older meeting-room hardware. Auditing first is what stops a security control becoming an outage.
Is legacy authentication blocked unconditionally, for all client app types?
Legacy protocols do not support modern authentication, so Conditional Access and MFA cannot be enforced on them. Any that remain open are the path of least resistance.
Are authentication transfer flows restricted?
A published mitigation in the FBI advisory on M365 token hijacking, and commonly left at default.
Is MFA enforced for every user and every cloud application, with no per-app or per-group exclusions?
Partial coverage is the norm and it is the gap that gets used. An exclusion added for one legacy app three years ago is a live bypass today.
Section 02
Tokens and device trust
Where an intrusion becomes persistent. This section is the one most often skipped, and it is the reason password resets keep failing to contain incidents.
Can you enumerate every device registered in Entra ID, and would a new registration be noticed?
A registered device yields a Primary Refresh Token, which survives a password reset because it never depended on the password. Unmonitored registration is silent, durable persistence.
Is device registration restricted to managed or compliant devices?
If any authenticated principal can register a device, then any captured token can be converted into long-term access.
Is Continuous Access Evaluation enabled?
Without it, revocation waits for token expiry. With it, a revoked session can be terminated near-immediately — which is the difference between containment and a fortnight of access.
Are sign-in frequency and session lifetime controls configured deliberately, rather than left at default?
Long-lived refresh tokens are the mechanism by which a single successful phish becomes months of access.
Do you have phishing-resistant authenticators (FIDO2/WebAuthn or certificate-based) for privileged accounts?
This is the only control class that actually defeats a transferred-authentication attack. TOTP and SMS do not, because the user genuinely completes them.
Section 03
OAuth applications and consent
The quietest persistence mechanism in the tenant, and the one least likely to appear in an annual audit.
Is user consent to third-party applications restricted or subject to admin approval?
Unrestricted consent lets any user grant a malicious application standing access to their mail and files, with no credential involved at any point.
Have you reviewed existing application consent grants and removed unrecognised ones?
Consent granted once persists indefinitely. Almost every tenant we assess has grants nobody can account for.
Do you monitor for new service principals and credential additions to existing applications?
Adding a secret to an application already trusted in the tenant is a well-established persistence route that looks entirely legitimate in logs.
Section 04
Data exposure and collection
What an attacker reaches once inside — and, more importantly, whether you would have any record of it.
Is organisation-wide or "anyone with the link" sharing disabled in SharePoint and OneDrive?
Broad internal sharing means one compromised mailbox reaches far more than that user's own files.
Does your audit configuration record previews, page views and searches — not only downloads?
Collection through the Graph API can read content without ever triggering a download event. If you only log downloads, an exfiltration leaves no trace.
Are M365 audit logs forwarded to your SIEM, with retention that outlasts your likely detection time?
Dwell time in these campaigns is measured in weeks. Thirty-day retention means the evidence is gone before the investigation starts.
Do you alert on anomalous volumes of file access, as opposed to static DLP thresholds?
Low-and-slow collection is specifically designed to stay under fixed thresholds.
Section 05
Mailbox integrity and detection
The controls that determine whether a compromise is discovered internally or reported to you by a third party.
Do you audit inbox rules across all mailboxes for hidden or obfuscated names?
Rules that auto-file and mark-as-read hide the attacker's own correspondence — including replies — from the account owner.
Would you detect a sign-in where MFA was satisfied by a claim in the token rather than a fresh challenge?
This is what a replayed or transferred session looks like in the log. It reads as success, which is exactly why it is missed.
Do you alert on unusual user-agent strings and non-interactive authentication patterns?
Automated clients maintaining a session look nothing like a human, but only if someone is looking at that field.
Does your incident runbook include session revocation, device de-registration and inbox rule audit?
A runbook that stops at "reset the password" does not contain any of the persistence mechanisms above.
Section 06
Third parties and people
The initial access route that no tenant control closes, because the mail is genuine.
Have staff been trained specifically never to enter a device code they did not themselves initiate?
Generic phishing training does not cover this. The page is real, the domain is Microsoft's, and every instinct the training built says it is safe.
Do you require suppliers who email you to run MFA and to notify you promptly of compromise?
A phishing message from a genuinely compromised supplier passes SPF, DKIM and DMARC, because it is legitimate mail from a legitimate sender.
Have you rehearsed an M365 account compromise in a tabletop exercise?
The decisions that matter — revoke or observe, notify or contain first — are poor ones to be making for the first time during an incident.
Take it with you
The same 24 checks, as a PDF.
For circulating to your infrastructure and security teams, or attaching to a board or IT committee paper. The whole checklist is on this page already — the PDF is for when you need to send it somewhere.
Microsoft 365 Identity Security Readiness Checklist
24 checks across authentication flows, token and device trust, OAuth consent, data exposure, mailbox integrity and supplier risk. We email a confirmation link, then the download.
Check your inbox
We've emailed you a link to download Microsoft 365 Identity Security Readiness Checklist.
The link expires in 48 hours. If it hasn't arrived in a few minutes, check your spam folder.
Something went wrong. Please try again.
Common questions
Using this checklist.
Can we use this checklist without engaging you?
Yes, that is the intent. Every item is answerable by your own team from the Entra and Microsoft 365 admin centres, and every item states why it matters so you can judge it rather than take our word for it. If you work through it and find nothing, you are in better shape than most tenants we assess and you should not buy an engagement.
How long should this take?
A competent M365 administrator can answer most of it in an afternoon. Two items usually take longer: enumerating registered devices in a way that would let you spot a new one, and confirming what your audit configuration actually records rather than what it is assumed to record. Those two are also the ones most likely to surface something.
We can answer yes to everything. Do we still need testing?
Configuration review and adversary simulation answer different questions. This checklist tells you whether the controls exist. It cannot tell you whether they hold in the order an attacker actually uses them, whether a gap in one compensates for strength in another, or whether your SOC would notice. That is what an attack-path assessment is for — but a tenant that passes this cleanly needs it far less urgently.
Where does this guidance come from?
Public sources only: the FBI IC3 public service announcement on Microsoft 365 token hijacking and its published mitigations, Microsoft's own threat intelligence and hardening documentation, and public security research on M365 password-spraying campaigns. We deliberately do not build public content from restricted advisories, whoever they came from.
Found gaps you cannot close internally?
Bring the checklist to a scoping call. Where you already have answers, we skip the discovery and go straight to testing whether the controls hold.