Break Glass Access in Kerberos: Procedures, Security, and Best Practices

The alert came at 2:03 a.m. The primary Kerberos authentication server was down, and production was locked.

When identity is the gate, “Break Glass” access is the hammer. In Kerberos environments, break glass procedures are not about convenience—they are about survival. Done wrong, they’re a security hole. Done right, they keep systems online without opening the floodgates to attackers.

What Break Glass Access Means in Kerberos

Break glass access in Kerberos is a predefined emergency path to critical resources when standard authentication fails. It bypasses normal ticket-granting flows but is wrapped in controls to prevent abuse. The goal is not to replace Kerberos, but to move through it in a strictly controlled way when it cannot respond.

When to Trigger Break Glass Access

You only trigger break glass access in defined emergencies:

• Kerberos Key Distribution Center (KDC) is offline
• Ticket Granting Tickets (TGT) cannot be issued or renewed
• Compromised service accounts have locked out normal paths
• Time skew or replication failures block authentication

Emergencies must be documented with precise conditions. No guesses. No “just in case” runs. Every use is logged, reviewed, and audited.

Core Steps in a Kerberos Break Glass Procedure

1. Secure the Break Glass Credentials – Stored offline, encrypted, physically separated from main systems. They should have minimal privileges to perform the repair, not the full keys to the kingdom.
2. Authenticate Break Glass Use – Multi-party verification before unlocking credentials. No single-person control.
3. Initiate Minimal Bypass – Use the break glass principal account or emergency TGT to access the necessary realm or service. Configure it so it cannot access unrelated systems.
4. Document Activity in Real Time – Every command, change, and login recorded for post-mortem review.
5. Close the Session and Rotate Credentials – Once normal Kerberos service is restored, revoke the emergency access. Replace keys immediately to block reuse.

Security Controls for Break Glass in Kerberos

• Store break glass credentials in a vault with tamper logging
• Require two-person approval to retrieve them
• Encrypt credentials using a hardware security module (HSM)
• Run quarterly tests to confirm the procedure works under real-world failure conditions
• Keep break glass accounts outside automation scripts to block silent abuse

Why Break Glass Access Without Discipline Is Dangerous

If uncontrolled, break glass accounts can bypass Kerberos’s strong crypto authentication, giving attackers a free path. Credentials can be stolen if they are online, in plaintext configs, or in weak password managers. Even a single undetected run can undermine years of trust in your identity fabric.

Testing Break Glass Without Breaking Production

Design a staging environment that closely mirrors production Kerberos realms. Simulate outages, run the procedure end-to-end, and verify that access logs show complete capture of all activity. A working plan on paper is not enough—run it often.

When your authentication backbone fails, minutes can mean millions. Break glass procedures in Kerberos are the insurance policy that keeps you operational. But they only protect you if they’re built, locked down, and drilled until they feel like muscle memory.

If you want to see a secure, tested break glass flow in action, set it up with hoop.dev and watch it run live in minutes.