Resilience and contingency policies

Backup policies held in reserve for an outage, and how to degrade without going open.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Resilient access control and contingency policies

Source: Create a resilient access control management strategy

· doc date 2025-03-04, updated 2026-06-15 · retrieved 2026-07-28

benchmark guidance does not cover this at all. It is the strongest differentiator available to the agent

for the rollout-planning scenario, because almost nobody does it.

Microsoft's four key takeaways

1. Avoid administrator lockout by using emergency access accounts.
2. Implement MFA using Conditional Access rather than per-user MFA.
3. Mitigate user lockout by using multiple Conditional Access controls.
4. Mitigate user lockout by provisioning multiple authentication methods or equivalents

for each user.

Two failure modes are named: administrator lockout (can't manage the tenant) and

user lockout (can't reach apps).

Mitigation vs contingency — two different strategies

• Mitigation = the design survives a single control failing, automatically. Achieved by

giving users a choice of controls.

• Contingency = pre-built backup policies, held in reserve, enabled manually during an

outage.

An organisation should pick one deliberately. The agent should ask which, rather than

assuming.

Mitigation: give users a choice of controls

Use Conditional Access policies with multiple controls to give users a choice of how they

access apps and resources... if one of the access controls is unavailable the user has

other options to continue to work.

Microsoft's recommendations:

• Provision **multiple authentication methods per user across different communication

channels** — Authenticator (internet), OATH token (on-device), SMS (telephonic). Different

channels, so one outage does not take them all.

• Deploy Windows Hello for Business so device sign-in itself satisfies MFA.
• Use trusted devices (hybrid join or Intune). A trusted device can satisfy the strong

authentication requirement without an MFA challenge; MFA is then required when enrolling

a new device or accessing from untrusted devices.

• Use risk-based policies instead of fixed MFA policies (requires P2).
• If protecting VPN with the MFA NPS extension, consider federating the VPN as a SAML app.

Microsoft's mitigation policy pair

Groups: AppUsers (target users), CoreAdmins, EmergencyAccess.

• Policy 1 — Block everyone outside the target groups

Include all users; exclude AppUsers, CoreAdmins, EmergencyAccess · All apps · no

conditions · Block

• Policy 2 — Grant AppUsers with a choice

Include AppUsers; exclude CoreAdmins, EmergencyAccess · All apps · no conditions ·

Grant: require MFA, require compliant device, Require one of the selected controls

Note this is Microsoft deliberately using OR for resilience. It is the same construction

benchmark guidance warns about for the MFA-plus-device case. See

benchmark guidance-vs-microsoft-reconciliation.md — the agent must handle this tension honestly rather

than parroting one source.

Note also Policy 1: the explicit Block for everyone else, which is the deny-by-exception

principle applied.

Contingency policies

A contingency Conditional Access policy is a backup policy that omits Microsoft Entra

multifactor authentication, third-party MFA, risk-based or device-based controls. In order

to minimize unexpected disruption when a contingency policy is enabled, the policy should

remain in report-only mode when not in use.

Microsoft's explicit warning: *disabling policies that enforce security on your users, even

temporarily, will reduce your security posture while the contingency plan is in place.*

Planning questions Microsoft says to answer in advance

1. Categorise your applications:

Microsoft is explicit that business, security, legal and leadership stakeholders must all

agree this list in advance.

2. For categories 1 and 2, pre-decide the level of access:

• Full access or restricted session (e.g. limiting downloads)?
• Part of the app or the whole app?
• Allow information-worker access but block administrator access until controls are restored?

3. Pre-decide which avenues you open and close:

• Browser only, blocking rich clients that can save offline data?
• Corporate network only?
• Certain countries only?
• Should contingency policies fail or succeed when an alternative control is unavailable?

Fallback design patterns

• Configure a policy requiring Domain Join in report-only as a backup for an active

policy that requires a third-party MFA provider.

• Deploy SSPR and Password Protection so passwords are stronger during any window

where MFA is not required.

• Restrict within the app rather than falling back to full access. Examples: send the

restricted-session claim to Exchange and SharePoint; or fall back to a Defender for Cloud

Apps policy allowing read-only but not uploads.

That last point is the sophisticated one — degrade the session, do not remove the control.

Contingency naming

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

Elements: label number · ENABLE IN EMERGENCY · the disruption it applies to · sequence

number showing activation order · apps · controls · conditions.

Worked example A — MFA provider outage

Normal state: MFA required for all Exchange Online and SharePoint Online access.

Disruption: the MFA provider is down. Groups: ContingencyAccess, CoreAdmins,

EmergencyAccess, named location CorpNetwork. Four policies, all held in Report-only:

Activation order matters and Microsoft specifies verification at each step:

1. Exclude ContingencyAccess, CoreAdmins, EmergencyAccess from the existing MFA policy;

verify a ContingencyAccess user can reach SharePoint and Exchange.

1. Enable Policy 1; verify domain-joined non-excluded users get access, excluded users get

access from any device.

1. Enable Policy 2; verify non-excluded users are blocked from mobile, excluded users are not.
2. Enable Policy 3; verify non-excluded users are blocked off-network even on a domain-joined

machine.

1. Enable Policy 4; verify no one reaches Exchange from native mobile mail apps.
2. Disable the existing MFA policy for SharePoint and Exchange.

The pattern: narrow the population, narrow the platform, narrow the network, close the

legacy path — then remove the control you can no longer satisfy. The compensating controls

go up before the primary control comes down.

Worked example B — device compliance evaluation outage

Normal state: Salesforce from mobile requires a compliant device. Two policies:

1. EM001 - ENABLE IN EMERGENCY: Device Compliance Disruption[1/2] - Salesforce - Block All users except SalesforceContingency
2. EM002 - ...[2/2] - Salesforce - Block All platforms except iOS and Android

Same shape: restrict who and restrict from where, then drop the failing control.

Hybrid resilience — password hash sync

User lockout also occurs when the organisation uses pass-through authentication or

federation and the on-premises identity system is unavailable.

Enable password hash sync using the Microsoft Entra Connect wizard, **regardless of whether

your organization uses federation or pass-through authentication**.

Microsoft is explicit: *it isn't required to convert users from federated to managed

authentication to use password hash sync.* Enabling PHS gives you the option to switch if

on-premises goes down. This is cheap insurance and frequently not done.

During a disruption

1. Enable contingency policies.
2. Disable the regular control-based policies.

Microsoft's cautions while operating degraded:

1. Document every change and the previous state as part of change control, so you can

roll back.

1. Assume attackers will harvest passwords through password spray or phishing while MFA

is off, and that they may already hold passwords that previously granted nothing. For

critical users such as executives, partially mitigate by **resetting their passwords

before disabling MFA for them**.

1. Archive all sign-in activity to identify who accessed what during the window.
2. Triage all risk detections reported during the window.

After a disruption

1. Enable the regular policies.
2. Return contingency policies to report-only.
3. Roll back other documented changes.
4. If an emergency access account was used, regenerate its credentials and physically

secure the new details.

1. Continue triaging risk detections for suspicious activity.
2. Revoke all refresh tokens issued to the affected users — especially privileged

accounts used during the disruption — forcing reauthentication against the restored

policies.

Step 6 is the one that gets forgotten. Without it, sessions established under degraded

controls persist after the controls come back.

Emergency options with no plan in place

If per-user MFA legacy policies are in use and nothing was prepared:

• Add the corporate outbound IP addresses as trusted IPs to allow authentication only

from the corporate network.

• If the outbound IP inventory is unknown, the entire IPv4 space can be added as trusted by

specifying 0.0.0.0/1 and 128.0.0.0/1.

Microsoft's warning, which the agent must always repeat with this: broadening trusted

IPs means **risk detections associated with IP addresses — impossible travel, unfamiliar

locations — will not be generated.** You are turning off the detection as well as the

control. Trusted IPs for MFA require P1 or P2.

The agent should present this as a genuine last resort with the detection loss stated, not

as a tidy workaround.

NPS extension contingency (on-premises VPN / RDG)

If MFA for on-premises resources uses the NPS extension, decide in advance whether you are

prepared to disable MFA in an emergency.

To disable: back up HKLM\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters, delete the

AuthorizationDLLs and ExtensionDLLs values (not the Parameters key), restart the Network

Policy Service (IAS), confirm primary authentication succeeds.

To re-enable: import the backed-up key, restart IAS, confirm primary and secondary

authentication, then **review NPS and VPN logs to establish who signed in during the

emergency window**.