Identity recertification is the periodic revalidation of whether access is still needed and still appropriate. For public-sector programmes, it is more than a compliance task, because it is one of the few ways to reduce privilege creep across both human and non-human identities.
Expanded Definition
Identity recertification is the scheduled revalidation of who or what still needs access, why that access remains justified, and whether the current privilege level still matches the task. In NHI governance, this applies to service accounts, API keys, workload identities, and human administrators who may have accrued excess entitlements over time. It is closely related to access review and entitlement certification, but the NHI context adds stronger pressure around ownership, runtime evidence, and secrets hygiene because the identity may never be “seen” by a person.
Definitions vary across vendors, but the governance goal is consistent: force an accountable decision, on a recurring basis, that either reaffirms access, narrows it, or removes it. That makes it a practical control within a broader program aligned to NIST Cybersecurity Framework 2.0 and the lifecycle emphasis described in Ultimate Guide to NHIs. The most common misapplication is treating recertification as a calendar-only checkbox, which occurs when approvers rubber-stamp stale access without verifying the identity’s current role, system dependency, or secret usage.
Examples and Use Cases
Implementing identity recertification rigorously often introduces operational friction, because approvers must gather evidence, understand dependencies, and sometimes coordinate with application owners before access can be renewed or revoked.
- A quarterly review of cloud service accounts confirms whether each account still supports a live workload, then removes any orphaned account that no longer has an owner.
- An API key used by a public-sector integration is recertified only after the system owner verifies the key is still needed, is scoped to the minimum endpoint set, and is stored in a secrets manager.
- A privileged automation identity is reviewed after a platform migration to ensure its permissions reflect the new architecture, not the legacy environment it once supported.
- An identity governance team uses lessons from 52 NHI Breaches Analysis to prioritise recertification of exposed service accounts that have internet-facing dependencies.
- Security architects map recertification workflows to NIST Cybersecurity Framework 2.0 so entitlement reviews feed directly into access reduction and governance reporting.
In practice, recertification works best when it is tied to ownership data, asset criticality, and usage telemetry rather than static org charts alone.
Why It Matters in NHI Security
Identity recertification matters because access that was once justified often becomes dangerous after a system changes, a team reorganises, or a secret is reused in a new workflow. NHIMG research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Those figures show why periodic review is not administrative overhead but an attack-surface reduction mechanism.
Without recertification, privilege creep accumulates quietly across pipelines, cloud accounts, and delegated automations. That creates hidden paths for lateral movement, persistence, and untracked secret reuse. The control also exposes ownership gaps: if nobody can justify the access, nobody can defend it. When paired with lifecycle controls described in Ultimate Guide to NHIs — What are Non-Human Identities, recertification becomes a practical way to remove inherited access before it turns into standing privilege. Organisations typically encounter the need for identity recertification only after a breach investigation or audit finding reveals that long-ignored access was still active, at which point the term 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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Access review and entitlement hygiene directly support periodic NHI recertification. |
| NIST CSF 2.0 | PR.AA-04 | Identity proofing and access authorization depend on ongoing validation of need-to-know. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires continual access decisions, not one-time approval. |
| NIST SP 800-63 | AAL2 | Identity assurance concepts inform how strongly access should be revalidated. |
| CSA MAESTRO | Agentic workflows need recurring authorization checks for tool access and delegated actions. |
Match recertification rigor to the sensitivity of the identity and require stronger validation for privileged access.
