Who is accountable for access recertification and deprovisioning when organisations adopt zero trust?

Why This Matters for Security Teams

zero trust changes the accountability model, but it does not eliminate it. Identity and access management teams can operate the recertification process, yet business owners still decide whether access remains justified, and application owners often know which privileges are truly required. That distinction matters because access reviews are only effective when someone with operational context can validate necessity, not just technical presence.

Current guidance in NIST SP 800-207 Zero Trust Architecture emphasizes continuous verification and explicit policy enforcement, which means stale access cannot be left to informal ownership. NHIMG’s Ultimate Guide to NHIs shows why this becomes urgent in practice: only 20% of organisations have formal offboarding and API key revocation processes, and 97% of NHIs carry excessive privileges. In zero trust environments, those gaps quickly become audit findings or breach paths.

In practice, many security teams encounter unresolved access sprawl only after a deprovisioning failure, not through a planned recertification cycle.

How It Works in Practice

Accountability usually needs to be split across three layers. IAM or identity engineering runs the process, system or application owners validate the access list, and business owners approve whether the access is still required. Zero trust makes that split more visible because access decisions are expected to be explicit, time-bound, and tied to policy rather than assumed to remain valid indefinitely.

A workable model typically includes:

• IAM owns the workflow, evidence collection, and enforcement of deadlines.

• Business owners attest that the user, service account, or NHI still has a legitimate purpose.

• Application owners confirm privilege scope, shared accounts, and environment-specific exceptions.

• Security or GRC validates that recertification, deprovisioning, and exception handling are auditable.

For non-human identities, this becomes even more operational. The OWASP Non-Human Identity Top 10 highlights the risks of unmanaged secrets, excessive privileges, and weak lifecycle controls. NHIMG’s NHI Lifecycle Management Guide reinforces that offboarding is not a single event: credentials, tokens, certificates, and API keys must be revoked, rotated, or expired in a controlled sequence. Best practice is evolving toward just-in-time access, short-lived secrets, and policy-driven approval chains, but there is no universal standard for this yet.

Where organisations mature, recertification is tied to asset ownership, data sensitivity, and privilege tier, with automatic removal if no approver responds. These controls tend to break down when ownership records are stale or when shared administrative access has no clearly named business owner.

Common Variations and Edge Cases

Tighter recertification controls often increase operational overhead, requiring organisations to balance stronger assurance against slower delivery and more approval noise. That tradeoff is manageable for high-risk systems, but it becomes harder in environments with large numbers of service accounts, shared integrations, and machine-to-machine access paths.

One common edge case is delegated administration. A central IAM team may manage the tooling, while a platform team or product owner is the only group that can judge whether a service should keep elevated access. Another is emergency access, where temporary privilege is granted for incident response and must be reviewed after the event, not folded into the next standard cycle. For service identities, the accountability question is often less about “who requested it” and more about “who owns the workload that uses it.”

NHIMG research on the Ultimate Guide to NHIs — Key Challenges and Risks shows why this matters: 71% of NHIs are not rotated within recommended time frames, which means deprovisioning discipline must be matched with rotation and expiry discipline. In practice, organisations that rely on annual attestations alone tend to miss accounts that are technically active but functionally abandoned.

When access is tied to federated workloads, external partners, or autonomous agents, the review owner may also need to validate runtime policy, not just static entitlements, and that responsibility is still emerging rather than settled.

Related resources from NHI Mgmt Group

• Why do rapid onboarding and deprovisioning become harder as organisations adopt more cloud services and automation?
• Who should be accountable for closing access-trust gaps across BYOD, shadow IT, and unmanaged applications?
• Who is accountable for securing access when IAM alone does not verify device trust?
• Why do standing access rights create more risk in SOX and zero trust environments?