Who is accountable when third-party administrators access regulated systems?

Why This Matters for Security Teams

Third-party administrators often have the deepest operational reach into regulated systems, but that does not transfer accountability. The regulated organisation still has to prove who approved access, what scope was granted, whether activity was monitored, and when access was removed. That evidence requirement is central to auditability under frameworks such as the NIST Cybersecurity Framework 2.0 and aligns with the governance concerns highlighted in the Ultimate Guide to NHIs.

This is where many programs fail: the vendor contract says the provider is responsible for operations, while the security team assumes the provider’s process is enough. It is not. Regulated access needs customer-owned evidence, customer-owned approvals, and customer-owned revocation records. NHIMG research notes that only 20% of organisations have formal offboarding and revocation processes for API keys and similar access, which shows how easily access can persist after it should be gone. In practice, many security teams encounter accountability gaps only after an audit finding or incident, rather than through intentional access governance.

How It Works in Practice

Accountability should be built around the organisation that owns the regulated environment, not the party performing the work. That means third-party administrator access must be treated as privileged access under the customer’s control model, even if the provider manages the tooling or performs the day-to-day administration. Current guidance suggests using least privilege, session visibility, time-bound approval, and explicit offboarding evidence so the customer can demonstrate control end to end.

In practice, strong programmes combine contractual controls with technical controls. The contract defines who may request access, under what conditions, and what evidence must be retained. The technical layer enforces that policy through privileged access management, just-in-time elevation, session recording, and periodic recertification. For regulated environments, this is not just a vendor management issue. It is an identity governance issue tied to audit trails and access lifecycle management. The NHIMG Lifecycle Processes for Managing NHIs guidance is useful here because the same lifecycle discipline applies whether the operator is human or a third party acting inside the estate.

• Approve access with named approvers and recorded business justification.
• Scope access to specific systems, roles, and time windows.
• Use session logging or command capture for high-risk admin actions.
• Require revocation on contract end, task completion, or role change.
• Retain evidence for audit and incident response, not just operations.

For access governance models, the OWASP Non-Human Identity Top 10 is relevant because third-party administration often depends on credentials, tokens, service accounts, and break-glass access that can outlive their intended use. These controls tend to break down when the provider uses shared admin accounts or when the customer cannot independently verify session activity and revocation timing.

Common Variations and Edge Cases

Tighter third-party control often increases operational overhead, requiring organisations to balance auditability against support speed. That tradeoff becomes more visible in outsourcing, managed service arrangements, and emergency maintenance windows, where teams want fast access but regulators still expect proof of control. There is no universal standard for this yet, but best practice is evolving toward customer-owned approvals and evidence, even when the provider executes the work.

One common edge case is break-glass access. It may be justified for critical incidents, but it still needs post-event review, retroactive approval, and revocation evidence. Another is shared administrative tooling, where the provider’s own internal controls are strong but opaque to the regulated customer. In that case, the customer may need compensating controls such as independent logging feeds, token scoping, or customer-managed identity boundaries. The NHIMG Regulatory and Audit Perspectives section is especially relevant because auditors generally care less about who clicked the button and more about whether the regulated organisation can prove the access was controlled, scoped, monitored, and removed.

In mature programmes, accountability also extends to downstream access chains. If a third party can delegate access to subcontractors or automation, the regulated organisation still needs visibility into those sub-delegations. That is where governance fails most often: access is approved once, then quietly expands through operational shortcuts, and the customer discovers the gap only after reviewing the evidence trail against the requirements in the 52 NHI Breaches Analysis.

Related resources from NHI Mgmt Group

• Who is accountable when third-party access to OT systems is over-permissioned?
• Who should be accountable for third-party access that can affect patient systems?
• What breaks when third-party access is left open too long?
• Who is accountable when third-party remote access is overused in public safety environments?