7 Break-Glass Cloud Access Controls That Keep You Online

Break-glass cloud access is the small set of standalone, highly privileged accounts you keep for the day your normal identity path fails: the identity provider is down, MFA is unreachable, or the administrators who hold standing rights are unavailable. Done right, it works when everything else is broken and trips an alarm the moment it is used. Done wrong, it is a permanent administrator password sitting in a drawer.

The seven controls below cover the full lifecycle: creation, authentication, policy interaction, monitoring, and periodic proof that the account still works. They draw on AWS Well-Architected break-glass guidance and Microsoft Entra ID emergency access recommendations, with implementation notes from incident practice.

Why break-glass exists

Break-glass accounts exist because every control that protects administrator access can also become the thing that blocks it. Microsoft documents the failure scenarios directly: federated sign-in breaks when the identity provider host goes down, MFA becomes impossible when the network that delivers codes is unavailable, the last Global Administrator leaves the organization, or every privileged role assignment is eligible instead of active and no approver is reachable to activate it. AWS describes the same class of events — identity provider failure, security incidents, unavailability of key personnel — as the reason to maintain temporary elevated access beyond regular permissions. The account is not a convenience; it is the last working key to the building.

Redundancy is the first decision. Microsoft recommends maintaining at least two emergency access accounts so a single damaged or lost credential cannot lock the organization out. Two credentials stored in separate locations and held by different people mean a lost safe key or a failed hardware token degrades your recovery path instead of destroying it.

Seven controls that matter

Two rows deserve explanation. Excluding emergency accounts from Conditional Access feels wrong — it looks like punching a hole in zero trust — but the exclusion only concerns policies that block sign-in, while report-only policies do not require it. Microsoft warns that an emergency account subject to a Conditional Access policy requiring MFA or a compliant device might be unusable during the exact emergency it was designed for. The phishing-resistant credential registered on the account is the compensating control. On role assignment, Microsoft is equally specific: in Privileged Identity Management the Global Administrator assignment for these accounts must be active and permanent, not eligible, because an eligibility-and-approval chain depends on exactly the people and systems an outage removes.

Monitoring is what separates a governed break-glass process from a shared password. AWS Well-Architected guidance is explicit that break-glass roles must use hardware-based MFA and that every use fires an alert tied into incident response. Configure alerts on sign-in and audit logs for the accounts, page the on-call security lead, and open an incident record automatically so that every activation is explained by a ticket.

The credential storage trade-off

Where the credential lives matters as much as what it is. Microsoft’s guidance is physical and blunt: keep credentials in secure, fireproof safes in separate locations, accessible to more than one authorized person, and change safe combinations when someone with access leaves. There is a real trade-off between shared and individual emergency accounts. A single shared pair is simpler to protect and audit as an object, but weakens per-person accountability; per-administrator emergency accounts give you accountability and remote-use capability at the cost of more standing secrets. Either way, the credentials must not live on employee devices, must not expire, and must stay out of automated cleanup that deletes unused accounts — an emergency credential used twice a year is, by design, exactly the kind of account that hygiene tooling will flag. Require a designated secure workstation for use, so the break-glass session never runs from a random laptop.

Testing and post-use review

Break-glass that has never been tested is fiction. Microsoft’s own guardrail summary calls for validating account functionality at least every 90 days, not just reviewing a checklist on paper. A real drill signs in with the stored credential, performs an administrative task, confirms the monitoring alert fired, and updates the list of authorized holders. Run the same drill after key changes too: staff departures, a new identity provider, or a Conditional Access redesign are the moments exclusions silently break.

After any real use, run a post-mortem. Pull sign-in and audit logs for the account, compare the actions taken against the incident authorization, and record whether the use was justified. This closes the governance loop for auditors in regulated industries and gives you evidence that the loudest account in the environment behaved as designed. Teams that already run pipeline guardrails can fold break-glass review into the same cadence they use for their CI/CD hardening checklist.

Failure modes to avoid

• Convenience drift: the break-glass account becomes the admin login people grab when normal access is merely slow.
• Silent expiry: password rotation or device-cleanup automation disables an unused account nobody missed.
• Single custody: one person holds both credentials and both safe combinations.
• Policy drift: a Conditional Access redesign removes the exclusion and nobody notices until the outage.
• Wrong problem: if the “emergency” is really over-granted third-party access, an OAuth grant audit fixes more than a break-glass login ever will.

Sources

• AWS Well-Architected — [AG.SAD.5] Implement break-glass procedures
• Microsoft Learn — Manage emergency access accounts in Microsoft Entra ID