Microsoft Best Practice Break Glass Account
To build a microsoft best practice break glass account, create two cloud-only emergency users. Exclude these emergency users from your standard login rules to prevent tenant lockouts. Teams create these special accounts to survive identity provider outages or bad rule changes. When a bad rule blocks normal logins, an admin uses the emergency key. Still, these accounts hold full admin rights across the entire cloud tenant. If someone steals those keys, they control every app, server, and databas
Break-Glass Access Procedures + Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To build a microsoft best practice break glass account, create two cloud-only emergency users. Exclude these emergency users from your standard login rules to prevent tenant lockouts.
Teams create these special accounts to survive identity provider outages or bad rule changes. When a bad rule blocks normal logins, an admin uses the emergency key. Still, these accounts hold full admin rights across the entire cloud tenant. If someone steals those keys, they control every app, server, and database you own.
How a microsoft best practice break glass account works
Your emergency accounts must live only in the cloud directory. They cannot depend on on-premises servers or outside login tools. If your local network goes down, synced accounts fail right along with it. Cloud-only accounts still work when local login servers go offline.
You should use domains that come built into the cloud tenant. Custom domain names might fail if your domain routing breaks or expires. A built-in tenant domain stays active during external network failures.
You also need strong login keys that do not rely on cell phones. Phone networks fail, and staff members leave the company with their devices. Physical security keys or long passphrases work best for emergency logins. Store two separate keys in fireproof safes at different physical sites. Only senior leaders should know how to open those safes.
Finally, you must leave at least one account out of your login rules. If a team member makes a mistake in a rule, everyone gets locked out. The untouched emergency account lets you log in and fix the broken rule.
Monitoring and testing emergency logins
An idle account is a prime target for attackers. Because these users bypass normal login blocks, you must watch them closely. Set up your log tool to watch every sign-in attempt from these accounts.
Break-Glass Access Procedures + Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When someone uses a break glass account, the system should send an alert right away. Send texts and emails to the security team whenever that account logs in. Send the same alerts if anyone changes the account password or role settings. If no outage is happening, treat that login as a live security breach.
Teams also need to test these accounts on a regular schedule. Pick a day every few months to run a full drill. Have two admins pull the keys from the safe and log in. Confirm that your log alerts fire and reach the right people on the team. After the test or a real outage, rotate the passwords or keys right away.
What native emergency accounts solve and where gaps remain
This native setup solves one vital problem: it prevents total tenant lockout. If your main login system fails, you can still get inside to fix it. It gives your team a safety net when identity rules go wrong.
Yet this setup leaves a major gap during active incidents and daily work. Directory roles decide who can log in to the cloud portal. They do not control what commands an engineer runs inside a database or server. Once an admin logs in with full rights, every query and script runs unchecked.
Teams often share broad admin roles for database fixes or production server outages too. Static directory roles give permanent power instead of scoping rights to a single task. Native directory logs show that a user logged in at a certain time. They do not inspect database queries or rewrite sensitive fields like card numbers or emails.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How many emergency accounts should a cloud tenant have?
Create at least two separate emergency accounts for your cloud tenant. If one account fails or loses its key, the second account serves as a backup. Use different storage sites for the keys of each account.
Should break glass accounts use phone-based multi-factor login?
No, avoid linking emergency accounts to a single person's phone or mobile app. If that person leaves or loses their phone, the team cannot log in. Use hardware security keys stored in a secure office safe instead.
How often should teams test their break glass accounts?
Test your emergency accounts at least once every ninety days. Walk through the full process of getting the key, logging in, and checking alerts. Change the account password after any test or real emergency use.