Azure Emergency Access Account
An azure emergency access account lets admins log in when normal sign-in paths fail. You create a cloud-only user with permanent admin rights and exclude it from conditional policies. Teams build these break-glass users so a faulty rule or outage does not lock everyone out. Yet holding a permanent top-level role creates huge risk if someone uses that account during an incident. Once logged in, the user can run any command across your whole tenant. How to set up an azure emergency access accoun
Emergency Access Protocols + Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An azure emergency access account lets admins log in when normal sign-in paths fail. You create a cloud-only user with permanent admin rights and exclude it from conditional policies. Teams build these break-glass users so a faulty rule or outage does not lock everyone out. Yet holding a permanent top-level role creates huge risk if someone uses that account during an incident. Once logged in, the user can run any command across your whole tenant.
How to set up an azure emergency access account
To build an azure emergency access account, you must keep it separate from federated login tools. You create the user inside the default cloud domain instead of your custom company domain. This step ensures the account still works if your on-premise identity servers go offline. Most teams make two separate emergency accounts to avoid a single point of failure.
Next, you assign the highest tenant admin role directly to both emergency accounts. Unlike daily admin accounts, these accounts do not use temporary role elevation tools. If the role elevation service breaks, the emergency user still has full rights right away. You also exclude these accounts from every conditional sign-in rule in your directory.
For sign-in checks, you should avoid phone apps or text messages tied to one person. Instead, teams use physical security keys or divide long passwords into two separate parts. You store those keys or password halves in separate fireproof safes at different sites. That way, no single person can log in alone without leaving a paper trail.
Monitoring sign-in events and alert rules
Because these accounts bypass normal sign-in rules, you must watch their activity logs closely. Any login attempt by a break-glass user should trigger a high-priority alert right away. Teams route directory sign-in logs to a central log workspace for constant checks. When the emergency account logs in, the system sends alerts to security leaders.
You should also test your emergency accounts on a regular schedule, such as every quarter. During a drill, two team members retrieve the physical keys and sign in together. They confirm that the login works and that the alert rule fires as expected. After the test, they rotate the account secrets and return the keys to the safes.
Emergency Access Protocols + Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What break-glass accounts solve and what they leave open
This native setup solves a major problem: total tenant lockout during an identity outage. If a bad conditional rule blocks all staff, an admin can still get in and fix it. If your external identity provider goes down, you can still reach your cloud portal.
Still, directory roles only decide who can log in to the cloud control plane. They do not inspect what individual database queries or server commands do in flight. When an engineer uses an emergency account or elevated role to fix a production database, they hold broad rights. The native login check cannot block a destructive query or mask sensitive columns like emails, phone numbers, card numbers, or national IDs in query results. Directory sign-in logs show that the account logged in, but not every command run inside downstream servers or databases. Controlling live sessions requires inspecting each command and query after the login succeeds.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why should an emergency account use the default cloud domain?
Custom domains often rely on external identity servers or network links that can fail. Using the default cloud domain keeps the login path inside the cloud provider.
How many emergency accounts should a cloud tenant have?
Most security teams create two accounts and protect them with different login methods. If one physical key breaks or gets lost, the second account still works.
Should emergency accounts be tied to a specific employee?
No, break-glass accounts should never link to one employee's phone or personal email. If that person leaves the company or loses their phone, the team gets locked out.