Should organisations recertify NHIs separately from human accounts?

Why recertifying NHIs needs different evidence than human access reviews

Separate recertification is not about creating extra bureaucracy, it is about matching the review method to the type of subject being certified. A human reviewer can usually confirm job role and business need, but an NHI review has to prove current ownership, system dependency, runtime use, and whether the credential is still needed in production.

That is why recertification criteria for NHIs should favour machine-facing evidence such as last use, rotation state, environment scope, and the application or service relationship behind the credential. Human-style attestation alone is too weak when the access path is a secret, token, certificate, or service account that can stay valid long after the original purpose has drifted.

Separate treatment also helps teams avoid a common governance error: certifying a machine credential because a person “recognises” it, rather than because the workload still needs it. For NHIs, the review question is not “does someone still approve this?” but “does this identity still have an owned, observable, justified function?”

What should a separate NHI recertification process actually check?

An effective NHI recertification process should verify identity ownership, current business purpose, runtime usage, and the blast radius of the credential. It should also ask whether the identity is bound to a live application, whether the secret is still active in deployments or automation, and whether the access scope still matches the workload’s actual function.

Good review criteria usually include the credential’s age, rotation history, last successful authentication, dependencies in downstream systems, and whether the account is shared, inherited, or tied to a deprecated integration. If the team cannot trace those points quickly, the review is already too human-centric and is unlikely to catch stale or orphaned machine access.

NHIMG’s Service Account Security Guide is useful here because it frames service account governance around discovery, least privilege, rotation, and ownership, which are the practical inputs a recertification workflow needs.

For many organisations, the strongest operating model is to treat NHI recertification as a lifecycle control, not a calendar event. That means review triggers should include deployment changes, ownership changes, rotation failures, environment moves, and inactivity thresholds, not just an annual campaign.

How to keep recertification from rubber-stamping active machine credentials

The main failure mode is rubber-stamping an NHI because the reviewer knows the business service, while ignoring whether the underlying credential is still necessary, appropriately scoped, or still in use. Another common failure is reviewing the label on the account instead of the actual runtime evidence, which allows stale credentials to survive simply because they are embedded in scripts, pipelines, or external integrations.

Separate review logic should force a decision on each machine identity’s current purpose and owner, and it should make “unknown” a real outcome rather than a soft approval. Where the evidence is incomplete, the safer path is to suspend, rotate, or isolate the credential until the workload dependency is proven.

NHIMG’s Access Reviews and Certification Guide is directly relevant because it shows how to design reviews that remove access, include NHIs, and close the loop instead of turning certification into a formality.

Teams also need ownership discipline, because an NHI cannot be recertified intelligently if nobody is accountable for its business function. NHIMG’s NHI Ownership and Accountability Guide supports that operating model by making ownership assignment and orphan handling part of the control rather than an afterthought.

Risk and Threat Considerations

When organisations use the same recertification process for humans and NHIs, they increase the chance of keeping active machine credentials that no one can properly justify. That creates unnecessary standing access, larger blast radius, and a better foothold for attackers who target long-lived secrets, unused service accounts, or overprivileged automation.

Failure mechanism: Human reviewers often approve an NHI because the associated service or team still exists, even when the specific credential is stale, overprivileged, or no longer tied to a live workload. That leaves hidden access paths in place long after the original business case has expired.

Impact: Compromised or forgotten NHIs can enable lateral movement, secret reuse, and persistence, especially where the credential is embedded in automation or external integrations. In practice, the damage is usually discovered late, after the access path has already been reused or abused.

NHIMG’s Top 10 NHI Issues is a strong companion reference because it highlights the exact failure patterns that separate recertification is meant to catch, including orphaned identities, excessive permissions, and stale accounts.

Practitioner Guidance

What to prioritise: Use a distinct NHI review queue for service accounts, API keys, tokens, and certificates, and require runtime or dependency evidence before approving continuation. If the reviewer cannot point to a live owner and a live workload, the credential should not pass by default.

What to verify: Confirm last use, rotation state, owner assignment, and whether the credential is still present in production automation or integration paths. A valid-looking account name is not enough evidence if the actual authentication material is long-lived or invisible to the business owner.

Practitioner takeaway: Recertification works for NHIs only when the control shifts from “does a person still approve this?” to “can we prove this machine access is still needed, still owned, and still bounded?”

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities alongside human accounts?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between managing human accounts and non-human identities?