Skip to content
Standing Access

Contents  ·  Access

Access During an Incident

Controls designed for normal operation fail under incident conditions. Designing the emergency path in advance, rather than suspending everything.

Procedure

During a serious incident, the controls that protect privileged access become obstacles to fixing the problem. What happens next was decided in advance or is being improvised.

What goes wrong

Approval routes require people who are asleep.

The vault is unavailable, possibly as part of the incident.

Just-in-time grants expire mid-task.

Someone declares an exception and suspends the controls entirely, which is the outcome to avoid.

Nothing is recorded, because the recording path was part of what failed.

The exception becomes permanent, because nobody unwinds it afterwards.

Designing for it

A defined emergency mode, with named conditions for entering it.

Faster approval, not none. A single approver instead of two, a wider pool, a documented self-authorisation with immediate notification.

Break-glass accounts on the systems that matter, tested.

Recording that survives the incident — logs shipped off-box, so a compromised or failed system does not take the record with it.

A time limit on emergency mode, after which it must be renewed explicitly.

A defined exit, including rotation of anything used and a review of what was done.

The self-authorisation model

Frequently the right answer out of hours.

The administrator grants themselves what they need, recording a reason.

Immediate notification to a defined group, which is the control.

Full recording of the session.

Mandatory review afterwards, within a stated period.

Faster than any approval chain, fully attributable, and it depends on the review actually happening. Without the review it is simply standing access with extra steps.

During a security incident specifically

Different from an availability incident, and it needs different handling.

Assume existing credentials may be compromised, including the ones you are about to use.

Prefer out-of-band paths that an attacker in the environment cannot observe.

Preserve evidence before remediating, which conflicts with speed and needs a decision made in advance about which wins.

Rotate as you go, rather than leaving it for afterwards when the urgency has passed.

Assume the audit log may be untrustworthy if the attacker held privileged access, which is the argument for shipping logs somewhere they cannot reach.

Afterwards

The step that is always skipped and always matters.

Rotate every credential used in emergency mode.

Review every session recorded.

Unwind every temporary grant, verified rather than assumed.

Confirm emergency mode is exited.

Record what happened and what was accessed, which is both the audit evidence and the input to improving the process.

Ask what made the emergency path necessary, and whether the normal path can be made fast enough that it would not have been.

Testing it

A tabletop annually, at minimum.

A live test of break-glass retrieval and use.

A test with the vault deliberately unavailable, which is uncomfortable and is the scenario most likely to occur.

Measure how long each step took, because the gap between the documented procedure and the achievable one is the finding.

Writing the entry criteria

Emergency mode needs a defined trigger, or it becomes a convenience.

Name the conditions: a declared incident at a stated severity, unavailability of the broker, a defined out-of-hours situation.

Name who can declare it.

Name what changes — which approvals are relaxed, which paths become available.

Name the time limit, after which it must be renewed explicitly.

Name the exit conditions and who confirms them.

Without written criteria the mode is entered by whoever finds the normal path inconvenient, which is not the same thing.

The post-incident rotation

Always required, always deferred once the urgency passes.

Every credential used during the emergency.

Every break-glass credential retrieved, whether or not it was used.

Anything typed into a session that may have been observed.

Within a defined window, tracked as an action rather than an intention.

Verified, with the old values confirmed to fail.

Recorded, because this is exactly what an auditor samples after an incident and exactly what is hardest to reconstruct later.