How can organisations tell whether Zero Trust is real or just branding?

Look for consistent enforcement across human and non-human identities. If the platform can time-bound access, enforce least privilege, and revoke credentials without manual cleanup across databases, servers, and cloud resources, it is operationalising Zero Trust. If those controls stop at the user login, the model is incomplete.

Why This Matters for Security Teams

zero trust is easy to claim and harder to prove. For security teams, the real test is whether access decisions are enforced at the identity, workload, and resource layers, not just at login. That means time-bound credentials, least privilege, and revocation that actually works across servers, databases, APIs, and cloud control planes. NIST’s NIST SP 800-207 Zero Trust Architecture frames this as continuous verification, while NHI Management Group’s Ultimate Guide to NHIs shows why non-human identities often expose the gap first.

The most revealing signal is whether the organisation can govern human and non-human identities with the same discipline. If service accounts, API keys, certificates, and automation tokens remain long-lived or manually cleaned up, the “Zero Trust” label usually covers only the user perimeter. In practice, many security teams discover the gap only after a leaked secret or stale service account has already been used for lateral movement.

How It Works in Practice

Real Zero Trust is observable in how access is issued, evaluated, and revoked. The architecture should assume no implicit trust based on network location or account type. Instead, policy is evaluated at request time using identity, device or workload context, resource sensitivity, and task purpose. For non-human identities, that usually means short-lived credentials, workload identity, and strong attestation rather than shared static secrets.

A practical implementation often includes:

• Workload identities such as SPIFFE/SPIRE or OIDC-based identity for services and automation, so the system knows what the workload is, not just what secret it presents. See the Guide to SPIFFE and SPIRE.
• Just-in-time access with tight TTLs for secrets, tokens, and certificates, especially for CI/CD jobs, agents, and ephemeral compute.
• Policy-as-code controls that evaluate at runtime, using context rather than fixed role assumptions.
• Automated offboarding and revocation so access disappears when a workload ends, not after a manual cleanup ticket.

That approach aligns with the operational guidance in the Ultimate Guide to NHIs and its standards section, which emphasises lifecycle control, rotation, and visibility. It also reflects the core Zero Trust principle in NIST SP 800-207 Zero Trust Architecture: trust should be continually re-established, not presumed. NHI Mgmt Group research notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which is why branding often outruns execution.

These controls tend to break down when legacy systems require long-lived shared credentials because revocation and runtime policy evaluation become inconsistent across the stack.

Common Variations and Edge Cases

Tighter Zero Trust enforcement often increases operational overhead, so organisations have to balance stronger containment against integration complexity. That tradeoff is real in legacy estates, hybrid cloud environments, and machine-to-machine integrations where not every platform supports short-lived identity or per-request policy checks.

Current guidance suggests treating the following as warning signs rather than exceptions:

• If user MFA is strong but service accounts still use static passwords, the model is incomplete.
• If token rotation exists but revocation depends on manual intervention, Zero Trust is only partial.
• If cloud workloads are governed but on-prem databases are excluded, enforcement is inconsistent.
• If vendors describe “Zero Trust” without explaining identity lifecycle, secrets rotation, and policy decision points, the claim is usually branding rather than architecture.

There is no universal standard for every implementation detail yet, but the pattern is clear: real Zero Trust reduces standing access and proves it across every identity class. Organisations that can only demonstrate controls at the login screen have not closed the loop for NHI governance or workload access, and that is where compromise usually begins.

Related resources from NHI Mgmt Group

• Should organisations treat MCP server collaboration as a Zero Trust problem?
• Should organisations prioritise Zero Trust for machine identities before broader IAM changes?
• Should organisations align PAM and zero trust policy design?
• How should organisations implement Zero Trust without breaking existing access workflows?