Break Glass Access Procedure Template: Using Emergency Accounts Safely and Auditably

An emergency account is the most powerful credential an organisation owns, and the moment it is used is when controls are weakest: normal sign-in is broken, people are under pressure and nobody is sure who approved what. This template gives [Organisation] a step-by-step procedure for using break-glass accounts: when use is allowed, who approves it, how the credential is retrieved, what is monitored while it is open, and how the account is reset and reviewed afterwards. How to design those accounts (how many, which roles, which authentication method, where to store them) is covered in the Break-Glass Account Guide; this page is the runbook. It is written for identity administrators, security operations and incident managers, and uses Microsoft Entra ID and the AWS root user as worked examples. Replace every [bracketed] placeholder.

How to use this template

• Complete the register first: section 2.2 lists every emergency account, where its credential parts are kept and who holds them. Without it the procedure cannot run.
• Treat every use as an incident: planned drills, real emergencies and misuse all follow sections 3 to 8. Microsoft's guidance asks for a post-mortem after every alert on an emergency account to decide which of the three it was.
• Print it: keep a copy in each safe that holds a credential part, because the wiki may sit behind the identity provider that has just failed.
• Owner and review: [Head of Identity], reviewed every [90] days with the account validation in section 8.3, and after any staff change among credential holders.

1. Scope and triggers

1.1 This procedure covers emergency access accounts for [Microsoft Entra ID tenant(s), AWS management and member accounts, Google Cloud organisation, on-premises Active Directory, PAM vault, network devices]. Microsoft recommends keeping on-premises emergency access separate from cloud emergency access with no dependency between them, so list each environment's accounts separately.

1.2 Permitted triggers. Use is allowed only when one of these applies and normal privileged access has been tried and failed:

1.3 Not permitted: convenience, avoiding a PIM activation or approval workflow, routine changes, or any task a named admin account can perform.

2. Roles and contacts

2.1 Split knowledge. No single person holds every part of a credential. AWS describes this for the root user: one group holds the password and another holds the MFA device, and one member of each must come together to sign in. AWS also recommends separating the root email inbox and recovery phone between two groups.

2.2 Emergency account register:

3. Detection and triage

1. Raise the request on [out-of-band channel] with: requester, trigger from 1.2, the exact task, systems affected and expected duration. Record it in [ticket system or paper log if the ticket system is down].
2. Confirm normal access has failed: the Approver checks that a named admin account cannot do the task, for example by asking a second administrator to try.
3. Approve with limits: the Approver records approval time, a time box (default [60] minutes) and the allowed actions.
4. Warn the SOC: the Witness tells the SOC that an approved use is starting and gives the ticket number, so the alert is matched rather than escalated as an attack.
5. Unexpected alert: if the SOC sees an emergency account sign-in with no approved request, go straight to section 4. Treat it as compromise (ATT&CK T1078.004 Valid Accounts: Cloud Accounts) until proven otherwise.

4. Containment

4.1 Approved use, controlled session.

1. Credential holders retrieve their parts from separate safes and bring them to the designated secure workstation or privileged access workstation. Microsoft requires a designated secure workstation for any use of these accounts. See the Privileged Access Workstations Guide.
2. The Requester signs in with the Witness present. The Witness logs each action with a timestamp.
3. Perform only the approved task. Any further task needs a new approval entry.
4. Do not create new standing admin accounts, role assignments or access keys from the emergency session unless that is the approved task; these are classic persistence moves (T1098.003 Additional Cloud Roles).
5. Sign out, and return the credential parts to their safes. Each holder records the return time.

4.2 Unapproved use. The SOC and Incident Manager act in this order: confirm the account cannot be used by an approved holder at that moment; revoke sessions and reset the credential from a second emergency account or a trusted admin; check for new role assignments, federation changes, Conditional Access edits, new app credentials and new access keys made during the session; open the main incident under the Incident Response Plan Template.

5. Eradication

5.1 After every use, approved or not, the credential is considered exposed. Within [24] hours:

• Password: generate a new random password, split it again between holders, and update the register.
• FIDO2 key or certificate: where the key left the safe for an unapproved use, remove it from the account and register a replacement. For an approved use, check the key serial against the register.
• Sessions: revoke all sign-in sessions and refresh tokens for the account.
• Changes made: compare the Witness log against the audit logs (Entra audit log, AWS CloudTrail, AD security log) and reverse anything not on the approved list.
• Safe combinations: change them if anyone with access has left or if a safe was opened outside the procedure, as Microsoft advises.

6. Recovery

1. Confirm normal administrative access is working again (federation restored, policy fixed, admin accounts re-enabled).
2. Return the emergency account to its baseline: role active and permanent, excluded from blocking Conditional Access policies through the [EmergencyAccess] group, no new MFA methods registered, no personal devices or personal contact details on it.
3. Confirm the sign-in alert still fires: Microsoft's pattern is an Azure Monitor log search on SigninLogs filtered by the accounts' object IDs, threshold greater than 0, severity 0 Critical, notifying an action group. For AWS, confirm the root usage alert (for example the EventBridge rule or the GuardDuty root credential usage finding) is enabled.
4. Record the account as back in standby in the register.

7. Communication and notification

• During use: the Witness posts start and end times on [channel] for the SOC and on-call management.
• After use: the Approver notifies [CISO, Head of IT, audit] within [1] business day with the ticket, task performed and reset confirmation.
• Unapproved use: handled as a security incident; regulators and customers are notified only through the main incident process.

8. Post-incident review

8.1 Classify the use: planned drill, real emergency or misuse, as Microsoft's post-mortem guidance sets out, and confirm every action was authorised.

8.2 Fix the cause: if the use was a lockout, change the process that caused it (for example require report-only mode before enforcing Conditional Access). See the Conditional Access Guide.

8.3 Validation drill, at least every 90 days and after credential holder changes or subscription changes:

• [ ] SOC told in advance; sign-in alert fires and is matched to the drill ticket
• [ ] Authorised holder list reviewed and current
• [ ] Account signs in under current Conditional Access and performs an administrative task
• [ ] No MFA or self-service reset registered to a personal device or detail
• [ ] MFA devices reachable and the workstation has two independent network paths
• [ ] Holders trained; this procedure re-read and updated

Implementation guidance

Rollout order. Build the register and safes first, then the alerting, then run a supervised drill before declaring the procedure live. A procedure that has never been run fails on small things: a key with an unknown PIN, a safe whose combination left with a former employee.

Small versus large organisations. A small organisation with three administrators can let the CISO approve and an external managed service provider act as witness. A large organisation should hold credential parts in different buildings or regions and route approval through the incident manager rota.

Evidence to keep for each use. Auditors and post-incident reviewers ask for the same items every time, so collect them in one record:

Adapting for other environments. For AWS Organizations, AWS recommends centralised root access management, which removes root credentials from member accounts so only the management account root remains to protect; if member roots stay enabled, an SCP can deny root actions apart from root-only tasks. AWS also warns against storing the root password in a tool that depends on AWS services in the same account. For a Google Cloud organisation, Google advises enforcing two-step verification with a security key on super admin accounts, keeping that key in a safe place, giving each super admin a separate login from their everyday account and not using super admin for daily administration. For on-premises Active Directory, keep the emergency domain account out of any group that syncs to the cloud, and store its password outside the PAM vault so a vault outage does not block it. For a PAM vault itself, the emergency path is usually the vault's own recovery credential: list it in the register with the same split-knowledge rule.

Framework mapping. NIST SP 800-53 AC-2(2) Automated Temporary and Emergency Account Management, AC-2(12) Account Monitoring for Atypical Usage, AU-6 Audit Record Review and IA-5 Authenticator Management; NIST CSF 2.0 PR.AA-05 and DE.CM-03; ISO/IEC 27001:2022 Annex A 8.2 Privileged access rights; CIS Controls v8.1 Control 5 Account Management. See the AWS Root Account Compromise Playbook for the response when a root credential is stolen.

References. Microsoft: Manage emergency access admin accounts in Microsoft Entra ID · AWS: Root user best practices for your AWS account · NIST: SP 800-53 Rev. 5 · Google Cloud: Super administrator account best practices · NIST: SP 800-53 Rev. 5 control catalog (OSCAL), AC-2(2) and AC-2(12)

Related NHI Mgmt Group resources: Break-Glass Account Guide · Privileged Access Workstations Guide · Conditional Access Guide · AWS Root Account Compromise Playbook