Conditional Access, PIM and break-glass accounts: the checklist

Before you start

Conditional Access needs a premium Entra ID licence, and PIM and risk-based policies need a higher tier or Entra ID Governance. Licensing changes, so confirm the current position with Microsoft for every user and admin in scope before you plan.

• Check whether security defaults are on, and plan to turn them off at the point your first Conditional Access policies are enforced, because the two cannot run together.
• List every account that holds an admin role, including service accounts and accounts used by suppliers.
• Identify accounts that cannot complete MFA, such as scanners, shared mailboxes with sign-in enabled and older integrations.
• Review the sign-in logs to find which apps and accounts still use legacy authentication.
• Name an owner for identity security and a deputy, and agree who approves policy changes.

Break-glass accounts

Emergency access accounts exist for when normal admin sign-in fails: an MFA outage, a federation problem, or a Conditional Access policy that blocks everyone. They have to work when nothing else does, and because they are powerful they have to be watched closely. Create them first, before any policy is enforced.

• Create at least two cloud-only accounts on the onmicrosoft.com domain, not synced from on-premises and not federated.
• Assign Global Administrator to them permanently, not as an eligible PIM assignment.
• Protect them with phishing-resistant authentication, such as FIDO2 security keys, stored in separate secure locations.
• Avoid tying them to any named person's phone, mailbox or device.
• Exclude them from Conditional Access policies that could lock them out, and record each exclusion.
• Alert on every sign-in by either account, and route the alert to more than one person.
• Test sign-in to each account on a fixed schedule and record the result.
• Write down when the accounts may be used, who may use them, and what happens afterwards.

Conditional Access foundations

Build every policy in report-only mode first. Report-only evaluates the policy at each sign-in and records what would have happened without enforcing it. Review the results in the sign-in logs or the Conditional Access insights workbook before you switch a policy on.

• Adopt a naming convention that shows the policy number, who it targets and what it does.
• Exclude the break-glass accounts from every policy through a dedicated exclusion group, and monitor that group's membership.
• Block legacy authentication for all users.
• Require MFA for all users on all cloud apps.
• Require phishing-resistant MFA for admin roles using authentication strengths.
• Require MFA for access to Azure management.
• Decide how guests are treated, and require MFA for them as a minimum.
• Test each policy against named users with the What If tool before enforcing it.

Device and location controls

Once the identity basics are enforced, add conditions about the device and the context of the sign-in. These depend on how well your devices are managed, so be honest about the state of Intune enrolment before relying on compliance.

• Decide whether unmanaged devices get full access, browser-only access or none, app by app.
• Require a compliant or hybrid joined device for admin roles where your device estate supports it.
• Define named locations for trusted networks, but never treat a location as a substitute for MFA.
• Block countries you have no reason to see sign-ins from, after checking the logs for genuine travel and suppliers.
• Use session controls, such as sign-in frequency, for admin portals and unmanaged devices.

Privileged Identity Management

PIM turns admin rights into something people activate when they need them, for a limited time, rather than hold permanently. It only helps if the standing assignments are actually removed.

• Convert standing admin assignments to eligible assignments, except for the break-glass accounts.
• Assign the least privileged built-in role for each task, such as User Administrator or Exchange Administrator, instead of Global Administrator.
• Keep the number of Global Administrators small, and give each admin a separate admin account rather than elevating their everyday account.
• Require MFA and a justification on every activation.
• Require approval for activating Global Administrator and Privileged Role Administrator.
• Set activation durations to the shortest period that allows the work.
• Send activation notifications to the identity security owner.
• Bring Azure resource roles under PIM as well as Entra ID roles.
• Run regular access reviews on privileged roles, and remove eligibility from anyone who no longer needs it.

Monitoring and maintenance

Policies drift. Exclusions get added during incidents and never removed, and new apps arrive outside the original scope. Treat this as an ongoing control with a routine, not a project with an end date.

• Send sign-in and audit logs to a Log Analytics workspace or your SIEM so you keep them beyond the default retention.
• Alert on changes to Conditional Access policies, PIM settings and the break-glass exclusion group.
• Review failed and report-only sign-ins after every policy change.
• Review all policy exclusions quarterly, and remove any without a current owner and reason.
• Retest break-glass sign-in after any change to authentication methods or Conditional Access.

Rolling out to users

Most Conditional Access problems that reach the service desk are not technical. They come from people being asked for MFA they did not expect, or being blocked on a device they have always used. A little preparation removes most of them.

• Make sure users have registered MFA methods before enforcing a policy that requires them.
• Tell staff what will change, when it will change, and what to do if they are blocked.
• Enforce each policy in waves, starting with IT, then a pilot group, then everyone.
• Brief the service desk on reading Conditional Access results in the sign-in logs.
• Keep a rollback step for every policy, which is usually switching it back to report-only.

What usually goes wrong

The most damaging mistake is enforcing an all-users policy before the break-glass accounts exist and are excluded. The next is a break-glass account that nobody can actually use, because the key is lost or the password was stored somewhere that needs the account to reach it.

After that come service accounts that break when MFA is enforced, and admins who activate the maximum PIM duration every morning, which recreates standing access with more steps. Exclusions added during an incident and never removed are a quieter problem, but they slowly turn a policy that covers everyone into one that covers most people. Each of these is avoidable by working through the steps above in order, testing them, and reviewing them on a schedule.