What is the best way to audit break glass access on shared devices?

What makes break glass access auditable on a shared device?

Break glass access is only auditable when the emergency session can be tied to one named person and one specific use of the shared device. On shared endpoints, that means the device must not become a generic pool account shortcut. The audit trail should show who used it, when, why, and what privileged actions followed.

Individual sign-in before elevation is the key design choice. If the emergency path starts from a shared account, you lose attribution before the privileged action even begins. The audit record needs to capture the user identity first, then the elevated activity, so review can distinguish emergency access from ordinary shared-device use.

Because the device is shared, you also need custody context around the session. That includes which person had the device in hand, whether the session was transferred, whether the screen was locked or cleared between users, and whether the access event matched an approved emergency path rather than an informal workaround.

How should the audit evidence be structured?

The cleanest audit record combines four evidence layers: device usage, identity, approval, and action. Device usage shows the shared endpoint was under a known operator’s control. Identity shows the named operator. Approval shows the access was authorised or at least exception-handled. Action records show exactly what privileged commands or administrative changes were taken.

Session recording strengthens the audit because it fills the gap between log entries and actual behaviour. Logs can tell you that elevation happened, but not always whether the operator stayed within the emergency purpose. A recording, or at minimum a detailed command trail, helps prove that the session was limited to the break glass need and not broader admin work.

Review should compare the emergency session to the approval record and to the custody timeline. If the person who used the device is not the person recorded in the approval, or if the session started before the approved window, the audit is incomplete even if the underlying access worked as intended. That mismatch is usually the first sign of a weak control model.

What gets missed most often in shared-device emergency access?

The most common miss is treating the shared device as sufficient evidence of control. It is not. Without individual sign-in, attribution collapses, and without per-session review, a legitimate emergency path can quietly become a standing privileged access path. Shared-device convenience often hides that drift until an incident or audit asks for proof.

Another common gap is failing to separate emergency access from routine admin work. If operators use the same device, the same browser profile, or the same session across multiple tasks, the audit trail becomes ambiguous. A break glass event should stand out as a bounded exception with a short, defensible evidence chain.

Use Break-Glass and Emergency Access Account Guide to align the audit trail with how emergency access should be designed and monitored, not just used.

The shared-device angle is also why Kiosk and Shared Device Security Guide matters here: if the endpoint keeps stale sessions, shared profiles or unclear custody, the audit evidence will be weaker than the access control.

Practitioner Guidance

What to verify: Confirm that every break glass event has a unique operator identity, a timestamped approval or exception record, and a corresponding device custody signal. If any one of those is missing, treat the record as incomplete even if the privileged action itself is logged.

Decision rule: If the emergency access path cannot distinguish one person from the next on the same device, redesign the flow before relying on the logs. The control objective is not merely to log elevation, but to preserve attribution after elevation.

What good looks like: A reviewer can reconstruct the event from start to finish without guessing who was present, why the access was used, or which actions belonged to the emergency session.

Practitioner takeaway: On shared devices, break glass auditing succeeds only when identity, approval, custody and privileged actions line up into one defensible chain of evidence.

Related resources from NHI Mgmt Group

• Why does break-glass access create so much audit and compliance risk?
• What happens when organisations keep shared credentials and break-glass access in a FedRAMP environment?
• What are the best practices for break-glass access in incident response?
• What is the best way to manage network access when users, devices, and teams change frequently?