Break-glass access

In most of the industry, break-glass means an emergency bypass: the approval queue is unavailable, the systems are down, so a designated account is used to get in and the whole event is heavily logged. If that is what you came here for, read the next paragraph carefully.

Qorionix's break-glass does the opposite. Marking a request as break-glass raises the number of approvals required from one to two. It does not bypass approval, it does not bypass multi-factor authentication, and it does not bypass the session limits on the credential. It is a declaration that this access is exceptional, which makes it slower and more visible — not a route around the controls.

That is a defensible design and it is not what the name suggests, so this article states the mechanics first and then deals properly with the question you probably actually have: what do you do when the person who approves is unreachable.

What break-glass actually does

There is no separate break-glass page, route or record type. It is a flag on an ordinary access request. Set is_break_glass to true — or set the subject type to break_glass, which does the same thing — and three consequences follow.

A break-glass request can also carry an activation region and an activation cell identifier, which are recorded for context. Everything else about the request — the mandatory justification, the mandatory attestation from each approver, the duration and its expiry, the single-use binding to one session — behaves exactly as a normal request does.

What to do after a break-glass session

1. 1

   Rotate the credential

   Use the rotate-now control on the credential's schedule, or rotate the account manually on the target if it has no schedule. Do this the same day, not at the next scheduled interval — which on the default setting is thirty days away.

2. 2

   Read the session's keystroke index while it still exists

   The recording body lives in the API process's memory and is lost on restart. If a break-glass session is going to be reviewed, export the evidence now rather than next week.

3. 3

   Read both attestations

   Two approvers each had to write what they checked. That text is the record of why an exception was made, and it is the part of the trail that an auditor will actually read.

4. 4

   Write down why normal approval was not used

   The platform records that break-glass was used. It does not record why the ordinary route was unavailable, and that is usually the more interesting question.

What is logged

Break-glass is visible without inference, which is the part of the design that works well. Three places carry it explicitly:

• The pam.access_request.create audit entry carries the break-glass flag in its metadata.
• The pam.session.start audit entry carries it too, so a break-glass session can be found from the session side without joining back to the request.
• The pam.session.terminate entry carries the rotation status, so you can find sessions that ended with a rotation outstanding.

The console shows a break-glass count on the sessions view. The request and session records both expose the flag, and it is readable by anyone with the access-request read or session read permission — which includes the viewer role, deliberately: knowing that an emergency access happened is not sensitive in the way the credential is.

Planning for when normal approval is unavailable

This is the real problem and break-glass does not solve it. Break-glass needs two approvers; if you cannot find one, you certainly cannot find two. So plan for the case explicitly, before it happens. Four things to decide, in order of how much they help.

Make sure more than one person can approve

The commonest cause of an approval emergency is that one person holds the permission and is on a plane. Approving requires the pam:access_requests.write permission. Check who has it, make sure it is at least two people, and make sure they are not always in the same place, on the same holiday rota or on the same phone network. This is dull and it removes most of the risk.

Know what would let you through, and decide about it in advance

There are three ways privileged access happens today without a second person, and you are better off knowing them than discovering them at three in the morning. None is a feature; all three are honest descriptions of the current behaviour.

1. A credential with no policy attached to it requires no approval at all. Approval is a policy control, and policies are matched to a credential by credential, by target, or organisation-wide. If none matches, the loop that would demand approval runs zero times — no approval, no multi-factor prompt, no concurrency cap. This is the largest and quietest gap in the module. The fix is not an emergency plan, it is to create an organisation-wide policy so there is no unpoliced credential; see PAM access policies.
2. Self-approval is not prevented. The same permission raises a request and approves one, and nothing compares the approver against the requester. So a single person holding that permission can raise and approve their own request for a normal, one-approver request. This is a weakness in normal operation. It is also, in practice, your working emergency path today — and it is fully audited, with the same identity visible on both sides of the record.
3. An administrator can set require_approval to false on a policy. That requires the policy-write permission, which is admin-only. It is a standing change rather than an emergency action, and if you make it, decide in advance how you will notice and reverse it. Note that policies combine as most-restrictive-wins, so a per-credential exemption does not override an organisation-wide requirement.

Keep one genuine emergency credential outside the platform

This is advice rather than a product feature, and it is the thing most organisations of your size actually need. Pick the smallest possible set of accounts that would let you recover — a domain administrator, the firewall's local admin, the hypervisor console — write those credentials down on paper, seal them, and put them in a physical safe with a signed log of who opened it. Do not manage them in Qorionix, because the scenario you are planning for includes Qorionix being unavailable.

Then treat opening that envelope exactly as you would treat a break-glass session: rotate every credential in it afterwards, and record why it was opened. An emergency credential that is never rotated after use stops being an emergency credential and becomes a shared password.

Write the plan down while nothing is on fire

One page: who approves, who approves when they cannot, where the safe is, who may open it, and what must be rotated afterwards. The value of this page is that it is written by people who are calm, and read by people who are not.

One thing that is not this feature

There is a second, stronger break-glass mechanism inside the platform, and it is not available to you. It issues signed, single-use, time-boxed emergency tokens with a hard one-hour ceiling, requires two genuinely distinct operators — enforced by a database constraint, not by convention — and transitions its own records to expired when they lapse. It exists so that Qorionix's own operations staff can reach a customer environment during an incident, it runs in a separate service on an internal-only interface, and it is not part of the privileged access module you administer.

We mention it for two reasons. First, so that a phrase you may see in an architecture document does not get mistaken for a feature on your console. Second, because it is a fair description of what tenant break-glass should eventually look like, and the difference between the two is a reasonable thing to ask us about.

What to do next

1. Create an organisation-wide access policy so that no credential is unpoliced — this closes the largest gap named above.
2. Check who holds the approval permission and make sure it is more than one reachable person.
3. Set up rotation on the credentials you would use in an emergency, so that rotating after use is one click rather than a project.