How do you audit and certify non-human identity access for service accounts and machine identities?

What auditors should verify first in non-human identity access

Start by anchoring each service account or machine identity to a real business owner and a specific purpose. That gives you the baseline for certification: if you cannot identify who owns it, why it exists, and which systems it should reach, the access review is already incomplete. For machine identity governance context, the Service Account Security Guide is a useful companion reference.

From there, compare the granted permissions to the minimum set needed for the current workload. The practical test is not whether the identity ever needed those entitlements in the past, but whether it still needs them now. That is especially important where access has drifted over time through new integrations, inherited group membership, or environment changes. The broader Top 10 NHI Issues page is useful for the recurring failure patterns behind these reviews.

Certification should also check whether the identity is using an approved authentication method and whether its secrets are being rotated on a defensible schedule. If the review cannot confirm how the identity authenticates, who can use it, and whether the secret material has been handled safely, then the access decision is not trustworthy. For workload identity patterns and stronger authentication design, see the SPIFFE workload identity specification.

How to separate valid access from stale entitlement

Not every permission should be certified just because it is present. Long-lived non-human identities often accumulate stale access from decommissioned services, copied configurations, emergency workarounds, and forgotten test paths. A good review distinguishes active entitlements from historical residue and removes anything that no longer supports a documented system function.

Shared, privileged, or dormant identities deserve special scrutiny because they can hide blast radius. If several systems depend on one account, or if an account has not been used recently but still has broad access, the safest assumption is that the review must go deeper before certification. That is where ownership evidence, service dependency mapping, and usage logs become more valuable than a simple yes-or-no checkbox.

Reviewing the review itself matters too. If the same account keeps passing certification without a material change in business purpose, that usually means the process is measuring process completion rather than access necessity. A strong audit should produce a defensible decision trail: keep, reduce, rotate, or remove.

What good certification evidence looks like

Good evidence is specific enough to explain why the access exists today. Auditors should expect to see an owner, a purpose statement, the systems or APIs the identity is allowed to reach, recent usage activity, and proof that the authentication material is still current. If that evidence is missing or contradictory, the safest outcome is usually to downgrade or suspend the entitlement until it is reconciled.

Usage logs are especially useful because they show whether the identity is actually exercising the access being certified. A dormant account with no recent use may still be needed, but it should be treated as an exception that requires explicit justification rather than automatic renewal. The same logic applies to machine identities that authenticate successfully but never perform a legitimate workload function.

For practitioners operating in cloud and API-heavy environments, RFC 6749: The OAuth 2.0 Authorization Framework remains a useful reference when reviewing machine-to-machine access patterns and token-based delegation.

Risk and Threat Considerations

Non-human identity reviews fail when they treat permissions as static inventory instead of live access paths. A stale service account or machine identity can become a persistence point, a lateral-movement foothold, or a privileged route into production if its secret remains valid and its entitlements were never reduced. That is why overprivilege, dormant access, and unrecycled secrets are not administrative issues, they are security exposure.

Failure mechanism: The identity remains active after its real business need has ended, or it retains permissions that exceed the workload’s current function. Attackers who obtain the secret, token, or certificate can reuse that standing access without needing to compromise a human account first.

Impact: Exposed or overprivileged non-human identities can enable unauthorized data access, service manipulation, environment traversal, and difficult-to-detect persistence. In practice, the most dangerous condition is not simply that the identity exists, but that it still works.

Practitioner Guidance

What to verify: Confirm that every non-human identity has a named owner, a current purpose, and a current permissions boundary. If any one of those three is missing, the certification should be treated as incomplete, even if the identity appears technically healthy.

Decision rule: If the identity is privileged, shared, or rarely used, require a more frequent review cycle and stronger evidence of business need. If it cannot prove recent legitimate use, certify only the minimum access needed for continuity and queue the rest for removal.

Common mistake: Approving access because the account is “still in use” without checking whether it needs the same scope it had last quarter. Certification should validate necessity, not preserve historical convenience.

Practitioner takeaway: The real test is whether the identity can still justify its current access with clear ownership, live usage, and bounded privilege, if not, reduce or remove it rather than certifying inherited entitlement.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities alongside human accounts?