Who is accountable when a shared-device access process fails compliance or audit review?

Why This Matters for Security Teams

When a shared-device access process fails review, the issue is rarely just “missing paperwork.” It usually indicates that the organisation cannot prove who approved access, how long it lasted, whether it was revoked, or whether the device itself was governed as a controlled asset. That matters because auditors look for repeatable control ownership, not informal handoffs. Guidance in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives and the OWASP Non-Human Identity Top 10 both point to the same operational reality: shared access fails when identity, device, and workflow controls are split across teams without a clear owner. The accountability question is therefore not academic. If a shared terminal, kiosk, or floor device can be used by multiple people or automated processes, the device lifecycle becomes part of the access control boundary. That boundary needs explicit evidence for RBAC decisions, JIT access, logging, and revocation, or the review will fail even if the access was well intended. In practice, many security teams discover this only after the audit trail is challenged, rather than through intentional control testing.

How It Works in Practice

The practical answer is to assign a single accountable owner for the control, then distribute execution tasks across IAM, OT security, and operations. Accountability does not mean one team performs every task; it means one team is answerable for the design, evidence, and continuous operation of the process. For shared-device access, that owner should be responsible for:

• defining who may use the device and under what conditions;
• requiring JIT access rather than standing access where feasible;
• making access approvals time-bound and revocable;
• ensuring device logs, badge events, and session records can be reconciled;
• reviewing exceptions and compensating controls regularly.

This is aligned with the lifecycle emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the operational focus of the NHI Lifecycle Management Guide. It also matches the NIST CSF 2.0 expectation that organisations define governance, access management, and monitoring as linked functions rather than isolated tasks, as described in the NIST Cybersecurity Framework 2.0. For many environments, the cleanest control model is: operations owns the device, IAM owns identity proofing and entitlements, and OT security owns risk acceptance and monitoring. The accountable owner signs off on the control design, the exception process, and the evidence package used for audit. These controls tend to break down when shared devices are unmanaged physical endpoints in plants, warehouses, or clinical areas because local supervisors often grant access informally and logs are incomplete.

Common Variations and Edge Cases

Tighter access control often increases operational friction, so organisations must balance auditability against throughput and frontline usability. That tradeoff becomes visible in 24x7 operations, shift-based plants, and emergency response settings where shared-device access cannot always wait for a manual approval. Current guidance suggests using a documented exception path rather than weakening the baseline control. There is no universal standard for this yet, but good practice is to define whether the device is a shared human workstation, a privileged admin console, or a machine-to-machine access point, because each one has different evidence requirements. Where agents or automated tools use the same device pool, the process should also distinguish human access from workload identity access, since the control owner may need to manage both session-based approvals and ephemeral secrets. The issue is especially important where access is tied to a high-risk service, because shared endpoints often become the weakest link between policy and actual use, as highlighted in Top 10 NHI Issues and the 52 NHI Breaches Analysis. For regulated organisations, the safest pattern is to make exception ownership explicit, time-box it, and require post-event review. That is also where governance frameworks matter: Regulatory and Audit Perspectives should map to a named control owner, not a committee with no final sign-off authority.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• Who is accountable when password governance fails in a regulated environment?
• Who is accountable when OT remote access cannot be traced after the fact?
• Who is accountable when ePA access controls fail?