Break Glass Accounts
You set up break glass accounts by creating local admin profiles that bypass standard single sign-on. Teams store these emergency keys in offline safes and use them only when identity systems fail. Most teams create two emergency profiles with full cloud or database rights. When a crisis hits, an on-call engineer pulls the secret and logs in. If those roles stay too broad, one mistake during an outage can wipe out live data. How break glass accounts work in emergencies Standard daily logins r
Break-Glass Access Procedures: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up break glass accounts by creating local admin profiles that bypass standard single sign-on. Teams store these emergency keys in offline safes and use them only when identity systems fail. Most teams create two emergency profiles with full cloud or database rights. When a crisis hits, an on-call engineer pulls the secret and logs in. If those roles stay too broad, one mistake during an outage can wipe out live data.
How break glass accounts work in emergencies
Standard daily logins rely on an outside identity provider to check user names and passwords. If that provider goes down, your team gets locked out of servers and databases. Emergency profiles solve this problem because they live directly inside the target cloud or database. They do not talk to your normal login tools or phone apps.
To build this workflow, you first make a local user with high rights. Next, you attach a separate hardware key or a long password to that profile. Teams often split the password into two parts and place them in physical safes. Two managers must meet to join the parts and read the secret.
At the same time, you set up high-priority alerts in your log tool. Every login attempt on an emergency profile must page the security team right away. Once the outage ends, an admin rotates the password and puts the new secret away. Teams also run regular drills every few months to check that the keys still work.
What native emergency roles solve and what they miss
Native emergency profiles make sure your team can log in when your main identity provider fails. They also create a clear event in your sign-in logs when someone pulls the fire alarm. Auditors like this setup because the account sits idle for months until a real incident happens. You can see the exact minute an admin opened the safe and signed in.
Still, this setup only governs who gets through the front door. Once the engineer signs in, the emergency role grants full control over every resource. Native roles do not check individual SQL queries or shell commands while they run. An admin trying to fix a broken table can drop the wrong database by mistake.
Break-Glass Access Procedures: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared emergency profiles also hide who typed each command if two people share the session. In a panic, engineers often query live tables that hold user emails, phone numbers, or card numbers. Standard admin roles return all of those fields in plain text without rewriting matched fields in results. You need controls that inspect each command in flight and limit risk during high-stress fixes.
How to keep emergency logins under control
Start by removing emergency profiles from all automated scripts and background jobs. No app or test pipeline should ever use a break glass secret to run tasks. Keep the total count of these profiles down to two per core system. Give each profile a clear name so log alerts stand out right away.
Next, Scope the role permissions to the exact tasks needed to fix an identity outage. An account meant to fix login settings does not need rights to read customer tables. Test the login path once a quarter to make sure firewall rules did not block it. Right after every test or real outage, change the password and check every log entry.
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
When should an engineer use an emergency account?
Engineers should use these profiles only when the main login provider is down or broken. Never use them to skip normal approval waits during routine daily work.
Should break glass accounts use multi-factor authentication?
Yes, but they should use a separate method like a physical hardware key stored in a safe. Do not tie them to the same phone app used for normal daily logins.
How often should teams test emergency login keys?
Run a test login every ninety days to verify the secret and the alert rules. Always rotate the password or key right after the test finishes.