Identity-provider outage readiness: test the route back into administration

The recovery runbook is in the company wiki. The emergency credentials are in the password vault. The incident bridge is in the collaboration suite. If all three require the identity provider that has failed, the recovery plan contains a circular dependency.

For the identity lead, outage readiness starts by proving a route back into administration. A document saying that an emergency account exists is not enough. An authorised person must be able to find the instructions, obtain the right authentication material, reach the required control plane and perform the repair under the failure conditions the plan claims to cover.

Specify what has failed

“The identity provider is down” is too broad for a useful exercise. A federation endpoint might be unavailable while the cloud directory remains healthy. A Conditional Access change might lock out administrators while ordinary users retain access. An MFA dependency might fail. The identity platform itself might be unavailable, removing options that work during a federation fault.

Choose one failure at a time and identify which route should still work. Draw the dependency chain in the operational runbook: administrator device, network, credential store, authentication method, directory, privileged role and target console. For each step, ask whether the same incident could make it unavailable.

Distinguish administrative recovery from business continuity. Restoring the ability to manage a tenant does not necessarily restore every application’s sign-in path. Some applications may continue existing sessions while rejecting new ones; others may need separate recovery steps. Establish actual behaviour through documentation and controlled tests rather than assuming a universal grace period.

Make the emergency route independent of the failed component

Microsoft’s Entra emergency-access guidance recommends at least two cloud-only accounts using the onmicrosoft.com domain, without federation or on-premises synchronisation. It recommends phishing-resistant passwordless authentication, such as FIDO2 passkeys, and excluding these accounts from Conditional Access policies that would block or restrict their emergency sign-in. It also calls for monitoring and regular validation of administrative access.

That design addresses particular dependencies. A cloud-only account can avoid a failed federated identity provider; it does not create a way around an outage of Entra itself. Keep that distinction in the recovery claim. An account with a different name but the same unavailable authentication path offers little additional resilience.

Secure the emergency authentication material so authorised staff can retrieve it without the failed service. Consider physical location, after-hours access, staff absence and the availability of a suitable device. A hardware authenticator locked in an office that the on-call administrator cannot enter is a dependency just as surely as a software vault.

Do not make emergency access an unobserved permanent shortcut. Define who may use it, what circumstances permit use and how an incident record identifies the human operator. Where a second person must authorise access, make sure that person can be reached through a channel independent of the failed identity path.

Walk through the first fifteen minutes

Use an approved exercise with a test environment or a tightly controlled production validation. Do not disable the production identity service merely to make the drill realistic. Withhold access to the failed dependency in the exercise and require participants to follow the documented alternative.

1. Declare the condition. Give the operator a specific symptom and scope. Can they distinguish an identity fault from an application or network fault without spending the recovery window on the wrong system?
2. Reach the people and instructions. Verify access to an offline or independently available runbook, current contact details and the incident communications channel.
3. Obtain emergency access. Use the approved custody and authorisation process. Confirm that the required device, authenticator and network path are available to the on-call team.
4. Perform a harmless administrative check. Demonstrate the permission needed for recovery without making a destructive change. Signing in to a portal is insufficient if the account cannot reach the relevant control.
5. Confirm the evidence. Establish that emergency use is logged and the responsible monitoring team receives the expected notification. If that monitoring path depends on the failed service, identify how evidence will be preserved and reviewed.

Time the whole sequence. The interval between declaring the fault and obtaining useful administrative access matters more than the login screen’s response time. Note delays caused by stale contact details, unclear authority and inaccessible equipment as recovery defects.

Practise returning to ordinary access

A recovery exercise should not finish when an administrator gets in. Confirm the repaired normal route, test the affected applications and remove temporary changes through the agreed process. Reconcile privileged actions with the incident record and review any credential exposure. Replace or rotate affected authentication material where necessary, without accidentally disabling the only remaining usable recovery path.

Check the state of the emergency accounts afterwards. They must remain usable for the next incident, protected from routine use and monitored. The same exercise should verify that a former administrator no longer retains access to stored material.

Changes to federation, MFA, network access or privileged roles should trigger a review of this route. An IAM migration can silently invalidate a once-successful drill by moving the vault or the approval process behind a new dependency.

Take the longest delay found in the exercise and repair it first. Then incorporate the tested access route, named responsibilities and recovery evidence into the incident response plan people will use during the outage. The useful outcome is a route an on-call administrator has demonstrated, with a clear statement of the failures it can and cannot overcome.