Conditional Access foundations: break-glass accounts, exclusion groups, and the logging you want before any policy

Entra ID  ·  Conditional Access  ·  Break-Glass  ·  2026

Conditional Access Baseline Series  ·  Part 2 of 4

Series progress

Part 1

Baseline overview

Part 2  · You are here

Foundations: break-glass & logging

Part 3  · Coming soon

The 8 policies — deep implementation guide

Part 4  · Coming soon

Report-only rollout & troubleshooting

Before you deploy a single Conditional Access policy, three things have to be in place: two break-glass accounts with phishing-resistant MFA, a clean exclusion group pattern, and sign-in logs wired to real alerts. This is the Part 2 deep dive — the setup that stops a misconfigured policy from turning into a business-hours incident, and that every auditor is going to ask about sooner or later. Skip any of it and you are borrowing trouble from your future self.

🔑

Two break-glass accounts, not one. Redundancy matters when the failure mode is "the FIDO2 key broke" or "the admin who knew the recovery path left the company"

🏢

Break-glass accounts live on .onmicrosoft.com, not your custom domain. Custom domains can be caught up in federation or sync states that interfere in an emergency

📋

Exclusions are groups, never individual users. CA-Exclusions-BreakGlass, CA-Exclusions-ServiceAccounts, CA-Exclusions-Travel — each documented, each reviewed

📊

Sign-in logs go to Log Analytics, not just stay in Entra. Portal retention is fine for short-term investigation, but usually insufficient for audit history and longer incident review

🚨

Any break-glass sign-in is an incident. These accounts should sign in twice a year for verification — every other sign-in gets investigated

This is the least glamorous article in the series, and the most important one. The policies in Part 3 are easy to write and easy to get wrong. What makes the difference between a clean rollout and a two-day outage is whether the foundations are already in place when the first policy goes live.

Three sections cover those foundations: break-glass accounts (the full setup, not the summary), exclusion groups (the naming pattern and review cadence), and logging and alerting (sign-in logs, audit logs, the Log Analytics wiring, and the alert rules that actually matter). One additional section covers pre-deployment hygiene — the state the tenant should be in before Policy 1 goes into Report-only.

🛑

If you already have Conditional Access policies deployed without break-glass, stop reading linearly and implement the break-glass setup first. Every additional day without them is a day you are one misconfigured policy away from calling Microsoft support at midnight. The setup below is usually quick to implement, but do not rush the testing and documentation.

On this page

Break-glass accounts — full setup The exclusion group pattern Sign-in logs & Log Analytics Audit logs & CA change detection Pre-deployment hygiene Foundations checklist

Break-glass accounts — the complete setup

Break-glass accounts exist for exactly one scenario: you deployed a Conditional Access policy that locks out every admin in the tenant, including yourself, and you need to sign in to fix it. That scenario happens. It happens to consultants who know what they are doing. The only question is whether you are ready for it.

The shape of a defensible setup is six decisions made correctly. Each one has a wrong version that looks fine until the moment you actually need the account.

1

Create two cloud-only accounts on .onmicrosoft.com

Go to Entra ID → Users → New user → Create new user. Name them breakglass-01 and breakglass-02. Use the default @yourtenant.onmicrosoft.com domain, not your custom domain. The reason: custom domains can be federated to on-premises AD FS, can be in the middle of a domain migration, or can be affected by Entra Connect sync states that break sign-in at exactly the wrong moment. The .onmicrosoft.com domain is always cloud-native and is always there. Set a 32+ character random password, generated by a password manager, stored in two physically separate secure locations (two safes, or a safe and a director's sealed envelope in a lockbox). They usually do not need workload licences such as Exchange or Teams — keep them as lean as possible. Do not add them to distribution lists. Set "usage location" to your primary country if required for compliance, otherwise leave blank.

2

Register two FIDO2 security keys per account

Phishing-resistant MFA is the only factor acceptable here. SMS, voice call, authenticator push, even authenticator number-match are all off the table. Use FIDO2 security keys (YubiKey 5 series, Feitian ePass FIDO2, Thetis FIDO2, any FIDO2-certified hardware key) or passkeys on a corporate-managed hardware token. Two keys per account, stored separately: key A in the office safe, key B in a director's secure location or at a named officer's home safe. Register them via https://aka.ms/mysecurityinfo while signed in as the break-glass account itself. Test sign-in with each key immediately. Label the keys physically with "BG-01-A", "BG-01-B", "BG-02-A", "BG-02-B".

3

Assign permanent Global Administrator, not PIM

This is the counterintuitive one. Best practice for every other admin account is to use Privileged Identity Management and elevate on demand. Break-glass is the one exception. PIM activation requires the user to complete an MFA and often a Conditional Access flow — which is precisely what you may be locked out of. In the exact emergency break-glass exists for, PIM will not rescue you. Go to Entra ID → Roles and administrators → Global Administrator → Add assignments → Active → pick both break-glass accounts → set duration to Permanently assigned. Document the two permanent Global Admins in your privileged access runbook so auditors know they exist on purpose.

4

Create the exclusion group and add both accounts

Entra ID → Groups → New group → Security → Name: CA-Exclusions-BreakGlass → Membership type: Assigned → add both break-glass accounts as members. Add a group description: "Excluded from ALL Conditional Access policies. Reviewed annually by IT Lead. Contains only break-glass accounts." That description is your paper trail when someone asks why these accounts are exempt. Every Conditional Access policy you create from now on references this group under Users → Exclude → Groups. Never individual users. If you do it with a group, you cannot forget one of the accounts when adding a new policy.

5

Wire sign-in alerting via Log Analytics

Entra ID → Monitoring → Diagnostic settings → Add diagnostic setting → send SignInLogs and AuditLogs to a Log Analytics workspace. In that workspace, create an alert rule (Alerts → New alert rule → scope: LAW → condition: custom log search) using the KQL query below. Action group notifies the IT Lead's mobile and email. Threshold: one record in any 15-minute window. See the KQL snippet in the next code block.

6

Document, store, test twice a year, rotate annually

One-page runbook kept in both the IT folder and the physical safe: account names, key storage locations, who can authorise use, the sign-in test procedure. Two scheduled tests per year (e.g., first Monday of January and July) — a named engineer signs in with each break-glass account using one of its FIDO2 keys, verifies Global Admin access to Entra and Exchange admin centres, signs out. Annually, rotate the long random password and re-register the FIDO2 keys. Document every test in the runbook's test log with date, engineer, and outcome.

KQL — alert on any break-glass sign-in Log Analytics / KQL

// Run in the Log Analytics workspace receiving SignInLogs
// Use in an Azure Monitor alert rule: threshold = any row in 15 min window
SigninLogs
| where UserPrincipalName in~ (
    "breakglass-01@contoso.onmicrosoft.com",
    "breakglass-02@contoso.onmicrosoft.com"
  )
| project TimeGenerated, UserPrincipalName, ResultType,
           IPAddress, AppDisplayName, Location, ClientAppUsed
| order by TimeGenerated desc

⚠️

Alert on success and failure. A failed sign-in to a break-glass account is as interesting as a successful one — it may mean someone has the username and is trying to guess the password. The KQL above does not filter on ResultType; that is deliberate.

The exclusion group pattern

A Conditional Access policy without exclusions applies to everyone assigned to it. Reality is messier than that: service accounts, roaming executives, temporary contractors, third-party integrators. The question is not whether to have exclusions — it is whether your exclusion pattern is defensible six months from now when an auditor asks why finance@contoso.com is exempt from Policy 4.

The pattern is simple: exclusions are always groups, named predictably, with documented reasons and review dates. Individual user exclusions are technical debt that auditors hate and that you forget about.

Group 1

CA-Exclusions-BreakGlass

Two break-glass accounts. Excluded from every policy without exception. Review annually. Members never change except for scheduled key rotation.

Group 2

CA-Exclusions-ServiceAccounts

Non-human identities that genuinely cannot meet the policy (rare — most should be migrated to modern auth or moved to workload identities). Document the reason per account. Review quarterly. Goal: size trends to zero.

Group 3

CA-Exclusions-Travel

Users travelling outside your allowed countries. Used by the location-block policy. Membership is time-limited — added before travel, removed on return. Owner is the Exec Assistant or HR. Review monthly.

Group 4

CA-Exclusions-TempAccess

Short-term contractors or auditors who need an approved exemption from a specific policy. Every membership has a ticket number, a reason, and an automatic review date in 30 days. Review weekly.

Three operational rules keep this pattern clean. First, each exclusion group carries its purpose in its description: "Members are automatically blocked from Policy 6 (unexpected countries). Owner: HR. Reviewed monthly." The description is your audit trail. Second, use Entra ID access reviews on the exclusion groups — especially Travel and TempAccess, where membership should churn. Third, resist the temptation to create ad-hoc exclusion groups for one-off situations. If you find yourself wanting to, the question is usually whether the policy itself needs tuning, not whether another group needs carving out.

Sign-in logs and Log Analytics

Entra ID keeps sign-in logs for 30 days for tenants with Entra ID P1 or higher. That is enough for tactical investigation, not for audit, incident forensics, or trend analysis. The answer is to stream the logs to a Log Analytics workspace — and, if you use Microsoft Sentinel, to Sentinel on top of that.

1

Create or select a Log Analytics workspace

Azure portal → Log Analytics workspaces → Create. Pick a region close to your tenant's primary location. Name convention: law-<tenant>-security. Keep it in a subscription dedicated to security / management resources if you can — it protects the workspace from accidental deletion during project cleanups.

2

Set retention to 90 days minimum, 365 preferred

Log Analytics workspace → Settings → Usage and estimated costs → Data Retention. 31 days is the free allowance; past that you pay per GB. For an SMB tenant the cost is usually a few tens of EUR per month and well worth it for auditability.

3

Stream Entra ID logs to the workspace

Entra ID → Monitoring → Diagnostic settings → Add diagnostic setting. Enable at minimum: SignInLogs, AuditLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs. Destination: the Log Analytics workspace. If you have Entra P2, also include RiskyUsers and UserRiskEvents.

4

Create the first four alert rules

Break-glass sign-in (KQL above), Conditional Access policy change (KQL in the next section), Global Admin role assignment (any change), and legacy authentication used post-policy-enforce. Route all four to an Azure Monitor action group that notifies the IT Lead.

The first alert pays for the workspace on day one. The others accumulate value as your baseline matures. Six months in, the Log Analytics workspace will be the single most useful tool you have for demonstrating identity hygiene to anyone who asks.

Audit logs and CA change detection

Audit logs capture administrative changes: who modified which Conditional Access policy, who assigned a role, who added a member to a group. For a baseline rollout, the one alert that matters most is "someone modified a Conditional Access policy". During rollout you want to know every time; post-rollout you want to know because unplanned CA changes are a sign of either sloppy change control or a compromise.

KQL — alert on any Conditional Access policy change Log Analytics / KQL

AuditLogs
| where Category == "Policy"
| where OperationName has "conditional access"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, Result, Actor, TargetResources
| order by TimeGenerated desc

Run that as a saved query in the workspace, and turn it into an alert rule with a 15-minute evaluation window. Combined with regular JSON exports of the full policy set (see the Graph PowerShell snippet in Part 1), you have a complete audit record: every change timestamped, every policy state recoverable, every actor identified.

Pre-deployment tenant hygiene

Four quick checks before Policy 1 goes into Report-only. Each of them turns up data that changes how you deploy.

Check 1

Legacy auth usage

Entra ID → Monitoring → Sign-in logs → Filter on "Client app" = "Other clients" or "IMAP4" / "POP3" / "SMTP AUTH". Every row is an account or device that will break when Policy 1 enforces. Address them before, not during, rollout.

Check 2

MFA registration status

Entra ID → Protection → Authentication methods → User registration details. Export users without any MFA method registered. Either nudge them to register or plan a staged rollout that warms them up.

Check 3

Admin devices are Intune-managed

Every admin who will be hit by Policy 4 needs an Intune-enrolled, compliant device. Verify in Intune → Devices → filter on users in admin roles. Non-compliant = planned exclusion until fixed.

Check 4

Security Defaults state

Entra ID → Properties → Manage security defaults. Record the current state. Plan to disable it after Policy 2 (MFA all users) is enforced and stable — never before, never simultaneously both.

For the MFA registration check, if you prefer Graph PowerShell over the portal:

Export users without MFA registered PowerShell

Connect-MgGraph -Scopes "AuditLog.Read.All","UserAuthenticationMethod.Read.All"

Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
  Where-Object { -not $_.IsMfaRegistered -and $_.UserType -eq "member" } |
  Select-Object UserPrincipalName, UserDisplayName, UserType, IsMfaCapable |
  Export-Csv -Path ".\mfa-unregistered-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

Foundations checklist

• Two break-glass accounts created on .onmicrosoft.com, with no unnecessary workload licences assigned, 32+ char password stored in two safe locations Test sign-in with password alone confirmed before adding MFA.
• Two FIDO2 keys per break-glass account, physically labelled, stored in two separate secure locations Sign-in with each key verified at least twice.
• Both break-glass accounts permanently assigned Global Admin (not via PIM) Listed in the privileged access runbook.
• CA-Exclusions-BreakGlass group created, both accounts added, described Description includes owner, review cadence, and purpose.
• Exclusion groups for ServiceAccounts, Travel, TempAccess created with documented owners Empty is fine — the groups must exist before the policies reference them.
• Log Analytics workspace created, 90+ day retention, Entra diagnostic settings streaming SignInLogs, AuditLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs minimum.
• Alert rule on break-glass sign-in live, tested with a manual sign-in Action group routes to IT Lead mobile + email.
• Alert rule on Conditional Access policy changes live Baseline period captured: any future change shows as a diff.
• Pre-deployment hygiene checks completed: legacy auth, MFA registration, admin device state, Security Defaults Reports exported and archived; remediation planned where needed.
• Runbook written: break-glass accounts, key locations, test schedule, rotation schedule Stored in IT folder and physical safe. First test scheduled.

Next in the series  ·  Part 3 of 4

The 8 policies — deep implementation guide

With the foundations in place, Part 3 goes significantly deeper than the Part 1 overview: exact UI path per policy, precise include/exclude scope, grant vs session trade-offs, common false positives and how to triage them in the sign-in logs, and the rollback pattern for each one.

Coming next →

Need a hand

Want someone to validate your break-glass and logging setup?

If you want an independent review of the foundations — break-glass configuration, exclusion group hygiene, Log Analytics wiring, alert rules — before you start deploying policies, that is part of what an Entra ID hardening review covers. Get in touch.

Sources

References used

• Microsoft Learn — Emergency access admin accounts
• Microsoft Learn — Enable FIDO2 security keys
• Microsoft Learn — Stream Entra ID logs to Log Analytics
• Microsoft Learn — Create log search alert rules
• Microsoft Learn — Privileged Identity Management
• Microsoft Learn — Authentication methods activity report
• CISA — Implementing phishing-resistant MFA