Break Glass Approach
A break glass approach gives engineers temporary, high-level permissions during a severe outage. Teams set up an emergency role that bypasses normal rules when systems fail. Most teams build this flow using cloud roles or shared admin accounts. If these emergency roles stay too broad, one bad command can wipe out data. Standing admin permissions also make audits hard to pass. How a native break glass approach works In a standard setup, engineers have read-only permissions for daily work. They
Break-Glass Access Procedures: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A break glass approach gives engineers temporary, high-level permissions during a severe outage. Teams set up an emergency role that bypasses normal rules when systems fail. Most teams build this flow using cloud roles or shared admin accounts. If these emergency roles stay too broad, one bad command can wipe out data. Standing admin permissions also make audits hard to pass.
How a native break glass approach works
In a standard setup, engineers have read-only permissions for daily work. They cannot change production databases or live servers on a normal day. When an incident starts, the on-call engineer requests the emergency role. A chat bot or ticketing tool checks if an active alert exists. Once approved, the identity system attaches an admin policy to that user.
This policy stays active for a set window, such as two hours. During that window, the engineer logs in to fix the broken service. A timer revokes the role when the window ends. The system also sends an alert to the security team for review. Some teams store a root key in a safe for outages. If the main identity provider fails, an admin retrieves that backup key.
What native emergency roles solve and what they miss
Native emergency roles stop teams from keeping permanent admin rights all week. They shrink the time window where an attacker could steal a high-level account. They also create a clear log of who asked for emergency rights. Auditors like seeing when an engineer claimed the role and why.
Still, native roles only control who logs in to the target system. Once the engineer holds the role, the system trusts every command they run. A tired engineer at three in the morning can still drop a table. Native cloud roles do not check individual SQL queries or shell commands in flight. They also do not mask sensitive fields in query results. If an engineer runs a broad select statement, raw card numbers and emails appear. The audit log only shows that a login happened, not the exact queries.
Break-Glass Access Procedures: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to review emergency sessions after an outage
Every emergency event needs a clear review after the team fixes the outage. First, match the role activation log against the active incident ticket number. Check that the engineer dropped the role right after the fix finished. Next, pull the command and query logs from the database or server. Look for any broad data exports or schema changes made during the window.
If you use shared emergency keys, rotate those passwords right away. Never let an emergency key sit unchanged after someone reads it. Meet with the engineer to ask which exact permissions they needed. Often, you can narrow the emergency role before the next outage hits.
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.
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
When should a team trigger a break glass workflow?
Teams should only trigger this workflow during a major production outage or security incident. It is for moments when standard approval queues would cause severe business harm.
How long should emergency permissions stay active?
Most teams set the timer between one and four hours per incident. The system should drop the permissions right away when the timer runs out.
How do you stop abuse of emergency accounts?
Send real-time alerts to security channels the second someone claims an emergency role. Require a mandatory post-incident review for every single command run during that session.