Breaking Glass Account
A breaking glass account gives an on-call engineer emergency rights when normal login paths fail. Teams set up this special user with full admin rights and store the login key in a safe place. Most teams create one or two emergency accounts in their cloud or database tool. They exclude these accounts from standard single sign-on rules so an outage cannot block login. Still, these broad roles give the user total control over every table and host. One bad command during a stressful outage can dele
Break-Glass Access Procedures + Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A breaking glass account gives an on-call engineer emergency rights when normal login paths fail. Teams set up this special user with full admin rights and store the login key in a safe place. Most teams create one or two emergency accounts in their cloud or database tool. They exclude these accounts from standard single sign-on rules so an outage cannot block login. Still, these broad roles give the user total control over every table and host. One bad command during a stressful outage can delete live data or expose secret keys.
How a breaking glass account works in practice
To build a breaking glass account, admins first create a local user inside the target system. This user does not rely on an outside identity provider or directory tool. If the main login service goes down, the local account still works as expected. Admins attach a top-level role to this user so the responder can fix any broken resource.
Next, the team locks the password and multi-factor token inside a physical safe or separate vault. Some teams split the password into two parts and give each part to a different manager. Other teams use an automated vault that requires two peers to approve the secret checkout. When a major outage hits, the on-call engineer requests the secret and logs in. The system sends a high-priority alert to the security team the moment this login happens.
Once the crisis ends, the security team must reset the password right away. They also generate a new hardware token or backup code for the next incident. This manual rotation keeps the emergency login safe from reuse after the ticket closes.
What native emergency accounts solve and what they miss
A native emergency setup solves the deadlocked login problem during an identity outage. It gives the team a fast way back into the cloud console or database engine. Security teams also get a clear alert showing that someone opened the emergency vault. This setup works well for rare events where the primary login provider fails completely.
Yet this model leaves a huge gap during day-to-day production incidents. Most urgent fixes do not happen because the identity provider is down. Instead, an engineer needs quick admin rights to fix a stuck database job or bad state. Giving out a full emergency user for routine outages hands over far too much power. Once the engineer logs in, the native role cannot block dangerous queries or destructive commands. The account setup only controls who logs in, not what individual statements do in flight.
Break-Glass Access Procedures + Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, native logs often miss the exact queries or shell commands run during the session. Admins know that the emergency user logged in at two in the morning. They still have to dig through scattered system files to see what changed. Sensitive fields like emails, phone numbers, and card numbers also show up in plain text during queries. Without query-level rules, an emergency login turns every urgent fix into a high compliance risk.
Steps to audit and rotate emergency credentials
Every emergency login must trigger a strict review process as soon as the system recovers. First, the security team revokes the active session and rotates the account secret. Next, the responder writes a short post-mortem note explaining why normal permissions were not enough. The team then pulls the system logs from the database or server to check every action.
If engineers use the emergency account too often, their normal roles need an update. Teams should also test the emergency login once every quarter during business hours. Regular drills prove that the backup key still works and that alerts fire on time. Keeping the workflow tight ensures the account stays ready for a real disaster.
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 a breaking glass account?
An engineer should use this account only when the main login tool fails or blocks urgent fixes. It is meant for severe outages where normal approval flows cannot work in time.
How do you secure multi-factor authentication for an emergency user?
Teams should register a separate hardware key or backup code that does not use the main phone app. Store this physical key in a locked safe and log every time someone takes it out.
How often should teams test and rotate emergency passwords?
Rotate the password right after every use and at least once every ninety days. Run a live login test once a quarter to confirm that security alerts still reach the team.