Who is accountable for credential governance when access spans identity platforms, PKI, and physical tokens?

Why This Matters for Security Teams

When access spans identity platforms, PKI, and physical tokens, the risk is not just technical fragmentation. It is governance fragmentation. Each control plane may be operated by a different team, but the organisation still needs one accountable owner for policy, lifecycle decisions, and evidence. Without that owner, revocation, recovery, and exception handling drift apart, and auditors are left reconciling contradictory records.

This is why identity governance must be treated as a cross-domain control, not a set of isolated admin tasks. The governance model should align with NIST Cybersecurity Framework 2.0 principles for accountability and control ownership, while recognising that credential failures often start in the seams between systems. NHIMG’s research on Top 10 NHI Issues shows that identity sprawl and inconsistent lifecycle control are recurring causes of exposure across environments.

In practice, many security teams discover the accountability gap only after a failed revocation, an expired certificate still being accepted, or a lost token that was never formally decommissioned.

How It Works in Practice

The cleanest operating model is to assign one business owner for credential governance and then define shared execution responsibilities across IAM, PKI, and endpoint or badge teams. That owner sets policy for issuance, renewal, revocation, recovery, logging, and periodic review. The operational teams execute those controls in their own platforms, but they do not each define separate governance rules. That distinction matters because a common failure pattern is treating platform administration as the same thing as accountability.

For example, IAM may manage application entitlements, PKI may issue and revoke certificates, and physical security may control smart cards or hardware tokens. Yet the governance decision about who is allowed to hold what credential, for how long, under what assurance level, and with what approval path must be centrally defined. That central model should be mapped to control families in NIST SP 800-53 Rev 5 Security and Privacy Controls and should include evidence collection from all three domains.

• Define one authority for credential policy, even if implementation is distributed.
• Use a single lifecycle standard for issuance, rotation, revocation, and emergency recovery.
• Require traceable logs that tie platform actions back to named approvals.
• Test cross-domain revocation so a disabled identity cannot retain an active certificate or token.

Where this becomes especially important is in NHI environments, where credentials can be embedded in automation, certificates, or tokens that outlive the administrator who issued them. NHIMG’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, and that gap often reflects unclear ownership rather than missing tools. These controls tend to break down when identity, PKI, and physical token teams each optimise for their own workflow because no one is accountable for the full credential lifecycle.

Common Variations and Edge Cases

Tighter credential governance often increases coordination overhead, requiring organisations to balance stronger control with faster operations. That tradeoff becomes visible in mergers, multi-cloud estates, and environments with both employee and machine credentials, where a single governance model may need to span different assurance levels and different revocation workflows.

There is no universal standard for exactly how to split responsibilities between IAM, PKI, and physical security, but current guidance suggests keeping accountability with the function that owns access policy, while delegating execution to the specialist teams. In highly regulated environments, the accountable owner is often an identity governance or security operations leader. In smaller organisations, it may sit with the CISO or head of IAM, provided the role has authority over policy enforcement and audit evidence.

Two practical edge cases deserve attention. First, emergency recovery can blur ownership if a lost token or expired certificate must be restored quickly. Second, service identities and non-human access often require faster turnover than human credentials, which makes static approval chains too slow. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it highlights why long-lived credentials are harder to govern than ephemeral ones. The key is to decide in advance who can approve exceptions, who can revoke across all platforms, and who is responsible when evidence is incomplete.

Related resources from NHI Mgmt Group

• Which frameworks require stronger identity governance controls for sensitive access and regulated data?
• Who is accountable for secret rotation and access governance in OpenTofu deployments?
• Who is accountable when a weak login design allows access to multiple systems through one compromised identity?
• Who is accountable for OAuth governance when third-party apps and AI tools keep access to sensitive data?