Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.
Expanded Definition
Access recertification is the periodic revalidation of permissions, roles, and account entitlements to confirm that access still has a business purpose. In NHI programs, it applies to service accounts, API keys, workload identities, and delegated automation that can accumulate privileges over time.
Definitions vary across vendors on whether recertification is a pure attestation exercise or part of broader identity governance, but the operational goal is consistent: reduce stale access before it becomes exploitable. That distinction matters because access review alone does not remove the root causes of privilege creep, over-permissioned accounts, or unused secrets. The OWASP Non-Human Identity Top 10 frames this as a governance control, not a one-time compliance task, while Ultimate Guide to NHIs places it inside the lifecycle of visibility, rotation, and offboarding.
The most common misapplication is treating recertification as a checkbox exercise for human-owned systems, which occurs when teams review entitlements after exceptions have already become permanent.
Examples and Use Cases
Implementing access recertification rigorously often introduces review fatigue and administrative overhead, requiring organisations to weigh stronger assurance against slower operations and more coordination across application owners.
- A quarterly review of cloud service accounts confirms whether automation jobs still need write access to production storage, and removes permissions that are no longer tied to active deployments.
- A secrets review validates whether API keys stored in CI/CD pipelines are still used, aligning with guidance in the Ultimate Guide to NHIs — Key Challenges and Risks and reducing silent credential sprawl.
- A breach response team re-certifies all third-party integrations after an incident to identify which vendor tokens remain valid, similar to the remediation concerns discussed in the Sisense breach.
- An identity governance program pairs recertification with role redesign so that managers do not merely approve existing access, but also remove inherited privileges that no longer match RBAC intent.
- A platform team reviews whether an AI agent still requires tool execution authority before a new release, because agentic access can persist beyond the model lifecycle and create hidden standing privilege.
These use cases are most effective when recertification is fed by asset inventory, ownership metadata, and usage telemetry, rather than by spreadsheets and ad hoc approvals. The 52 NHI Breaches Analysis shows why review workflows must connect to real incident patterns, not just policy language.
Why It Matters in NHI Security
Access recertification matters because NHI estates tend to grow faster than teams can manually govern them, especially when secrets are embedded in pipelines, apps, and third-party integrations. NHIs outnumber human identities by 25x to 50x in modern enterprises, which makes periodic review necessary but not sufficient; without lifecycle controls, stale access keeps reappearing between review cycles. The strongest programs treat recertification as a backstop for least privilege, not a substitute for it.
One relevant data point from the Ultimate Guide to NHIs is that only 20% of organisations have formal processes for offboarding and revoking API keys, which means many environments rely on review events to catch what should have been removed automatically. That is why recertification should sit alongside Zero Trust Architecture and Zero Standing Privilege principles, as reflected in the OWASP guidance and in OWASP Non-Human Identity Top 10.
Organisations typically encounter access recertification as an urgent requirement only after a key leak, service account misuse, or supplier compromise, at which point the process becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret sprawl and lifecycle governance failures that recertification helps uncover. |
| NIST Zero Trust (SP 800-207) | PA-3 | Zero Trust requires continuous verification of access assumptions, including non-human accounts. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management depends on periodic entitlement review and correction. |
Review NHI entitlements and secrets on a fixed cadence, then remove access that lacks current business justification.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
