Access certification should include anyone or anything that can accumulate privilege over time, including employees, third-party partners, developers, and connected accounts. If an identity can retain access after the original business need changes, it belongs in the certification model. Scope should reflect access risk, not only organisational chart boundaries.
Why This Matters for Security Teams
access certification fails when it is limited to job titles and annual reviews, because privilege accumulates in places that organisational charts do not reveal. That includes service accounts, contractors, dormant integrations, and shared accounts that quietly outlive the original business need. NHI Management Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which means certification scope that excludes machine identities misses most of the practical risk.
The issue is not only volume. Long-lived access tends to drift, especially where secrets are embedded in code, CI/CD systems, or partner integrations. OWASP’s OWASP Non-Human Identity Top 10 treats this as a governance problem, not just a credential problem, because stale access is often discoverable only after misuse or breach. In practice, many security teams encounter excessive access after an incident has already exposed how many identities were never in scope for review.
How It Works in Practice
The right certification model starts with risk, not org structure. Security teams should include any identity that can retain, inherit, or accumulate privilege over time, then classify those identities by business criticality, data sensitivity, and path to privilege escalation. That usually means employees, but it also includes third-party users, developers, service accounts, API keys, CI/CD bots, cloud roles, and delegated application identities. The question is not whether the identity is human or machine. The question is whether it can still act after the original justification has expired.
A practical programme usually combines inventory, ownership, and review cadence:
- Inventory all identities with access to production, sensitive data, or admin functions.
- Assign a business owner and a technical owner for each identity type.
- Review standing access on a frequency aligned to risk, with shorter cycles for privileged and external identities.
- Require attestation that access is still needed, then revoke or downgrade anything without a current business case.
- Track connected accounts and delegated access paths, not only direct user grants.
This matters because NHI misuse often persists after a human account would have been noticed. The 52 NHI Breaches Analysis and NHI Mgmt Group’s Key Challenges and Risks section both reinforce the same operational lesson: if an identity can still authenticate, it can still be abused. Access certification should therefore include service accounts, third-party integrations, and automation identities wherever they can persist beyond the intended task. These controls tend to break down when ownership is unclear and machine accounts are hidden inside application teams because reviewers cannot reliably judge business need.
Common Variations and Edge Cases
Tighter certification scope often increases review burden, so organisations must balance completeness against reviewer fatigue and operational delay. The best practice is evolving, but current guidance suggests using different review depths for different identity classes rather than forcing every account through the same human-centric workflow.
High-risk edge cases deserve special treatment. Shared accounts, break-glass accounts, CI/CD service principals, partner-managed integrations, and nested group memberships can all create access that survives normal employee offboarding. Connected accounts are especially easy to miss because their privilege may come from another system rather than a direct grant. In those cases, certification should verify both direct access and upstream trust relationships. A periodic review that only asks whether a named user still needs access will miss delegated tokens, unused API keys, and inherited cloud permissions. For that reason, teams should tie certification to offboarding, secret rotation, and ownership change events, not only calendar-driven campaigns. NHI Mgmt Group’s Sisense breach is a reminder that externally exposed and service-linked access paths can become the real entry point when review scope is too narrow.
There is no universal standard for this yet, but mature programmes certify every identity that can outlive its original purpose, then apply more frequent scrutiny to identities with standing privilege, external exposure, or automation authority.
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-01 | Covers inventory and ownership of non-human identities that need certification. |
| NIST CSF 2.0 | PR.AC-1 | Access permissions must be managed across human and non-human accounts. |
| NIST AI RMF | Governance should address autonomous or automated identities with changing access needs. |
Set policy and accountability for automated identities before they accumulate standing privilege.
Related resources from NHI Mgmt Group
- Why do identity programmes need access history if they already have current entitlement data?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- When do NHI access reviews create more value than a one-time cleanup?
