Brake Glass Account
You set up a brake glass account by creating a local admin login for outages. This backup role works when your main login provider goes down. Many engineers type brake instead of break when searching for emergency login guides. Both terms point to the same backup admin role for crisis events. Teams often attach full root permissions to this role so responders can fix anything. Broad permissions create big risks once a responder logs in during a high-stress outage. How a brake glass account wor
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 a brake glass account by creating a local admin login for outages. This backup role works when your main login provider goes down. Many engineers type brake instead of break when searching for emergency login guides. Both terms point to the same backup admin role for crisis events. Teams often attach full root permissions to this role so responders can fix anything. Broad permissions create big risks once a responder logs in during a high-stress outage.
How a brake glass account works in practice
Your normal daily workflow relies on a central identity provider for team logins. If that provider fails, engineers lose their ability to fix production apps and servers. A brake glass account skips the central login system and uses local platform credentials. Security teams store the password and hardware key in a safe or secret store. When an outage hits, an on-call responder checks out the credentials to log in. Every login event triggers a high-priority alert to the security team right away. After the crisis ends, the team rotates the password and revokes active tokens.
What native emergency roles solve and what they miss
Native emergency roles solve the problem of getting locked out during a major failure. They give your team a fast way back into cloud consoles and databases. Still, this setup only controls who can log in at the start. Once the responder logs in, the platform grants full admin permissions for every task. The native role does not inspect individual SQL queries or shell commands in flight. An exhausted engineer can drop a production table or read raw customer data. If the emergency database query returns emails or card numbers, no native rule rewrites them. Masking rewrites matched fields like phone numbers or national IDs in query results. Without command checks and data masking, emergency sessions leave your sensitive systems wide open.
How to audit and test emergency logins
A backup login fails if your team only touches it during a real outage. Security teams run regular drills every quarter to test the full checkout process. During a drill, an engineer pulls the backup key and logs in. The security team checks that the alert fires and reaches the on-call channel. Next, reviewers read the cloud and database logs to verify every recorded action. Native logs often show that the shared admin role logged in, not which person used it. Tying the checkout record to the command log helps auditors track every single change. Finally, the team resets the secret and locks the hardware key back in storage.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
Break-Glass Access Procedures + Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do people call it a brake glass account instead of break glass?
Engineers often spell break as brake by mistake when writing docs or searching online. The phrase comes from breaking the glass on a fire alarm box during an emergency.
How many emergency accounts should a team keep?
Most teams keep two separate emergency accounts to avoid a single point of failure. If one hardware key breaks or gets lost, the second account still works.
Should emergency accounts use multi-factor authentication?
Yes, every emergency role should use a hardware security key stored in a safe. Do not tie the account to a single person's phone or email app.
Teams that document these role rules and review logs each month catch config drift early. Clear ownership for each role keeps live systems simple to run and easy to audit across the whole team.