Break-glass Accounts
You set up break glass accounts by creating local admin users that bypass single sign-on. These emergency logins let engineers fix production systems when your main identity provider goes down. Most teams store these root keys inside a physical safe or a separate secret vault. When an outage hits, an on-call responder pulls the password and logs right into the target. Because these roles hold full admin power, one bad command can wipe out critical data. How break glass accounts work in product
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 users that bypass single sign-on. These emergency logins let engineers fix production systems when your main identity provider goes down. Most teams store these root keys inside a physical safe or a separate secret vault. When an outage hits, an on-call responder pulls the password and logs right into the target. Because these roles hold full admin power, one bad command can wipe out critical data.
How break glass accounts work in production
In normal daily work, your team logs in through a central identity provider. That central system checks user roles and enforces multi-factor rules for every single session. If that identity provider fails, nobody can log in to fix the broken apps. Break glass accounts solve this lock-out risk by using local database or cloud accounts. These local accounts do not talk to your central login server at all.
To build this setup, admins create one or two standalone users with full root rights. They turn off normal login rules for these specific users so nothing blocks emergency entry. Next, they generate long random passwords and split the recovery keys across two separate managers. Some teams keep the hardware security keys inside a locked office safe for extra safety. The account sits idle until a major outage takes down the normal login path.
When an incident starts, the on-call engineer requests the secret key from the vault. The system sends a high-priority alert to the security team the moment someone logs in. Once the crisis ends, the security team rotates the password and checks the audit logs.
Why static emergency roles leave a security gap
Native emergency setups do a great job of getting engineers online during a bad outage. They make sure a broken login server never stops your team from fixing production. Still, native emergency accounts only check who logs in at the start of a session. Once the engineer enters the password, the system grants total control over every resource.
This all-or-nothing access creates a massive risk during high-stress incidents. Tired engineers working at three in the morning make typos in the terminal. A single wrong query can drop a live customer table or delete cloud storage buckets. Native cloud and database roles cannot stop a bad command once the user is inside.
Break-Glass Access Procedures: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static emergency roles also expose raw sensitive data in query results. If an engineer queries a user table to fix a bug, raw card numbers appear. Emails, phone numbers, and national IDs show up on the screen in plain text. After the incident, basic login logs only show that the shared emergency account signed in. Security teams struggle to prove which person ran which exact command during the outage. Rotating shared passwords and hardware keys after every drill also takes hours of manual work.
Better habits for emergency access drills
You should test your emergency login flow every quarter to make sure it works. Many teams find out during a real outage that an old password expired months ago. Run a quick game day where an engineer pulls the key and reads one table. Check that your alert system pages the security team within one minute of login. When the test finishes, revoke the active session right away and reset the stored secret. Scoping emergency roles down to specific tasks also lowers the blast radius of human mistakes.
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 break glass accounts should a team keep?
Most teams keep two separate emergency accounts for each core cloud or database system. If one key gets lost or locked, the second account acts as a backup.
Should emergency accounts use multi-factor authentication?
Yes, they should use hardware keys that do not depend on your main login provider. Avoid phone apps or text messages that might fail during a wide network outage.
How often should we rotate emergency passwords?
You must rotate the password right after every real use and every scheduled drill. If the account sits unused, rotate the secret at least once every ninety days.