Who is accountable when access certification becomes rubber-stamped?

The identity governance owner, application owners, and control stakeholders all share responsibility, because weak scoping turns review into theatre. When campaigns are too broad, reviewers lose signal, evidence quality drops, and the control stops supporting audit or risk decisions.

Why This Matters for Security Teams

When access certification becomes rubber-stamped, the problem is usually not reviewer negligence alone. It is a control design failure: too many entitlements, too much context loss, and too little accountability for the evidence being collected. That is especially dangerous for NHIs, where service accounts, API keys, and automation tokens can outlive projects and accumulate broad access. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes weak certification a direct risk amplifier rather than a paperwork issue.

Security teams often assume the reviewer is the accountable party, but accountability actually sits with the identity governance owner, the application owner, and the control owner together. If the scope is wrong, reviewers cannot make a defensible decision, and audit evidence becomes performative. The OWASP Non-Human Identity Top 10 reinforces that NHI sprawl and privilege creep are structural problems, not one-off exceptions. In practice, many security teams encounter failed certifications only after an audit challenge or incident review, rather than through intentional control testing.

How It Works in Practice

Real accountability starts before the campaign launches. The governance owner defines the certification standard, the application owner validates which identities and entitlements are in scope, and the control stakeholder confirms that the review produces evidence strong enough for audit and risk decisions. For NHIs, that usually means separating human access from machine access, grouping identities by application or business function, and attaching enough metadata to show what the identity does, who owns it, what it can reach, and when it was last used.

Strong programs also require reviewers to see context, not just a list of permissions. Current guidance suggests including business criticality, last activity, secret age, privilege level, and whether the identity is tied to a deployment pipeline, integration, or workload. That matters because certification is not meaningful if a reviewer cannot tell whether a token is active, orphaned, over-privileged, or used by an automated process. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how review gaps and ownership ambiguity repeatedly show up in compromise paths.

• Define one owner for scope, one owner for remediation, and one owner for evidence quality.
• Use attestation questions that force a decision: still needed, needs reduction, or remove.
• Feed in usage data so dormant accounts do not receive the same treatment as critical production identities.
• Escalate exceptions when the reviewer cannot determine intent or business purpose.

Controls like this align with the operational reality described in the OWASP Non-Human Identity Top 10, where poor lifecycle visibility and excessive privilege undermine review quality. These controls tend to break down when the inventory is incomplete and ownership metadata is missing because reviewers are forced to approve unknown identities by default.

Common Variations and Edge Cases

Tighter certification often increases administrative overhead, requiring organisations to balance review quality against campaign fatigue. That tradeoff is real, especially in environments with thousands of NHIs, ephemeral workloads, and frequent CI/CD changes. Best practice is evolving here, and there is no universal standard for how much context is enough. The pragmatic goal is not exhaustive review, but review that can actually support a risk decision.

Edge cases usually appear when identities are shared across teams, when one workload depends on many downstream APIs, or when access is provisioned and revoked through automation. In those situations, individual attestation by name can be misleading, because the real accountable party is the team that owns the workload and its change process. This is where policy, inventory, and ownership records must stay aligned with the certification workflow. The Ultimate Guide to NHIs — Key Challenges and Risks is useful for framing why broad reviews and weak inventory discipline create blind spots.

For high-churn environments, current guidance suggests shorter review intervals, narrower scopes, and automated removal for identities that cannot be substantiated. The goal is to stop treating certifications as a compliance ritual and start using them as an operational control. If a reviewer cannot explain why access still exists, the control should fail closed rather than be signed off.

Related resources from NHI Mgmt Group

• Who is accountable when identity certification campaigns miss risky access?
• Who should be accountable for patient data access in connected healthcare hubs?
• Who is accountable when workload access decisions fail under conditional policies?
• Who is accountable when a shared device still contains the prior user's access?