Who is accountable when a partially offboarded account is still active?

Why This Matters for Security Teams

A partially offboarded account is not a paperwork issue. It is an access-control failure with real operational impact because the account can remain active in one system while another team assumes revocation is complete. Accountability therefore belongs to the system owner who can demonstrate closure, not the group that originally granted access. That aligns with NIST guidance on accountable control ownership in NIST SP 800-53 Rev 5 Security and Privacy Controls.

For NHI programs, this problem is common because service account, API keys, tokens, and certificates often span IAM, CI/CD, vaults, SaaS consoles, and infrastructure tools. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That gap means “offboarded” frequently means “removed from one place, still live somewhere else,” which creates hidden residual risk across the access path. The practical question is not who opened the account, but who can prove every path to it has been removed. In practice, many security teams discover incomplete offboarding only after an audit, incident, or customer complaint exposes the remaining access.

How It Works in Practice

Accountability should follow the control point that can verify revocation. In a multi-tool environment, that usually means the service owner, platform owner, or workload owner closest to the live credential store. If an account touches IAM, a secret manager, a CI/CD pipeline, and an application config, each owner must validate their own removal step and preserve evidence of closure. The NIST identity model also reinforces that identity proofing and lifecycle events must be reliable, not assumed, as described in NIST SP 800-63 Digital Identity Guidelines.

Operationally, mature teams treat offboarding as a chain of attestations rather than a single ticket. A practical workflow usually includes:

• Identify every system where the account, key, token, or certificate exists.
• Assign one accountable owner per system, with a timestamped revocation record.
• Revoke the primary credential first, then confirm dependent secrets and cached tokens are invalidated.
• Verify no automation, job runner, or integration can still mint or reuse access.
• Keep evidence of closure in a single record that can survive audits and incident reviews.

This is especially important for NHIs because lifecycle management often breaks across departments. The NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both emphasize that revocation, rotation, and visibility must be treated as lifecycle controls, not one-time admin tasks. Where ownership is unclear, the safest interpretation is that the account remains active until every dependency is proven closed. These controls tend to break down when offboarding spans legacy systems, delegated admin models, or manually managed secrets because no single system can attest to the full access path.

Common Variations and Edge Cases

Tighter offboarding controls often increase coordination overhead, requiring organisations to balance faster shutdowns against the risk of false closure. That tradeoff becomes sharper when a single account supports multiple applications, shared automation, or third-party integrations. In those cases, current guidance suggests using a strict evidence standard: if one owner cannot prove revocation, the account should remain in the active-risk register until the gap is resolved.

A common edge case is shared service access, where one team decommissions the original account but downstream systems still cache the token or certificate. Another is delegated administration, where the owning team believes the platform team handled revocation, but the platform team only disabled login and did not remove machine credentials. The same issue appears in emergency access, where temporary access was approved quickly and then forgotten after the incident.

NHIMG research on Top 10 NHI Issues highlights visibility and rotation as recurring failure points, and the broader breach record in the Coupang Signing Key Breach shows why leftover signing and service credentials cannot be treated as administrative leftovers. The safest operational rule is simple: if the account can still authenticate anywhere, accountability is not complete.

Related resources from NHI Mgmt Group

• When does a short-lived API key still create material risk?
• How should security teams govern Active Directory service accounts?
• When does a service account become a compliance problem?
• Who is accountable when a vendor account remains active after the work ends?