Who is accountable when access certification decisions are made at enterprise scale?

Why This Matters for Security Teams

Enterprise-scale access certification is not an administrative checkbox. It is a control that decides whether people, service accounts, API keys, and other NHIs keep the authority to reach sensitive systems. When accountability is vague, reviews become rubber-stamps, especially across recurring campaigns and high-volume entitlements. NHI Mgmt Group’s Ultimate Guide to NHIs notes that NHIs can outnumber human identities by 25x to 50x in modern enterprises, which makes ownership discipline a security issue, not a process preference.

The accountable party should be the business or service owner who can judge whether the access is still needed, while IAM and governance teams operate the workflow, evidence, and enforcement. That distinction matters because certification is really an assertion of business necessity. If the owner cannot explain why access exists, the review has failed, even if the platform recorded a completion status. The OWASP Non-Human Identity Top 10 reinforces the same risk pattern for machine identities: scale, overprivilege, and weak lifecycle ownership create predictable exposure. In practice, many security teams discover accountability gaps only after a review cycle has already been signed off with little real scrutiny.

How It Works in Practice

At enterprise scale, access certification should be designed around ownership, not tooling. IAM teams typically run the campaign, define the cadence, pre-populate entitlement data, and retain evidence. But the actual decision to keep, reduce, or revoke access should rest with the manager, application owner, or data owner who understands the business context. That is the person who can answer whether the access is still required for an active role, project, vendor relationship, or operational function.

A practical operating model usually includes:

• named owners for each application, dataset, and privileged role
• clear decision rights for approve, revoke, delegate, or escalate
• risk-based review tiers for standard, privileged, and dormant access
• attestation records that capture who decided, when, and on what basis
• automation that removes access when no decision is made by the deadline

This is where policy and process should complement each other. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls supports accountable access governance through least privilege, review, and authorization controls, while the certification workflow supplies the audit trail. For machine identities, the same ownership principle applies to service accounts and API credentials. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privileges and poor visibility magnify harm when no one truly owns the entitlement.

IAM can orchestrate and enforce, but it cannot independently judge business need. These controls tend to break down when reviewers are assigned by title alone, without real application knowledge, because they cannot reliably validate whether access still supports the workload.

Common Variations and Edge Cases

Tighter accountability often increases review overhead, requiring organisations to balance stronger assurance against slower campaign completion. That tradeoff becomes visible in environments with thousands of entitlements, shared platforms, or highly distributed ownership models. Current guidance suggests the accountable owner should remain close to the business risk, but there is no universal standard for every matrixed organisation structure.

In some cases, access spans multiple owners, such as a platform team, a data steward, and a product manager. In those situations, a single named approver still needs final decision authority, even if others contribute evidence. For third-party access, accountability should sit with the internal sponsor who requested or benefits from the access, not the vendor itself. For privileged or emergency access, certifiers should review both standing access and the exception process that allowed it.

One useful rule is simple: if the reviewer cannot remove the access without a second committee, the ownership model is too weak. The best practice is evolving toward explicit attestation ownership, automated escalation, and revocation when decisions are overdue. NHI Mgmt Group’s research on recurring NHI risk and exposure shows why this matters at scale, especially where overprivileged identities and stale entitlements persist across long review cycles. In mature programmes, accountability is documented before the campaign begins, not negotiated after a risky entitlement is discovered.

Related resources from NHI Mgmt Group

• Who is accountable when GitHub access decisions are approved, modified, or revoked during a certification cycle?
• What breaks when access reviews and segregation of duties are still handled manually at enterprise scale?
• Who is accountable when workflow access reviews and source-of-truth decisions are inconsistent?
• Who is accountable when physical access decisions do not match HR status or security policy?