Emergency Access Is a Board Decision: Assuring the Accounts That Bypass Everything

Emergency access is frequently approved at the point of implementation and then treated as settled. A signature is added to a project file, the accounts remain in place, and the organisation moves on. That is the wrong lifecycle. Break-glass credentials are not ordinary administrative accounts with a dramatic name. They are a pre-authorised route around normal controls, and their value to an attacker is precisely the value they have to the organisation in a crisis.

For UK boards, the question is not whether emergency access should exist. It must. The question is whether the board can demonstrate that it is invoked rarely, approved properly, logged immutably and reviewed afterwards. That is a governance question before it is a technical one.

Why emergency access belongs in the board pack

Most control frameworks assume that access follows a process: a request, an approver, a role, a review. Break-glass access deliberately suspends part of that process so that a named individual can restore service when normal authentication or administration is unavailable. The suspension is the point. It is also the risk.

A standing emergency account with a shared password, no expiry and no alerting is not a resilience measure. It is a persistent privileged account that happens to be labelled emergency. When such an account is compromised, the attacker inherits the organisation's own exception. The board has, in effect, pre-approved the bypass.

Directors do not need to inspect password vaults. They do need to know that the exception has an owner, a boundary and a review date. The board pack should treat emergency access as a named risk with a named executive owner, not as a line item buried in a privileged access management programme.

The four questions a break-glass policy must answer

A board-level policy can be short, but it must answer four questions without ambiguity.

First, who may invoke emergency access? The answer should be a role or a small named group, not a department. It should also identify who may approve invocation when the usual approver is unavailable. If the policy says only that engineers may use it in an emergency, the board has not set a boundary.

Second, what control applies at the moment of use? Dual control and out-of-band approval are the minimum expectations for high-impact systems. That means a second person authorises the access through a channel separate from the system being recovered. A chat message in the same platform that is down is not out-of-band approval.

Third, what record is created? Logging must be immutable, centralised and monitored. The board does not need the raw log, but it should know where the log is held, who can delete it and whether an alert reaches someone who is not the invoker. A log that only the invoking team can edit is not an assurance record.

Fourth, when does access end and who reviews it? Time-bound expiry is essential. So is a post-use review with a defined deadline. The review should confirm what was done, whether the emergency was genuine, whether the account was disabled or rotated, and whether the underlying failure has been fixed. Without that loop, the exception becomes permanent by default.

What directors should see in their papers

Boards should resist the temptation to ask for a policy document and accept its existence as assurance. Ask for evidence that the policy operated. A useful quarterly paper might include a register of break-glass accounts showing the system or platform covered, the business owner, the invocation method, the approvers, the expiry setting, the last test date and the last review date. It should also show whether any invocation occurred in the period and, if so, the post-use review outcome.

The paper should distinguish between accounts that are technically capable of bypass and accounts that have actually been used. A long-unused account can still be a risk if it is unmonitored, but the board's attention should sharpen when an invocation has taken place. In that case, directors should expect a short incident-style summary: who invoked, who approved, what was accessed, what was changed, when the account was disabled and what the reviewer concluded.

The National Cyber Security Centre's guidance on privileged access and incident management is a useful reference point for UK organisations, but the board's standard should be simpler: can we show that the exception was controlled before, during and after use?

A fifteen-minute scenario test

A board can test its own readiness without turning the session into a technical rehearsal. Present a one-page scenario: at 02:10 on a Sunday, a major SaaS platform is unavailable and the on-call engineer cannot authenticate through the normal identity provider. The emergency account is invoked.

Ask the board five questions. Who was entitled to approve the invocation at that hour? Was the second approver independent of the recovery team? Where did the approval record sit? Which log captured the session, and who was alerted? When was the credential disabled, and who reviewed the use within five working days?

If the board cannot answer those questions from the papers in front of it, the gap is not a failure of the scenario. It is a finding about the governance of emergency access. The exercise takes fifteen minutes and is considerably cheaper than discovering the gap during an incident or a regulatory conversation.

Where UK regulators and insurers will press

Regulated firms should expect operational resilience and outsourcing questions to touch on emergency access, particularly where critical services depend on third parties. The Information Commissioner's Office will consider whether appropriate technical and organisational measures were in place if a break-glass account featured in a personal data breach. Insurers are increasingly interested in privileged access management, multi-factor authentication, monitoring and the quality of incident records. Where an emergency account was used during an incident, expect questions about who knew, when they knew and what evidence was retained.

The board's role is not to design the mechanism. It is to set the standard of proof. Emergency access should be rare, time-bound, independently approved, immutably logged and reviewed after use. If the board cannot see that pattern in its papers, it should ask why not.