M365 Break Glass Account
You set up an m365 break glass account by creating a cloud-only admin user. This user skips normal login rules so you can fix total tenant lockouts. Teams often build two emergency accounts and store their keys in physical safes. They assign top admin roles to these users so they work during outages. If a bad actor steals these broad roles, they control your whole tenant. How an m365 break glass account works in practice Normal admin users log in through single sign-on and strict multi-factor
Break-Glass Access Procedures + Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an m365 break glass account by creating a cloud-only admin user. This user skips normal login rules so you can fix total tenant lockouts. Teams often build two emergency accounts and store their keys in physical safes. They assign top admin roles to these users so they work during outages. If a bad actor steals these broad roles, they control your whole tenant.
How an m365 break glass account works in practice
Normal admin users log in through single sign-on and strict multi-factor rules. If your identity provider goes down, no normal admin can log in. A bad conditional rule can also lock every staff member out at once. The emergency account solves this problem by living only inside Microsoft cloud directories. It uses the base domain name that comes with your tenant at creation. You do not link this user to on-premise servers or external login tools.
To keep the account working, you exclude it from conditional login rules. You still protect the user with a strong hardware key or long password. Teams split the login details across two separate safe locations for better safety. One person holds the first part and another person holds the second part. You never attach this account to one single person's phone or email address. If that person leaves the company, your team still owns the recovery method.
You also set up alert rules inside your central log tool right away. Every time the emergency user logs in, the system sends high-priority alerts. The security team gets a page and checks why someone used the account. Teams test the login path every few months to make sure it works. After each test, they rotate the secret and update the paper records.
What native emergency accounts solve and what they leave open
Native emergency accounts solve the huge risk of a permanent cloud lockout. They give your team a reliable back door when external login systems fail. Without them, you must call vendor support and wait days for tenant recovery. During a major outage, that delay costs your business time and money.
Still, this native setup leaves a major operational gap during real incidents. The emergency role grants full control over every setting, user, and data store. Account setup only decides who logs in to the cloud portal. It does not check what individual commands or requests do in flight. Once an admin logs in, they can run any command without extra checks.
Break-Glass Access Procedures + Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
A tired engineer fixing an outage at night might run a destructive script. They could delete user mailboxes or change tenant-wide sharing rules by mistake. Native logs record the bad action after the damage already happens. They do not block dangerous commands or mask sensitive data like emails in results. Teams also need emergency paths for databases and servers outside the cloud portal. Relying on permanent super-user accounts across every system multiplies your risk of breaches.
How to tighten emergency workflows and audit reviews
Good emergency workflows focus on strict steps before and after the login event. First, write a clear rule on when engineers can pull the emergency credentials. Only a full identity outage or broken access rule should trigger this path. Regular support tickets or slow approvals never justify using the emergency account.
Second, require two people on a voice call whenever the account is active. One engineer runs the fix while the second person watches every screen action. This buddy system cuts down on typos and accidental deletions during high stress. As soon as the main login tool works again, sign out right away. Change the emergency password or hardware key before closing the incident ticket. Finally, review every audit log line from that window with your security lead.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How many emergency accounts should a tenant have?
Most teams create two cloud-only emergency accounts for their main tenant. If one account gets locked or loses its key, the second one works. Store the keys for each account in different physical safes or bank vaults.
Should an m365 break glass account use multi-factor login?
Yes, you should use a strong method like a physical hardware security key. Do not use phone apps or text messages tied to one single employee. Keep the hardware keys in a safe that differs from the password safe.
How often should teams test emergency cloud accounts?
Run a live login test with your team at least once every ninety days. This check proves the keys work and confirms your alert rules fire properly. Always update the account password right after you finish the scheduled test.