Conditional Access for Microsoft 365 admin accounts

Your tenant's baseline Conditional Access requires MFA for everyone and blocks legacy authentication. Good. It is not enough for the twenty accounts that can reset everyone else's password, change every policy, and read every mailbox. Those accounts are the target of every serious attack on a Microsoft 365 tenant, and the standard MFA prompt — approve on your phone — is exactly what adversary-in-the-middle phishing kits are built to defeat. Admin accounts need their own policy set, and it needs to be stricter in specific ways.

This assumes the CA design guide is the baseline and PIM is in use. It also assumes admins have separate admin accounts — a person's daily mailbox-holding identity should not hold a directory role, ever, and no policy below makes sense if that is not true.

What "tighter" means

Four differences from the general population:

1. Phishing-resistant MFA, not just MFA. FIDO2 security keys, passkeys in Authenticator, Windows Hello for Business, or certificate-based authentication. These bind the credential to the origin, so a proxied phishing page cannot capture and replay them.
2. A managed, compliant device, and ideally a specific class of device — a privileged access workstation or at least an Entra-joined, Intune-compliant machine — rather than any browser anywhere.
3. Short sessions. Sign-in frequency measured in hours, no persistent browser sessions, so a stolen token has a short life.
4. No exceptions. Admin policies do not have location exclusions, trusted-network carve-outs, or "except this vendor's account". The only exclusion is break-glass.

The policy set

Target each policy at directory roles, not at a group of admin users. Conditional Access can target policies at role assignments directly, which means a newly assigned Global Administrator is covered the moment the role is assigned, with no group to forget. Include the roles Microsoft's phishing-resistant MFA template lists — Global Administrator, Privileged Role Administrator, Security Administrator, Exchange, SharePoint, Conditional Access, Authentication, User and Password administrators, and the rest of the high-privilege set. PIM-eligible users are covered when they activate, because activation is what assigns the role.

Policy 1 — Admins: require phishing-resistant MFA. Users: the directory roles. Cloud apps: all. Grant: require authentication strength → Phishing-resistant MFA. This is the single most valuable policy in the tenant. Roll it out only after every admin has registered a phishing-resistant method, or you will lock them out — the report-only week below is where you find who has not.

Policy 2 — Admins: require compliant device. Same targeting. Grant: require device to be marked compliant, and (not or) require the authentication strength. If you operate privileged access workstations, add a device filter for those devices' attributes so only the PAW fleet satisfies it. If you do not yet, compliant Entra-joined devices are the achievable version; the gap is that a compromised standard workstation can still be a compliant one.

Policy 3 — Admins: session controls. Same targeting. Session: sign-in frequency of a few hours (many organisations choose between 1 and 8; shorter is safer and admins tolerate it because they are activating PIM roles anyway), and persistent browser session → never persistent. Consider requiring an authentication context for PIM activation of the highest roles, so activating Global Administrator triggers a fresh phishing-resistant challenge even inside a valid session — the authentication contexts guide shows the wiring.

Policy 4 — Admins: block legacy and unmanaged paths. Block legacy authentication clients for the roles (your tenant-wide block already does this; a role-scoped duplicate costs nothing and survives someone loosening the general one). Block device platforms you do not support for admin work — usually mobile platforms, since portal administration from a phone is a habit to break, though the Authenticator app itself is not administration and is unaffected.

Policy 5 — Admins: token protection, where the client apps in use support it. Token protection binds sign-in sessions to the device, which closes the replay path that policy 3 only shortens; see token protection and token theft for the current support matrix. It is safe to apply to admins earlier than to the whole tenant because admins use a known set of clients.

Policy 6 — Admin portals for everyone else. The reverse policy: target all users except the admin roles, cloud app Microsoft Admin Portals, and block. Non-admins have no business at the admin centres, and this stops a compromised standard account from even reaching the door.

Exclusions, and the only one allowed

Every admin policy excludes the break-glass accounts, and nothing else. No vendor account, no "the CEO's assistant needs Exchange admin", no service account with a directory role. If a service principal needs privilege, it gets an app role via a workload identity, which is governed by workload identity policies, not by user CA.

Verify the break-glass exclusion after every change to every admin policy. It is the check that makes the rest of this safe.

Rollout order

1. Register methods. Every admin gets a FIDO2 key or a passkey, and registers it. Track completion with the authentication methods activity report.
2. Report-only for policies 1 to 3 for a week. The sign-in log's Report-only results show who would have been blocked and why — usually a missing method, a non-compliant device, or a role you forgot admins hold.
3. Enable policy 1 first, during working hours, with a second admin signed in on a separate session and the break-glass credentials to hand.
4. Policies 2 and 3 a few days later, then 4, 5 and 6.
5. Access review of the admin roles themselves, because every policy above is cheaper to apply to ten accounts than fifty.

What this does not cover

Conditional Access governs sign-in. It does not stop an admin already signed in from doing something foolish, and it does not protect the admin's workstation from malware that acts within the session. Those are PIM (approval and justification for activation), administrative units (scoping what a role can touch), and device hardening. The policies here are the front door; the rest of the house still needs locks.

Downtime risk is entirely self-inflicted lockout, which the report-only week and the break-glass exclusion prevent. Microsoft support cannot bypass a Conditional Access policy for you; they can, slowly, help recover a tenant whose every admin is locked out, which is the outcome all of this is designed to make impossible.