Should organisations review human and non-human access with the same zero trust discipline?

When should zero trust reviews treat people and machines the same way?

Zero trust is strongest when the review question is about current authority, not actor type. A human account and a non-human credential can both become overexposed, stale, or mis-scoped, so organisations should review both through the same discipline while adapting the evidence, ownership, and remediation path to how the access is actually used.

Why the control objective stays the same

The control objective is to confirm that access is still justified, bounded, and observable. If a person can no longer explain why they need access, or a service can no longer justify a token, key, or role, the risk is the same: unnecessary standing access creates avoidable blast radius. Zero trust asks for continuous verification of need, context, and least privilege, not a different standard for humans and machines.

That matters because entitlement drift rarely shows up as a single obvious failure. It accumulates through role changes, project handoffs, integrations, emergency grants, and forgotten machine paths. For both populations, the review should look for the same end state: access that is still tied to an approved business function, still restricted to the minimum necessary scope, and still traceable to an accountable owner.

How to adapt the review without lowering the bar

Human and non-human access should be reviewed with the same discipline, but not the same evidence. Human access usually depends on manager attestation, job function, and activity context. Non-human access usually depends on workload purpose, integration boundary, secret or certificate lifetime, and whether the credential is still needed by the application or automation. The review model changes the inputs, not the standard.

That is why a single access review process often fails when it treats every principal as if it were a user. A service account with a long-lived API key should be reviewed for ownership, rotation, reuse, and scope. A person with standing admin rights should be reviewed for duty separation, task necessity, and whether the role still reflects current responsibilities. The practical test is whether the access would still be approved if it were requested today.

For workload identity and service-to-service access, the same review discipline becomes even more important because SPIFFE and SPIRE style identity models reduce ambiguity by binding access to workloads, trust bundles, and attestation. When access is tied to a clear workload identity, review can focus on whether the relationship still exists and whether the scope still matches the workload’s function.

What good review evidence looks like

Good reviews are not just a list of names or account IDs. They show who owns the access, what business process depends on it, how long it has existed, whether it is actively used, and what happens if it is removed. For human access, that may mean role, manager, and recent activity. For non-human access, that may mean application owner, secret age, last rotation, dependency map, and whether the credential is shared across environments.

Good practice also means recognising when access review is the wrong control by itself. If the issue is a shared secret embedded in code, a quarterly attestation is too slow. If the issue is a production role that never expires, the review must be paired with expiry, rotation, or just-in-time elevation. The review should surface problems, but the remediation should remove standing access where possible.

That is why access review design needs to include both humans and non-humans when the control objective is entitlement reduction, not workforce-only governance. A review that excludes machine principals leaves a major source of privilege drift untouched.

Risk and Threat Considerations

When organisations review humans more rigorously than machines, the gap becomes a standing access problem. Attackers and internal misuse alike benefit from stale service accounts, long-lived keys, and forgotten integrations because those paths often receive less scrutiny than user access and may persist after ownership changes.

Failure mechanism: Access review excludes or underweights non-human principals, so dormant entitlements, shared secrets, and excess privilege survive normal certification cycles and create durable paths for misuse or compromise.

Impact: The organisation keeps business-critical access it no longer needs, which increases blast radius, weakens accountability, and makes privilege escalation or lateral movement easier after one credential is exposed.

Practitioner Guidance

What to prioritise: Put humans and non-humans into the same review program, then tailor the attestations to the actor type. Use one policy standard for when access should be removed, and separate evidence fields for manager approval, application ownership, secret age, and dependency confirmation.

What to verify: Before trusting a certification result, verify that every reviewed principal has a current owner, a current business purpose, and a removal path. If the reviewer cannot explain why the access exists today, treat that as a failed review, not a deferred one.

Practitioner takeaway: Zero trust review discipline should be uniform at the control objective level and specific at the evidence level, because the real question is whether access is still justified, not whether the principal happens to be human.

Related resources from NHI Mgmt Group

• Should organisations apply the same access review process to human and non-human identities?
• 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 organisations apply Zero Trust to non-human identities?