Breakglass Account
A breakglass account is a spare admin user built for urgent outages. You set it up to log in when your primary login tool fails. Engineering teams create these local users to prevent total system lockouts. Teams often grant these users full admin rights across all servers and databases. Those broad rights create high risk if someone steals the login keys. Once an engineer logs in, the system trusts every action they take. How to set up a breakglass account in your system To build a breakglass
Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A breakglass account is a spare admin user built for urgent outages. You set it up to log in when your primary login tool fails. Engineering teams create these local users to prevent total system lockouts. Teams often grant these users full admin rights across all servers and databases. Those broad rights create high risk if someone steals the login keys. Once an engineer logs in, the system trusts every action they take.
How to set up a breakglass account in your system
To build a breakglass account, start inside your local cloud or database directory. You must create a local user that does not use single sign-on. If your primary identity provider goes down, this local path still works. Assign this user the exact admin roles needed to fix broken login rules.
Next, generate a long, random password and a separate hardware token for two-factor checks. Store the password and the hardware token inside a locked safe or vault. Split the safe keys between two senior managers on different teams. This two-person rule stops one person from logging in alone during normal hours.
Finally, connect your system logs to your team alert channel. Set a rule that pages the security team the second this user logs in. Every sign-in event should open an urgent ticket for review. When the incident ends, rotate the password right away and lock the safe again.
What native emergency accounts solve and what they miss
This native setup solves the worst problem during a major outage. It gives your team a working door when normal login tools break. Your alerts also tell you who opened the safe and logged in. You know the exact minute the emergency session started and ended.
Still, a native admin user leaves a major gap during the session itself. The local user setup only checks who logs in at the door. It cannot check or limit what single commands or queries run in flight. Once the responder logs in as an admin, they hold total power.
Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Under stress, an engineer might run a bad delete query against a live table. They might also read raw customer tables to debug a broken app. Native database roles do not rewrite sensitive fields like emails or card numbers. Also, shared emergency logins make it hard to tie each command to one person.
Why teams move from static emergency logins to action-level rules
Relying on a shared static user puts heavy stress on your on-call staff. Responders waste valuable minutes finding safe keys and typing long passwords during an outage. After the fix, security engineers spend hours reading raw server logs to check changes. They must guess why the responder ran each command during the fire drill.
Modern teams prefer to scope emergency work down to the single command or query. Instead of handing out a full admin key, they approve specific actions fast. When an engineer reads production tables, data masking rewrites phone numbers and national IDs in results. This approach keeps urgent fixes fast while keeping sensitive records safe from 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 often should we test our emergency login process?
Test your emergency login at least once every three months during a scheduled drill. Confirm that the password works, the alerts fire, and the team can rotate keys fast.
Should an emergency user bypass two-factor checks?
No, you should still require a second factor for any admin login. Use a hardware security key stored in a physical safe instead of a phone app.
When should we rotate the password for an emergency user?
Rotate the password right after anyone uses the account or leaves the security team. You should also rotate it after every quarterly drill to keep the login secure.