How should security teams run access certification for privileged accounts?

Start with a complete inventory of privileged entitlements, then review each account against current business need, task scope, and ownership. Require an explicit decision to renew, reduce, or revoke access, and make revocation automatic when approval is absent. The review only works when the entitlement data is current and the remediation path is immediate.

Why This Matters for Security Teams

access certification for privileged accounts is not a paperwork exercise. It is one of the few control points that can catch stale admin rights, orphaned service accounts, and delegated access that never got cleaned up after a project ended. The practical risk is simple: if privileged access is reviewed without accurate entitlement data, the team can approve the wrong state and leave high-impact access untouched.

This is especially important for non-human identities, where privileges often outlive the business need that created them. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into service accounts, which means many certification programs start from incomplete inventory. Current guidance from the OWASP Non-Human Identity Top 10 and NIST-aligned identity governance practice both point to the same issue: access review fails when ownership, purpose, and expiry are unclear.

In practice, many security teams discover excessive privileged access only after a credential is reused, a service is decommissioned, or a responder finds that no one can explain why an account still exists.

How It Works in Practice

Effective certification starts with a verified inventory of privileged entitlements, not a list pulled from a single directory. Security teams need to reconcile human admin accounts, break-glass access, application service accounts, API keys, and delegated OAuth grants so the review covers the full privilege surface. That inventory should include ownership, system purpose, last-used signals, approval history, and expiry or rotation data. Without those fields, reviewers can only guess.

For privileged human access, reviewers should assess whether the role still matches current job function, whether the access is still required for a defined task, and whether a narrower role or just-in-time access would work better. For NHI-related access, the standard is similar but the mechanics are stricter. The question is not only “who owns it?” but also “what workload uses it, what it can reach, and whether it can be replaced with short-lived credentials or workload identity.” The State of Non-Human Identity Security found that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which is why certification should be tied to rotation and revocation workflows, not just approval records.

• Require reviewers to choose one outcome only: renew, reduce, or revoke.
• Use maker-checker approval for high-risk privileged entitlements.
• Make revocation automatic when an approver does not respond by the deadline.
• Route removals to systems that can execute immediately, including IAM, PAM, vault, and CI/CD controls.
• Retest after remediation so the same privilege does not reappear in the next cycle.

Where possible, combine certification with policy-as-code and runtime telemetry so the team can see whether the entitlement was actually used. That prevents rubber-stamping and helps surface access that exists only because no one has challenged it recently. These controls tend to break down when entitlements are spread across SaaS, cloud, and build systems because ownership is fragmented and revocation paths are inconsistent.

Common Variations and Edge Cases

Tighter access certification often increases operational overhead, so organisations have to balance review depth against business continuity. That tradeoff becomes sharper for break-glass accounts, shared admin accounts, and production automation where immediate revocation could disrupt recovery or deployment workflows.

Best practice is evolving for these edge cases. For break-glass access, current guidance suggests pre-approval of emergency use conditions, strong logging, and automatic post-use certification rather than standard periodic approval alone. For shared privileged accounts, many teams are moving toward named accountability plus PAM-mediated checkout, because anonymous shared use defeats meaningful review. For workloads and agents, certification should focus less on a person’s job title and more on the workload’s current function, secret lifetime, and approved scope of tool access.

NHIMG research shows only 20% of organisations have formal processes for offboarding and revoking API keys, so any certification program that depends on manual follow-through is likely to leave exposure behind. Use the 52 NHI Breaches Analysis alongside the Sisense breach as reminders that access reviews only reduce risk when the revoke path is real, immediate, and enforced across all privilege types.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams run user access reviews for FedRAMP compliance?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities alongside human accounts?