Guide
Conditional Access starter checklist
A practical Conditional Access baseline for Microsoft 365 — MFA, legacy auth, devices, and the registration paths attackers actually use.
Conditional Access is where Microsoft 365 identity policy becomes real. Secure Score can tell you what to aim for; Conditional Access is how you enforce it.
Use this checklist to put a sensible baseline in place for a New Zealand mid-market or public-sector tenant. Tick only what is enforced, not “planned”.
Print it, or download the PDF.
How to use it
Work top-down. Break-glass first, then MFA, then legacy auth, then devices and registration hardening.
Name a break-glass (emergency access) account before you tighten Conditional Access, and exclude it deliberately from the policies that would lock you out.
Prefer report-only, then a pilot group, then all users — unless the control is already low-risk (for example blocking legacy authentication).
Document what you switched on, and why. That matters under Privacy Act 2020 when you need to show you take identity seriously.
Before you start
- At least one break-glass account exists, is monitored, and is excluded from risky Conditional Access policies
- You know which licences you have (Entra ID P1 / P2, Intune) so you only tick what you can actually enforce
- A small pilot group is ready (IT first) for any policy that might interrupt sign-in
Core sign-in policies
- MFA required for all users (prefer Conditional Access over per-user MFA)
- MFA required for all admins, with phishing-resistant methods where licensing allows (passkeys / FIDO2 / Windows Hello for Business)
- Legacy authentication blocked (POP, IMAP, SMTP AUTH, and other basic auth clients)
- High-risk sign-ins blocked or forced to remediate (where Identity Protection is licensed)
- Risky users blocked or forced to remediate (where licensed)
Devices and apps
- Exchange Online, SharePoint, and OneDrive require a managed / compliant device or a constrained browser session (no download / sync) for unmanaged devices
- Device code flow blocked unless you have a named business exception
- Authentication transfer / companion-app style flows blocked unless you have a named exception
- Persistent browser sessions limited for privileged roles
Security info and registration (the quiet attack path)
Helpdesk-style “update your passkey / MFA” lures succeed when registration is wide open. Harden this on purpose.
- Separate Conditional Access for registering security information (MFA methods / passkeys)
- Registration requires phishing-resistant strength where you can
- Registration limited to managed devices and/or trusted locations
- Registration blocked at high sign-in risk
- Fresh interactive sign-in required before registering new methods
Guests and external access
- Guest users have Conditional Access applied (not left on “we’ll do guests later”)
- Guest MFA required
- Guest access to sensitive apps is deliberate — not the tenant default
Privileged roles
- Standing Global Administrators kept small and named
- Privileged roles use just-in-time elevation (PIM) where licensed
- Privileged role sign-ins require phishing-resistant MFA and, where practical, managed devices
Operating rhythm
- Policies have clear names (what they do, who they cover)
- Exclusions are listed and reviewed on a cadence
- A named owner reviews Conditional Access after any Entra / identity disclosure or major M365 change
- Break-glass sign-in is monitored (alert on use)
What good looks like
You can explain every policy in one sentence. Nobody is relying on per-user MFA leftovers. Device-code and MFA registration are not open doors. And if Microsoft publishes another Entra advisory tomorrow, you already know how your tenant answers “who can sign in, from where, on what, and how do they prove it?”
When you want this turned into a ranked plan for your tenant, book a chat.
Related: Microsoft Secure Score checklist, and the Tech Insight on passkey-themed lures.