Expiry by Design: Reclaiming Emergency Access from Permanent Exceptions

Emergency access has a habit of outliving the emergency. A local administrator account created during a failed upgrade, a vendor support login issued for a single warranty case, or an SSO bypass kept for the day federation fails can all remain active long after the original reason has gone. In many UK organisations, the federated identity estate is well governed. The residue is less tidy, and it is where quiet privilege accumulates.

The control question is not whether exceptions exist. Every estate has some. The question is whether each exception can be named, owned, tested and ended. A break-glass census turns an informal collection of workarounds into a managed register with dates and evidence.

Define the estate before counting it

Start by defining the scope. The census should cover every authentication path that does not pass through the primary identity provider. That includes local administrator accounts on servers, network appliances and operational technology; vendor support accounts held by a managed service provider or maintained remotely; application-local logins for legacy systems that were never federated; service accounts with interactive login rights; and fallback accounts used when single sign-on is unavailable.

The scope should also include cloud services where a local administrator exists alongside federated access, and any SaaS platform where an MSP or implementation partner retains a separate login. A useful test is simple: if the primary identity provider were unavailable tomorrow, which credentials would still open a door? Those are the accounts the census must find.

Build the census from evidence, not memory

Memory is a poor inventory. Assemble the register from artefacts that already exist: identity provider exclusion lists and emergency access groups, password vault entries, configuration management databases, asset inventories, vendor contracts, support tickets, VPN and firewall rules, and SaaS administration rosters. Where local account enumeration is technically feasible and authorised, use management tooling to collect account names and last logon data rather than relying on interviews alone.

Reconcile the sources. An account may appear in a password vault but not in the asset inventory, or on a server but not in the vendor contract. Each discrepancy is a finding. Record one entry per credential or access path, with fields for the system, account type, authentication method, privilege level, business owner, creation reason, expiry date, last test date, dependencies and compensating controls. The register should be dull, precise and auditable.

Give every exception an owner and an end date

An exception without a named owner is an orphan. Ownership should sit with an accountable role, not a team mailbox. The owner should be able to explain why the account exists, what would break if it were removed, and when it will next be reviewed.

Expiry dates should be realistic but finite. An incident account created for a specific recovery effort might carry a 30- or 90-day expiry. A vendor support account might be approved for a contract term, but only with a documented access method such as enablement on request. A permanent exception should be rare and should require explicit risk acceptance rather than passive renewal. The register should flag any account whose expiry has passed, whose owner has left, or whose last review predates the current financial year.

Test the path under controlled conditions

An emergency account that has never been tested is a claim, not a control. Testing should confirm that the credential is available to the right people, that it grants only the intended privilege, that access is logged and alerted, and that the recovery path works when the primary identity provider is unavailable. It should also confirm that the account can be disabled and re-enabled cleanly.

Tests should run in a change window with named approvers and a rollback plan. Where production testing is too risky, use a tabletop exercise backed by configuration review, or test in an isolated environment that mirrors the production path. Record the result, the date, the tester and any remediation. Remove test artefacts afterwards. The aim is not to prove that break-glass access is convenient. It is to prove that it is controlled.

Retire, narrow or formalise

Not every exception should be removed. Some are legitimate. But each should be placed in one of three outcomes. Retire it where the need has gone. Narrow it where the need remains but the privilege is too broad. Formalise it where it is genuinely required, with an owner, a review cycle and monitoring.

Retirement should include disabling the account, rotating or destroying credentials, removing remote access rules, updating the vault and recording the evidence. Narrowing might mean replacing a standing local administrator with just-in-time elevation, moving a service account to a managed identity, or requiring vendor access to be enabled only for a support window. Formalisation might mean adding the account to a privileged access management workflow and alerting on every use.

Vendor accounts deserve particular scrutiny. A support login that is always on is not a break-glass control; it is a permanent remote path. Contract terms should support time-bound enablement, named individuals and audit access. Where a supplier insists on standing access, that should be a recorded commercial and security decision, not an operational default.

Make the census repeatable

The first census will be the hardest. The second should be routine. Reconcile the register quarterly against the identity provider, vault, asset inventory and vendor list. Automate discovery where possible and alert on new local accounts, new bypass groups and accounts that have not been used for an extended period. Link the register to joiners, movers and leavers so that an owner leaving triggers a review rather than an orphan.

Report a small set of measures to the risk or audit committee: total exceptions, exceptions without an owner, exceptions past expiry, exceptions untested in the last twelve months, and exceptions removed since the last report. These measures show whether the organisation is reducing permanent residue or simply counting it.

A break-glass account is not a failure of identity design. It is a deliberate fallback for the day the primary path is unavailable. The failure is allowing the fallback to become ordinary. The census is how UK organisations make emergency access visible again, and how they give it the one thing it often lacks: an ending.