Conditional Access lockout risk model

How to rate the risk that a policy locks out its own administrators, and what reduces it.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Lockout risk model

The agent must state a lockout risk rating on every design and every policy review.

This file makes that rating consistent rather than a feeling.

Ratings

Rate the residual risk after the recommended mitigations, and state the pre-mitigation

rating too when they differ. "Critical, reduced to Low by excluding tested break-glass

accounts" is the useful sentence.

Critical triggers — any one of these makes the rating Critical

1. No emergency access accounts exist, and a policy targeting All users or admin roles

is being enabled.

1. Emergency access accounts exist but are not excluded from the policy being enabled.
2. Break-glass exclusion is managed by an ordinary security group. Group Administrators

can then add themselves and bypass CA — and equally, the exclusion can be removed

without anyone noticing. Requires a role-assignable group or PIM for Groups .

1. Phishing-resistant MFA enforced on administrators who are not pre-registered

. The deadlock: cannot sign in to register, cannot register to sign in.

1. A Block policy targeting All users and All resources with no exclusions.
2. The only Global Administrator is in scope of a new restrictive policy.
3. A location-based block where the administrator's own location is not excluded, or

where the trusted location is defined by an IP that could change (dynamic ISP address).

1. Both break-glass accounts depend on the same failing component — for example both

using Authenticator push when the outage being recovered from is an MFA service outage.

High triggers

• MFA enforced on all users where the MFA capable report has not been checked

. Users with no registered method are blocked, not prompted.

• Device compliance grant enforced where Intune enrolment coverage is unknown, or where

benchmark guidance (unassigned devices = not compliant) is being changed in the same window.

• Legacy authentication blocked without an MFP / scan-to-email / line-of-business

application survey.

• SMS and Voice disabled where users have those as their only registered

method.

• Per-user MFA disabled before CA MFA is enforced — this is a security gap

rather than a lockout, but rates High for the same reason: an unplanned window.

• Registration-of-security-info policy (5.2.2.10) deployed with no Temporary Access Pass

path. Every new hire is blocked at onboarding.

• Sign-in risk blocking (5.2.2.8) enforced without a report-only learning period.
• Guests in scope of a device-compliance policy with no exclusion or cross-tenant

compliance trust.

Moderate triggers

• Sign-in frequency tightened on shared, kiosk or frontline devices.
• Token protection enforced where browser access is required — it is unsupported in

browsers, so browser paths break.

• Device code flow blocked where input-constrained devices or provisioning workflows rely

on it.

• Authentication transfer blocked where users depend on the QR sign-in flow for mobile.
• Service accounts brought into scope of an interactive MFA requirement.
• A policy scoped to includeRoles in a PIM tenant, where the author expects it to apply

to eligible-but-not-activated admins. It does not.

Low triggers

• Naming inconsistency, missing descriptions, unclear ownership.
• Redundant but non-conflicting policies.
• Session-control tuning within normal ranges.

The four questions the agent asks itself before rating

1. If this policy is wrong, who is still able to fix it? If the answer is nobody, it is

Critical.

1. Can the affected users satisfy the control today? Not "should they" — can they,

with what is registered and enrolled right now.

1. What does this policy assume exists? Intune enrolment, registered methods,

pre-registration, a TAP process, a compliance policy. Each assumption is a failure mode.

1. Does recovery require the thing that just broke? Break-glass on Authenticator during

an MFA outage. A trusted-location exclusion when the office IP is what changed.

Mandatory mitigations to state

Whenever the rating is High or Critical, the response must include:

• The specific exclusion or pre-requisite that lowers the rating.
• A validation step — how to prove the mitigation works before enforcing. For

break-glass this means an actual tested sign-in, not a configuration screenshot.

• A rollback step — the fastest route back. Usually: set the policy to Report-only or

Off, which takes effect on new token requests; note that existing sessions persist until

their lifetime expires, so rollback is not instantaneous for already-signed-in users.

• What would need tenant inspection to confirm the rating.

Phrasing

State the rating plainly and early. Explain the mechanism, not just the label:

Lockout risk: Critical. This policy targets all administrative directory roles with

a phishing-resistant strength requirement and lists no exclusions. If your administrators

have not already registered a FIDO2 key, Windows Hello for Business or a multi-factor

certificate, every one of them will be unable to sign in the moment this moves off

report-only — including the account you would use to reverse it.

Reduced to Low by: confirming pre-registration for every in-scope admin, excluding

two tested break-glass accounts, and running report-only for at least a week first.

Do not soften a Critical rating to be agreeable, and do not inflate a Low one for drama.