The Real Problem with Emergency Access
In enterprise environments—especially those that operate 24×7—there are moments when someone needs elevated access immediately. A critical service fails. A major incident occurs. Business continuity is at risk. In these moments, organizations rely on breakglass accounts to bypass normal access controls and restore order.
And that’s perfectly reasonable—until it’s not.
One of our customers, a large enterprise with a complex IT footprint, approached us with the following issue:
“We use breakglass accounts for emergency access, but there’s no approval workflow, no MFA, and no audit trail. Auditors are concerned. And so are we.”
They weren’t alone. Across industries—finance, healthcare, manufacturing—organizations continue to rely on shared, privileged accounts for emergency access that:
- Can be activated with just a password
- Aren’t linked to a specific person
- Can remain active longer than needed
- Leave no clear trail of who did what and why
This makes breakglass access one of the most exploitable blind spots in any access governance program.
This wasn’t a simulated phishing drill.
This wasn’t a penetration test finding.
It was a real login attempt into a bank’s internal application.
A relationship manager’s credentials had been compromised through a targeted phishing email. The attacker didn’t just have the username and password — they also successfully completed the OTP challenge. From the application’s point of view, the authentication looked valid.
The login attempt happened late in the evening, outside normal working hours, from a location the user had never accessed from before.
In many environments, this is exactly where the story turns into an incident.
What the Customer Needed
The customer’s identity and security teams outlined three major goals:
- Controlled invocation: Breakglass accounts should only be usable after a defined request and approval process.
- Individual accountability: No shared logins. Every use of elevated access must be traceable to a named user.
- Audit-ready logging: Every session must be logged, time-bound, and available for attestation during compliance reviews.
At the same time, they didn’t want to slow down emergency access when it was truly needed.
This balance—speed with accountability—is exactly what we helped them achieve.
How BAAR-IGA Solved It
- Reason for access (e.g. incident ID, ticket number)
- Scope of systems or permissions needed
- Duration of access
- Route to a manager, application owner, or security lead for approval
- Allow emergency auto-approval with post-facto review for critical cases
- Log every step with timestamps for full traceability
- Entitlements granted are temporary and expire automatically
- Access revokes immediately after the approved duration or upon session termination
- This eliminates the risk of dormant high-privilege accounts lingering in the system
- Who requested and approved the session
- Which systems were accessed and when
- What actions were performed (via integrations with existing logs or optional session recording)
- Duration and justification
The Outcome
- No more shared logins — every access session is tied to a named user
- Real-time approval and strong authentication before elevated access
- Automatic revocation ensures privileges don’t linger
- Full visibility of who accessed what, when, and why
- Audit-ready logs and attestation aligned with internal and external compliance standards
- All of this was implemented without modifying their underlying systems
Why This Matters
Breakglass accounts are often overlooked during identity governance rollouts. They’re seen as edge cases—“we’ll get to that later.” But these accounts, precisely because they bypass normal controls, are among the most critical to govern.
By integrating breakglass access into BAAR-IGA, organizations gain the best of both worlds:
- Speed when it matters most
- Control, auditability, and trust every time
Identity governance is not just about regular access. It’s about the exceptions too.
