Access remains active even after the business need changes, so expired service accounts and unused keys continue to represent live privilege. Without recertification, teams cannot prove ownership, cannot justify access, and cannot confidently retire identities without risking outages.
Why This Matters for Security Teams
When non-human identities are excluded from recertification, access reviews become incomplete by design. That breaks the evidence chain for ownership, necessity, and revocation, which means privileged service accounts, API keys, and automation tokens can outlive the business process they support. The result is not just stale access. It is uncontrolled privilege that can be reused, copied, or inherited by forgotten systems.
This is especially dangerous because NHIs are often the real operators of cloud, CI/CD, and data pipelines. NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and the Ultimate Guide to NHIs — What are Non-Human Identities also notes that only 5.7% of organisations have full visibility into their service accounts. Under the NIST Cybersecurity Framework 2.0, identity governance is not just a policy exercise; it is a control that supports access assurance, traceability, and timely revocation.
In practice, many security teams discover broken recertification only after a dormant credential is abused, rather than through intentional governance.
How It Works in Practice
Recertification is meant to confirm that access is still needed, still owned, and still aligned to a current business function. For NHIs, that means each identity should be tied to a workload, system, or automation path that has a named owner and a defined renewal cadence. If the review process only covers human users, then machine access becomes a permanent exception even when the workload changes, the vendor is replaced, or the pipeline is decommissioned.
Good practice is to connect recertification to lifecycle events: application onboarding, rotation, offboarding, and change management. Teams should verify where the NHI is used, whether the permissions still match the task, and whether the secret can be replaced with a shorter-lived mechanism. In many environments, this is where Sisense breach style exposures become instructive: leaked machine credentials often remain usable because the organisation never forced a review at the point of change.
- Require an explicit owner for every NHI, including service accounts and API keys.
- Recertify permissions against actual workload usage, not just inherited RBAC roles.
- Use JIT credentials where possible so access expires with the task.
- Prefer ephemeral secrets and workload identity over long-lived static credentials.
- Log approvals, denials, and revocations so audit evidence is complete.
Current guidance suggests pairing recertification with Zero Trust principles and policy enforcement so that access is validated at runtime, not assumed from past approval. That aligns with the NIST Cybersecurity Framework 2.0 emphasis on protecting assets through continuous governance, and it reduces the chance that an old token survives a change window. These controls tend to break down when secrets are embedded in CI/CD systems or code repositories, because ownership is unclear and revocation can disrupt production unexpectedly.
Common Variations and Edge Cases
Tighter recertification often increases operational overhead, requiring organisations to balance stronger assurance against deployment speed and service continuity. That tradeoff is real for high-frequency pipelines, vendor-managed integrations, and always-on production services where manual approvals can become a bottleneck.
There is no universal standard for this yet, but best practice is evolving toward risk-based review. Low-risk, short-lived automation may only need lightweight verification, while privileged NHIs that touch customer data, secrets stores, or admin APIs should face stricter review and faster expiry. Where agentic or autonomous software is involved, the problem gets harder because behaviour is goal-driven and less predictable. In that setting, recertification alone is not enough; teams also need runtime authorisation, intent-based controls, and workload identity so the system proves what it is and what it is trying to do before each action.
The JetBrains GitHub plugin token exposure is a reminder that machine secrets can be widely distributed, while Schneider Electric credentials breach shows how quickly exposed credentials can turn into broader access problems. In other words, recertification fails hardest where the environment is highly automated, the secret sprawl is large, and revocation depends on manual discovery instead of system-level inventory.
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 CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers NHI credential rotation and lifecycle control, central to recertification gaps. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access management and least privilege for identities, including machine accounts. |
| NIST AI RMF | Autonomous workloads need governance beyond static approval because behaviour changes at runtime. |
Map NHI recertification to access reviews and revoke entitlements that no longer match business need.
