NHIs often lack a manager, are shared across systems, and are created outside HR-driven processes. That means ownership has to be resolved through application, team, or system accountability. Without that step, certification becomes paperwork rather than governance.
Why This Matters for Security Teams
Access certification assumes there is a clear human owner, a stable job function, and a predictable entitlement pattern. NHIs break all three assumptions. Service accounts, API keys, pipeline identities, and workload credentials are often shared across applications, created outside HR workflows, and used by systems that do not map cleanly to a manager review. That makes recertification much more than a checkbox exercise.
Practitioners usually find that the hardest part is not deciding whether an entitlement is excessive, but deciding who can credibly attest to it. NHI Mgmt Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which helps explain why manual review models scale poorly. When those identities also sit inside third-party integrations or CI/CD pipelines, the review turns into an investigation of ownership, usage, and blast radius rather than a simple access approval. The same governance challenge shows up in breach analysis such as the 52 NHI Breaches Analysis, where identity sprawl and weak accountability repeatedly appear as root causes.
Current guidance from OWASP Non-Human Identity Top 10 treats this as an identity lifecycle problem, not just an access review problem. In practice, many security teams encounter NHI over-privilege only after an outage, leak, or incident response has already exposed how little ownership actually existed.
How It Works in Practice
Effective certification for NHIs starts by replacing “who owns this account?” with “which application, workload, or service is accountable for this identity?” That means the review packet needs context: where the identity is used, what it can reach, whether it is embedded in code or a vault, how often it is rotated, and whether there is an operational fallback if access is removed. The review is then tied to the workload, not the person who happens to know the password.
In mature environments, teams combine inventory, telemetry, and policy to make this workable. The Ultimate Guide to NHIs — Key Challenges and Risks shows why: only 5.7% of organisations have full visibility into their service accounts, so certification without discovery is partial at best. A practical workflow usually includes:
- mapping each NHI to an application owner, system owner, or platform team;
- validating whether the identity is still active and whether its permissions match actual usage;
- checking for shared credentials, hard-coded secrets, or stale keys in pipelines and configuration;
- requiring attestation on business need, not just on existence;
- feeding revocation and rotation decisions into PAM, secrets management, and deployment automation.
For implementation detail, the OWASP Non-Human Identity Top 10 is useful because it frames recurring failure modes such as over-privilege, weak rotation, and poor lifecycle control. It also helps teams distinguish between a credential that is still operationally required and one that is simply lingering because nobody owns the cleanup. The challenge becomes even clearer when incidents like the JetBrains GitHub plugin token exposure show how quickly one leaked NHI secret can become a wider trust failure across the software supply chain. These controls tend to break down when identities are embedded in distributed CI/CD systems because the same secret is reused across environments and no single team can see the full dependency chain.
Common Variations and Edge Cases
Tighter certification often increases operational overhead, requiring organisations to balance governance quality against release velocity and support burden. That tradeoff is real, especially in environments with ephemeral workloads, multi-cloud deployments, or heavy automation.
Some teams try to solve NHI certification by applying human-style RBAC reviews, but that is usually too coarse. A role may look appropriate on paper while the underlying service account has accumulated permissions through tool chaining, inherited trust, or long-lived secrets. Best practice is evolving toward evidence-based review: actual use, current scope, and revocation readiness. There is no universal standard for this yet, which is why many programmes blend access certification with continuous controls such as rotation enforcement, secret scanning, and runtime policy checks.
Another edge case is third-party and supplier-owned NHIs. The Sisense breach illustrates how access decisions become harder when the organisation receiving the certification request does not fully control the identity lifecycle. In those cases, current guidance suggests requiring contract-backed ownership, expiry dates, and revocation evidence rather than relying on annual attestation alone. The Ultimate Guide to NHIs also reinforces that NHI review should be paired with offboarding and rotation, not treated as a standalone governance event.
Where the model breaks down most often is in machine-generated or rapidly provisioned identities, because the access path changes faster than the review cadence can follow. That is when certification must shift from periodic approval to continuous assurance.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI review needs lifecycle control and timely revocation of stale identities. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions review aligns with least-privilege NHI certification. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of identity and access context. |
Shift NHI certification from annual approval to ongoing trust validation and scope checks.
