Clear Thinking in Data, Cloud, and AI

The goal is to create accounts that are completely independent of your normal administrative processes, making them accessible even during a major system failure (e.g., federation failure, PIM service outage, or mass administrative lockout).

Step 1: Account Creation and Identity Isolation

1. Create New Cloud-Only Accounts:
   • Do not use existing user accounts.
   • Create two new accounts directly in Microsoft Entra ID (formerly Azure AD).
   • Example names: breakglass-admin-01@yourdomain.onmicrosoft.com and breakglass-admin-02@yourdomain.onmicrosoft.com.
   • Crucially, these accounts must be cloud-only. They should not be synchronized from your on-premises Active Directory (if you have one). This ensures that an issue with your on-premises environment (like a federation failure or a sync issue) does not prevent you from logging in.
2. Assign the Role:
   • Immediately and permanently assign the Global Administrator role to both new accounts.
   • Do not make these accounts eligible for the role via PIM; they need permanent, immediate access for emergency scenarios.

Step 2: Security Hardening (The Most Critical Step)

Since these accounts bypass normal controls, they must be secured like nuclear launch codes.

1. Strong, Unique Passwords:
   • Generate two extremely long, unique, and complex passwords (ideally 30+ characters).
   • The passwords should be known only to the necessary keyholders.
2. Mandatory Multi-Factor Authentication (MFA):
   • Enable MFA for both accounts.
   • Do not use SMS/voice call MFA. Use a hardware key (FIDO2/security key) or a dedicated, isolated authenticator app on a managed device.
   • Best Practice: Use a hardware security key (e.g., YubiKey) that is physically stored with the account details. This is the hardest form of MFA for an attacker to bypass.
3. Restrict Sign-in Locations:
   • Use a Conditional Access Policy to restrict these accounts’ sign-in to specific, highly-secured administrator workstations or IP addresses whenever possible.
4. No Email/Daily Use:
   • These accounts should never be used to read email, browse the web, or perform any daily administrative tasks. They are for emergency sign-in only.

Step 3: Secure Storage and Retrieval Process

The credentials must be stored securely, yet be accessible to the necessary personnel during an emergency.

1. Password and MFA Storage:
   • Store the passwords and the physical MFA device/recovery codes in two separate, highly secure locations.
   • Physical Security: Use a physical, fire-rated safe or a secure, certified container.
   • Digital Security (Alternative): Use a highly-secured digital vault or Key Management System (KMS) that requires multiple approvals (multi-party control) to access.
2. The “Break Glass” Protocol (The Process):
   • Document a formal, step-by-step procedure for using these accounts.
   • Access Requirements: The process should require at least two authorized personnel (keyholders) to be present to retrieve the credentials, ensuring a form of “four-eyes” security.
   • Mandatory Actions After Use: The protocol must require the following actions immediately after the emergency is resolved:
     • Change the password.
     • Review the sign-in and audit logs for the account.
     • Log the date, time, and reason for the access.

Summary of Configuration

This setup ensures that you have a completely segregated and secure emergency bypass for your environment, minimizing the risk associated with these ultra-privileged accounts.

Add to favorites