🛡️ Essential 8 Guide

Credentials for break glass accounts, local administrator accounts and service accounts are long, unique, unpredictable and managed.

Summary

Establish break-glass emergency access accounts with randomly generated passwords and a physical FIDO2 key for phishing-resistant MFA to ensure secure, auditable access during outages. Monitor sign-in and audit logs and validate accounts regularly to maintain accountability and incident readiness.¹²

Justification

Emergency access (break-glass) accounts represent the highest-privilege, lowest-frequency-use credential class. Their security requirements differ from regular admin accounts in three ways:

1. Why FIDO2 rather than TOTP/push:

• TOTP apps are software-only and vulnerable to phishing, SIM-swap, and authenticator-app malware — a single-device compromise can defeat them.
• FIDO2 security keys provide hardware-bound, verifier-impersonation-resistant authentication (NIST SP 800-63 AAL3). The private key never leaves the physical device, making phishing-based credential theft impossible.
• Break-glass use is tied to an infrastructure outage scenario (Azure MFA down, IdP unreachable). A FIDO2 key operates independently of cloud services, while push notifications require the MFA cloud service to be available.
• Microsoft guidance explicitly recommends FIDO2 or certificate-based authentication for emergency accounts to ensure access during service disruptions.

2. Why cloud-only (not federated):

If an on-premises AD or federation service is unavailable (the primary outage scenario for break-glass use), federated or synced accounts cannot authenticate. Cloud-only accounts authenticate directly against Entra ID.

3. Monitoring requirements:

Any sign-in from a break-glass account — successful or failed — is a security event requiring immediate investigation. Key Entra ID Protection signals to monitor:

Design Decision

[!NOTE] The Emergency Access Accounts will be created in Microsoft Entra ID with randomly generated passwords and a FIDO2 passkey for MFA provided. They will be configured as cloud-only accounts with a Global Administrator role to ensure break-glass capability during outages.

Prerequisites

• Permissions/Roles
  • At least two cloud-only emergency access accounts with the Global Administrator role in Microsoft Entra ID.¹
  • Emergency access accounts must use passwordless authentication methods: Passkey (FIDO2) or Certificate-based authentication.¹
  • Require phishing-resistant MFA for all emergency accounts.¹
• Dependencies
  • Emergency access accounts must be cloud-only (not federated or synchronized from on-premises).¹
  • If passwords are used in addition to passwordless methods, generate strong, randomly generated passwords of at least 32 characters, configured to never expire; implement dual control by storing credentials in separate secure physical locations and document retrieval procedures.²
  • Monitoring and alerting: enable sign-in and audit log monitoring using Azure Monitor or Microsoft Sentinel, with real-time alerts for emergency account activity.²
  • Runbooks and testing: maintain written runbooks detailing the complete emergency access process; perform quarterly testing; rotate credentials every 90 days or after personnel changes; train authorized administrators on break-glass procedures.²
  • Store account credentials safely.¹

Implementation Steps

Create break-glass emergency access accounts with random passwords and FIDO2 MFA

1. Create emergency access accounts: Provision two cloud-only accounts (EmergencyAccess01@contoso.onmicrosoft.com, BreakGlass02@contoso.onmicrosoft.com) with the Global Administrator role in Microsoft Entra ID; ensure accounts are not federated or synchronized from on-premises AD; use descriptive names that clearly identify their purpose.²¹

2. Secure credentials with dual control: Generate strong, randomly generated passwords of at least 32 characters configured to never expire; implement dual control by splitting credentials into multiple parts stored in separate secure physical locations, accessible only with multi-person approval.¹

3. Configure passwordless authentication with MFA: Configure emergency access accounts to use passwordless authentication, preferably FIDO2 passkeys; or use certificate-based authentication if PKI is in place; require phishing-resistant MFA for all emergency accounts.²

4. Configure Conditional Access exclusions: Exclude at least one emergency account from all Conditional Access policies and MFA requirements to guarantee access during service disruptions; optionally secure the second account with FIDO2 security keys stored in secure locations.²

5. Enable monitoring and alerting: Configure Azure Monitor or Microsoft Sentinel to analyze sign-in and audit logs; create real-time alerts triggering on any emergency account authentication or configuration change; establish incident response procedures requiring immediate security team notification and justification documentation for all emergency account usage.²

6. Establish testing and maintenance procedures: Test emergency account access quarterly; rotate credentials every 90 days or immediately following personnel changes affecting authorized users; train authorized administrators on break-glass procedures including credential retrieval and incident documentation; maintain written runbooks documenting the complete emergency access process for compliance and operational readiness.²

Recommended Enterprise FIDO2 Security Keys

The following FIDO2 security keys are attested with Microsoft Entra ID and commonly deployed in Australian enterprise and government environments. Each model’s AAGUID is published in the Microsoft Entra FIDO2 hardware vendor attestation list.³

[!NOTE] A single hardware model typically has multiple AAGUIDs across firmware versions, enterprise profile variants, and product revisions. When restricting by AAGUID, add all relevant AAGUIDs for the intended product family \u2014 the YubiKey 5 NFC family alone has 10+ distinct AAGUIDs. Always verify against the Microsoft Entra FIDO2 hardware vendor attestation list before finalising the approved list.³

Restricting FIDO2 Keys by Brand or Model (Device Attestation)

Microsoft Entra ID supports AAGUID-based restriction of FIDO2 security keys using Custom Authentication Strengths in Conditional Access. This allows organisations to enforce that only pre-approved key models (e.g., YubiKey 5 NFC only, or YubiKey + HID Crescendo) can satisfy FIDO2 authentication \u2014 preventing the use of unvetted consumer-grade or unapproved devices.

Step 1 \u2014 Enable attestation enforcement for passkeys (FIDO2)

Attestation must be enabled before AAGUID filtering takes effect. Without enforced attestation, Entra ID accepts any FIDO2-compliant key regardless of AAGUID.

1. In the Microsoft Entra admin center, browse to Authentication methods > Policies > Passkeys (FIDO2).³
2. Set Enforce attestation to Yes and save.

Keys registered after this point must have a FIDO Alliance MDS-validated attestation chain. Previously registered keys without a valid attestation will no longer satisfy authentication.

Step 2 \u2014 Create a custom Authentication Strength with approved AAGUIDs

1. Browse to Entra ID > Authentication methods > Authentication strengths.³
2. Select New authentication strength; provide a name (e.g., Approved FIDO2 Keys \u2014 [Organisation]).
3. Select Passkeys (FIDO2) as the allowed method.
4. Select Advanced options > Add AAGUID.
5. Enter each AAGUID for every approved key model and firmware variant. For a YubiKey-only policy, add all AAGUIDs for the chosen product lines from the Microsoft Entra attestation list.
6. Select Save, then Next, then Create.³

[!TIP] YubiKey Enterprise Program: YubiKey 5 Series and Security Key Series keys purchased through the YubiEnterprise Subscription can be provisioned with an Enterprise Profile AAGUID \u2014 a single organisation-specific AAGUID assigned to an entire batch. This dramatically simplifies AAGUID management: instead of tracking 10+ AAGUIDs per product line, you manage one. Enterprise Profile variants appear in the Microsoft Entra attestation list with (Enterprise Profile) in the description. HID Crescendo similarly offers an enterprise/managed profile variant.

Step 3 \u2014 Apply the custom strength to Conditional Access policies

1. Navigate to Entra ID > Security > Conditional Access > Policies and open the relevant CA policy.
2. Under Grant, select Require authentication strength and choose the custom strength (e.g., Approved FIDO2 Keys \u2014 [Organisation]) instead of the built-in Phishing-resistant MFA strength.
3. Save and enable the policy. Users presenting a key whose AAGUID is not in the approved list receive CA error 53003 (authentication strength not satisfied).³

[!WARNING] Before enforcing, verify that all currently registered FIDO2 keys for emergency accounts are in the approved AAGUID list, or re-register them with an approved key. A user whose registered key AAGUID is not in the list will be completely blocked.

Additional related information

• Local Administrator Password Solution provides per-device random local admin passwords rotated and stored with restricted ACLs for secure local admin management Local Administrator Password Solution

• Deploy Windows LAPS policy with Microsoft Intune guides how to enforce Windows LAPS to rotate strong, unique local admin passwords across devices in Zero Trust environments Deploy Windows LAPS policy with Microsoft Intune

• ASD Blueprint: Restrict administrative privileges outlines essential eight guidance on limiting break-glass and admin privileges to reduce risk ASD Blueprint: Restrict administrative privileges

• Managing service accounts (ML2) highlights long, unique, unpredictable credentials for service accounts and OS-driven password management (gMSAs) Managing service accounts (ML2)