Who is accountable when access is certified without understanding?

Accountability remains shared, but the strongest failure is usually in the governance design, not the manager alone. IAM and IGA teams are responsible for making entitlements understandable, owners visible, and risk obvious. Managers can only certify what they can interpret, so unreadable reviews are a programme design problem first.

Why This Matters for Security Teams

Access certification only works when the reviewer can understand what is being approved. In practice, unreadable entitlement names, missing ownership, and oversized role bundles turn certification into a rubber stamp. That is not just an audit problem. It creates a false sense of control while dormant access remains available long after business need has changed.

For NHI and privileged access environments, the risk is sharper because many entitlements are machine-created, app-specific, or inherited through nested groups and shared service accounts. The result is that managers are asked to approve access they cannot reasonably interpret. NHI Management Group data shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why certification workflows often fail to surface risk before it becomes an incident, as discussed in the Ultimate Guide to NHIs.

The accountability question therefore starts with governance design. Security teams, IAM teams, and IGA owners have to make access intelligible before they can expect meaningful sign-off. The OWASP Non-Human Identity Top 10 reinforces the same point: if identity state is opaque, approval quality collapses. In practice, many organisations discover this only after a certifier has approved access they could not decode, rather than through intentional access review design.

How It Works in Practice

Effective certification begins upstream of the review itself. Entitlements need to be grouped by business function, mapped to a visible owner, and described in plain language so a reviewer can tell whether access is still justified. For NHIs, that usually means separating human approvals from workload approvals, because service accounts, API keys, and automation tokens have different lifecycles and different risk signals.

Current guidance suggests three practical controls:

• Use business-readable labels for applications, roles, and groups instead of technical identifiers alone.
• Attach an accountable owner to every entitlement and require that owner to validate the review scope.
• Show last-used, privilege scope, and dependency information so the reviewer can see whether access is active or stale.

Where possible, certification should be paired with telemetry from secrets managers, PAM, and workload identity systems. That makes it easier to answer not only who owns the access, but whether the access is still being used, whether it is excessive, and whether it should be replaced with shorter-lived NHI controls. This is especially important because certification alone does not remove technical debt. It only validates a snapshot, and that snapshot can be misleading if the underlying catalog is poor.

Frameworks such as OWASP Non-Human Identity Top 10 and NIST guidance on access governance both point toward the same operational requirement: make review decisions evidence-based, not title-based. If the system cannot explain what an entitlement does, the reviewer is being asked to certify blind. These controls tend to break down in environments with heavy role nesting, shared admin accounts, and undocumented application entitlements because the review data no longer reflects how access is actually exercised.

Common Variations and Edge Cases

Tighter certification controls often increase operational overhead, so organisations have to balance review depth against review fatigue. That tradeoff matters because overly broad reviews are just as dangerous as overly frequent ones: both can train managers to approve without reading.

There is no universal standard for this yet, but best practice is evolving toward risk-based certification. High-risk entitlements should be reviewed more often, with clearer evidence and stronger approvers, while low-risk access can be sampled or auto-attested if the business case is stable. For NHIs, this becomes even more important because workload permissions may be ephemeral, inherited, or tied to deployment pipelines rather than to a named person.

Edge cases include mergers and acquisitions, legacy ERP platforms, and shared infrastructure accounts. In those environments, entitlement meaning is often buried in technical convention, so the certifier needs a curated context layer, not a raw access list. That is why governance teams should treat unreadable certification reports as a design defect, not a user training issue. The broader NHI risk picture in the Ultimate Guide to NHIs shows why stale or excessive access can persist when reviews are not understandable, and the 52 NHI Breaches Analysis illustrates how often weak visibility and poor ownership compound the problem.

Related resources from NHI Mgmt Group

• Who should be accountable for revoking shared credential access?
• Who is accountable when configuration drift causes an access failure or breach?
• Who should be accountable for access to a self-hosted credential store?
• Who should be accountable for privileged access when vendors and admins both use it?