What is break-glass access?

Break-glass access is emergency access to a production system that bypasses the normal approval workflow. It exists for situations where waiting for an approval would cause more damage than acting immediately, and where the risk of doing nothing outweighs the risk of acting without a second pair of eyes.

When is break-glass access actually used?

It is used when production is down and the on-call engineer cannot reach the system owner at 3 AM, or when a security incident is unfolding and every minute of delay increases the blast radius. The scenario is always some version of: normal process too slow, cost of waiting too high, act now and explain later.

This is not for convenience. Engineers who reach for break-glass because the approval queue is slow are misusing it. The pattern only makes sense when the normal path is genuinely unavailable or would cause harm.

How should break-glass access be logged?

Every use must be logged automatically and immediately, with no way for the user to suppress or delay the log. The log should capture who accessed what, when, from where, and what commands were run. An alert should fire the moment credentials are used – not batched, not delayed.

Time-boxing matters too. Break-glass credentials should expire after a short window, typically one to four hours, rather than remaining active indefinitely. If the incident takes longer, the engineer should re-invoke the process explicitly, which creates another log entry.

How does this work at a small company versus a large one?

At a 15-person startup, break-glass often means a shared secrets manager entry (a root IAM key or a stored credential) that is protected by a strong password kept in a password manager. One person holds it. Every use gets logged to a Slack channel that everyone can see. Post-incident, the password rotates.

That setup is not elegant, but it works. The important parts are the same: access is narrow, use is visible, and rotation happens afterward.

At larger companies, break-glass is usually a formal runbook: a named role with pre-attached permissions, a dedicated Slack command that mints time-limited credentials, an automated PagerDuty ticket that opens on use, and a mandatory post-incident review within 48 hours. The principle is identical, the automation is heavier.

The practical gap between small and large is not in the concept – it is in whether the process is written down and whether anyone has tested it recently.

What is the most common mistake with break-glass access?

Building it and never testing it. Teams configure a break-glass credential, document the procedure, and then leave it alone for 18 months. When an incident finally happens, the credential has been rotated but the runbook points to the old one, or the IAM role has drifted and no longer has the permissions it needs, or no one can find the documentation under pressure.

Break-glass access should be exercised in a staging environment on a regular cadence – quarterly at minimum. The exercise does not need to simulate a real incident, but it should confirm that the credential works, the alert fires, and at least two people know the procedure.

How is break-glass different from just-in-time access?

Just-in-time access is the normal pattern for getting elevated permissions. An engineer requests access for a task, a policy or a human approves it, short-lived credentials are issued, and they expire when the task window closes. The process has a built-in approval gate.

Break-glass removes that gate. There is no approval step, no waiting, no second person required before access is granted. That is exactly what makes it useful in an emergency and exactly what makes it dangerous if misused. The two patterns serve different threat models: JIT handles planned work with human oversight; break-glass handles crisis situations where that oversight would itself become the problem.

Korvalis is designed around this distinction, enforcing JIT access as the default path and keeping break-glass as a narrow, heavily audited exception.