Who is accountable when identity decisions are not governed?

Why This Matters for Security Teams

When identity decisions are not governed, accountability disappears into the seams between IAM operations, application teams, platform engineering, and security review. That is more than a process gap. It means no one can prove who approved access, why it was granted, or when it should be revoked. NIST’s Cybersecurity Framework 2.0 treats governance as a core security function because the question is not whether a login works, but whether the entitlement behind it is defensible.

For NHIs, the risk escalates quickly because these identities are numerous, persistent, and often over-permissioned. NHIMG notes in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, which makes weak ownership especially dangerous. Without explicit governance, teams inherit access drift, hidden dependencies, and unclear escalation paths that only surface after an incident or audit finding. In practice, many security teams encounter entitlement disputes only after a compromise, not through intentional review.

How It Works in Practice

Accountability starts with naming a decision owner for each identity class and each access pathway. For human users, that may be a manager, application owner, or delegated approver. For NHIs, the accountable party is usually the service owner or product owner who requested the identity, with IAM and security acting as control enablers rather than final owners. The key is that every privileged decision must be reviewable, time-bound, and tied to a business purpose.

Operationally, this usually means combining ownership metadata, approval workflows, and periodic access review. The lifecycle view in NHIMG’s Lifecycle Processes for Managing NHIs is useful here because accountability has to exist at provisioning, rotation, exception handling, and offboarding. In parallel, policy mapping should align with NIST CSF governance outcomes and access control expectations. Where possible, teams should define:

• who approves the identity at creation time,
• who owns its ongoing business justification,
• who can authorize exceptions,
• who receives review findings, and
• who is required to revoke or rotate credentials on expiry or role change.

Practitioner guidance also points to auditability as the enforcement mechanism, not just documentation. The Regulatory and Audit Perspectives section of the Ultimate Guide to NHIs emphasises that access decisions should be reconstructable after the fact, which is what converts “shared responsibility” into real accountability. These controls tend to break down in highly automated CI/CD environments because identities are created faster than ownership records, approvals, and revocation workflows can keep up.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance speed against provable ownership. That tradeoff becomes sharper in environments with ephemeral workloads, outsourced application support, or shared platform services, where a single identity may serve multiple teams. Current guidance suggests that accountability should follow the service consuming the identity, but there is no universal standard for this yet, especially in multi-tenant or agent-driven systems.

One common edge case is the “platform team owns everything” model. It simplifies administration, but it can also create false accountability if the platform team approves access without understanding the business use case. Another is emergency access, where break-glass privileges are intentionally fast but often poorly governed. Those exceptions need explicit review after use, otherwise they become standing privilege by another name.

NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the same lesson: governance failures are usually not about a missing tool, but about unclear ownership and weak enforcement. Where third-party vendors or shared service accounts are involved, organisations should require named accountability in contracts and internal control maps, because otherwise no internal team can practically own the risk.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• When does secret exposure become a broader identity risk?
• What is the difference between patching a vulnerability and reducing identity blast radius?