Break-glass access is a controlled emergency route for recovering administrative access when the normal route fails. Design it with a defined owner, strong authentication, limited permissions, immediate alerts and a tested closure process.

An emergency route becomes dangerous when it is an undocumented permanent bypass. Treat it as a separate operational capability and test the failure that it is supposed to survive.

Name the failure you need to survive

An upstream identity-provider outage, expired federation certificate and lost administrator authenticator are different failures. An emergency account that depends on the failed provider may not help during an outage.

Write down which dependency the route avoids and which controls still apply. Include tenant boundaries and the maximum actions the operator needs to restore service.

Failure	Design question
Federation configuration breaks	Can an authorized operator repair it without that connection?
Primary authenticator is lost	Which separately enrolled credential can recover access?
Privileged account is compromised	Can another approved operator revoke its access?
Application authorization fails	Is emergency access enforced outside the failed policy path?
Logging service is unavailable	Which evidence can still be captured safely?

Use provider guidance within its scope

Microsoft recommends emergency access accounts for its Entra environment, with controls for their use and monitoring. That provides a concrete example. Its account count, role assignments and policy exceptions are specific to that environment. They are not universal instructions for every SaaS product. Microsoft emergency-access guidance.

For your application, record the minimum necessary privileges and the reviewed authentication route. Keep normal administrator sign-in separate from the emergency procedure.

Protect the emergency credential

Prefer phishing-resistant authentication when the route supports it. Decide how custodians can access an enrolled credential during the failure. Separate everyday devices from emergency custody when your risk model requires that separation.

Synced passkeys and device-bound security keys have different recovery and custody dependencies. A hardware key can still be lost or unavailable. Test the complete route rather than treating the possession of a key as the entire control. Synced passkeys and hardware keys.

Avoid a shared everyday password with no attributable operator. Where shared custody is necessary, record the authorized person, approval and use event through a controlled process.

Require a bounded activation

Use the emergency-access drill worksheet to define the procedure.

Record the incident reference and failed dependency.
Confirm the operator's authority through the reviewed route.
Record any required independent approval.
Activate only the privileges needed for recovery.
Set a time limit for the emergency session.
Send the configured alert to an independent contact path.
Record the privileged changes and their results.

If dual approval is part of the policy, test the loss of one approver. Define the authorized alternative in advance. Avoid inventing a bypass during an incident.

Test an outage with synthetic accounts

In an isolated test environment, make the normal federation route unavailable. Use an application account with no customer data. Confirm that the emergency path succeeds only for the approved operator and intended tenant.

Attempt an ordinary sign-in through the same route. Attempt access from a second tenant. Confirm that neither gains emergency privileges.

Measure whether an alert arrives, whether evidence names the operator and whether the session expires as designed. Record actual results in the worksheet. These are acceptance tests for your implementation, not results claimed for an untested NamoID feature.

Close the route after recovery

Remove temporary permissions and terminate the emergency session. Review credentials exposed during use and rotate or replace them where required. Confirm that ordinary access works again before ending the incident.

Reconcile privileged actions with the incident record. Include any account, role, certificate or domain changes. Re-run the drill after a material authentication or policy change.

The admin-access guide covers routine operator permissions. The SSO readiness checklist places emergency access within the wider enterprise integration.

Review emergency access with NamoID

NamoID engineers can help review authentication dependencies, session boundaries and recovery tests. A complete break-glass procedure also needs application authorization, operational custody and alerting owned by your team.

Bring a synthetic outage scenario and the required administrator actions to Slack for an early response. Contact the NamoID team