Break-glass banking access: emergency credentials without creating a permanent back door

Break-glass access is an emergency route that lets authorised staff reach a critical banking service when normal identities, devices or approval paths are unavailable. This guide explains the mechanics, evidence, risks and controls a UK business should understand before relying on the process.

What this means in practice

Break-glass access is an emergency route that lets authorised staff reach a critical banking service when normal identities, devices or approval paths are unavailable. This becomes material when the business commits cash or relies on funding before confirming that the external condition has actually been satisfied.

The access should be exceptional, tightly controlled and recoverable: activation must be limited, logged and followed by credential reset or formal deactivation after the incident. The exact wording, bank implementation or scheme rule matters, so a process copied from another facility or institution should not be assumed to produce the same result.

How the process works

The operating sequence should start with the trigger, move through validation and approval, and end only when the external result is confirmed. For this topic, the critical mechanics are: The access should be exceptional, tightly controlled and recoverable: activation must be limited, logged and followed by credential reset or formal deactivation after the incident.

Planning should work backwards from the required result rather than from the internal submission date. A correct instruction can still fail operationally if the company misses a notice period, scheme window, bank cut-off or response deadline.

The data and evidence that matter

Operational review starts with emergency user or process, activation authority, storage method, MFA route, permitted actions, activation log, transaction log and post-use reset confirmation. The aim is to connect the commercial requirement to the exact bank, lender or counterparty status that determines what the company may do next.

The legal entity must remain visible throughout. Group reporting is helpful, but cash, debt and authority belong to particular entities, and the wrong entity assumption can invalidate an otherwise careful calculation.

Where the process can fail

An emergency account that is always enabled and rarely reviewed becomes a hidden privileged account rather than a resilience control. The exposure usually becomes more expensive to fix as the company gets closer to payment, settlement, testing or maturity.

A second failure mode is status confusion. Submitted, approved, accepted, processed and settled are different states, and systems that collapse them can make accounting or liquidity look complete before the external process is finished.

Worked example: test the mechanics

The identity provider is unavailable during a major outage, blocking normal portal users. A sealed emergency banking process lets two authorised executives access one critical payment function. After service returns, the emergency credentials are rotated and every action is independently reviewed.

The figures are illustrative, not universal terms. In a live case the company should replace every amount, date and threshold with the current bank, scheme or contractual evidence, then rerun the decision before cash is committed.

Governance and control design

Require dual control for activation, limit permissions to essential actions, test the route periodically and perform a mandatory post-use review. The evidence should sit beside the transaction so a second person can reproduce the decision without reconstructing the chronology from emails.

Management information should include last emergency-access test, activations, actions performed and time to revoke or rotate access after use. The purpose is to show whether exposure is building before it becomes a funding, settlement or operational incident.

Change management matters as much as daily operation. When a bank changes formats, a facility is amended, a new entity joins the group or a treasury system is upgraded, the company should retest the process from source data through external confirmation and reconciliation. For this article, the deciding evidence is emergency user or process, activation authority, storage method, MFA route, permitted actions, activation log, transaction log and post-use reset confirmation; the control is incomplete if those fields cannot be tied to one dated case.

Ownership should also survive absence and staff turnover. The procedure should say who acts, who reviews, where evidence is stored and what happens if the normal owner cannot complete the step. For break-glass banking access, undocumented expert knowledge is itself an operational dependency.

Reconciliation is part of governance, not only accounting. For this topic, the operating record should eventually connect emergency user or process, activation authority, storage method, MFA route, permitted actions, activation log, transaction log and post-use reset confirmation to the financial outcome so treasury can prove that the intended action and the actual cash result agree.

Responsibility should extend beyond the immediate transaction. If an emergency account that is always enabled and rarely reviewed becomes a hidden privileged account rather than a resilience control. the post-event review should identify whether the cause was data, timing, authority, system design or misunderstanding of the external rule, then assign a specific remediation owner.