Zero Trust is an identity strategy, not a single security tool

At a glance

What this is: This is Axiad’s critique of Zero Trust misconceptions, centred on the finding that identity must be treated as the perimeter across users, devices, workloads, and transactions, not reduced to authentication alone.

Why it matters: IAM, PAM, and NHI teams need to align Zero Trust programmes with enforcement and visibility across every identity type, or they risk protecting logins while leaving the rest of the trust chain exposed.

Context

Zero Trust is a security strategy built around continuous verification, not a single product or login step. In the identity context, the model fails when teams equate trust reduction with MFA or user authentication alone, because the attack surface extends to devices, workloads, applications, and the transactions they execute.

The governance gap is that many programmes still treat identity as a front-door control rather than an ongoing enforcement layer. That leaves post-authentication activity, machine access, and identity context outside the control boundary, which is exactly where modern attackers and operational failures create exposure.

Key questions

Q: What breaks when MFA is the same for every login in a zero trust model?

A: Static MFA breaks down when risk changes because it treats routine and suspicious sessions identically. That creates predictable prompts for users and predictable gaps for attackers. In zero trust, authentication should adapt when device posture, location, network reputation, or behaviour changes, otherwise the control remains fixed while the threat environment moves.

Q: Should organisations prioritise zero trust or NHI governance first?

A: Organisations should treat them as dependent priorities rather than competing projects. Zero trust fails quickly when NHIs are over-permissioned, undocumented, or impossible to revoke. NHI governance gives zero trust the inventory, ownership, and lifecycle controls it needs to work in cloud operations.

Q: How should teams decide whether passwordless access is enough for Zero Trust?

A: Passwordless access is not enough if it only changes how an identity signs in. Teams should treat it as one layer of assurance and ask whether authorization, device trust, logging, and post-authentication enforcement still operate across the full identity path.

Q: What is the difference between passwordless authentication and zero trust?

A: Passwordless authentication is an access method, while zero trust is an architecture that requires continuous verification and least privilege. Passwordless can strengthen zero trust by improving the quality of identity proof at login, but it does not replace device trust, authorization, monitoring, or lifecycle controls.

Technical breakdown

Why Zero Trust fails when it stops at authentication

Authentication proves that an identity presented a credential, but Zero Trust requires continuous evaluation of whether that identity should keep access in the current context. When teams stop at MFA or login approval, they leave session activity, device posture, workload behaviour, and transaction risk outside the decision loop. That creates a false sense of containment because the initial check is strong while the downstream enforcement is weak. In practice, Zero Trust is a policy system, not just an access event, and the policy has to follow the request path rather than end at sign-in.

Practical implication: extend policy enforcement beyond sign-in to cover session, device, workload, and transaction decisions.

Identity as the perimeter for users, devices, and workloads

The article frames identity as the new perimeter because traditional network boundaries no longer define trust. That means the relevant control problem is not simply who logged in, but which user, device, workload, or application is interacting with which resource and under what conditions. For NHI and workload access, that shifts emphasis toward certificate-backed identity, scoped access, and strong lifecycle controls. For human identity, it means authentication must be paired with contextual authorization and logging. The architectural point is that Zero Trust only works when every identity class is visible and governable.

Practical implication: map each identity type to a distinct verification and authorisation control path.

PKI and passwordless access as control enablers, not the strategy itself

The article positions PKI certificates and passwordless authentication as mechanisms that can support Zero Trust, especially where device and application verification matter. But those mechanisms are only enablers if they sit inside a broader governance model that also handles access scope, device trust, and transaction assurance. Password removal alone does not create Zero Trust, because the control objective is not simply stronger authentication. It is continuous, contextual trust evaluation across the lifecycle of access. Without that broader model, certificate use can become just another credential layer rather than a governance improvement.

Practical implication: treat PKI and passwordless as building blocks inside a broader identity control architecture, not as the end state.

NHI Mgmt Group analysis

Zero Trust is an identity governance model before it is a technology stack. The article is correct to push back on the idea that Zero Trust can be reduced to a single tool or authentication method. Once identity becomes the perimeter, governance has to address who or what is trusted, for how long, and under which conditions across users, devices, workloads, and transactions. Practitioners should treat Zero Trust as a policy and lifecycle problem, not a feature checklist.

Authentication-only thinking creates a trust gap after the login event. MFA can verify a credential and still leave the session, device state, and downstream action ungoverned. That is why Zero Trust programmes break when they stop at the front door, because the highest-risk decisions often happen after access is granted. IAM and PAM teams should read this as a warning that post-authentication control is not optional.

Identity context is the control plane Zero Trust actually depends on. The article’s strongest point is that verification must extend to the full identity surface, including machines and digital transactions. That aligns Zero Trust with NHI governance and workload identity management, where the subject is not a user at all but a certificate, token, or service account. The implication is that security architecture must move from single-step verification to continuous identity context enforcement.

PKI, passwordless access, and device trust are enablers, not substitutes for governance. Technical controls can reduce reliance on passwords and improve assurance, but they do not define the programme by themselves. A Zero Trust strategy still needs policy boundaries, access scope, and evidence that the controls apply consistently across all identity classes. Practitioners should judge the architecture by whether access decisions remain contextual after initial authentication.

Zero Trust programmes need a named control boundary for non-human identities. When the article says identity is the new perimeter, that perimeter must include service accounts, applications, and workloads, not only employees. That is where many programmes remain incomplete. The practical conclusion is that NHI lifecycle, privilege scope, and certificate governance belong inside the Zero Trust operating model, not beside it.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Standards

What this signals

Zero Trust collapses into a login-control problem when identity is treated as a one-time event. Teams that stop at MFA may improve credential assurance but still miss the control boundary that matters most: what happens after access is granted. The practical shift is toward contextual authorization and continuous evidence across the identity session.

Identity blast radius becomes the more useful metric than authentication strength. A strong sign-in flow does not tell you whether users, workloads, and service identities can move too far once inside the environment. Programme owners should measure how much access remains active, observable, and revocable after the initial trust decision.

For practitioners

• Define identity as the trust boundary Document which identity classes are in scope for Zero Trust, including users, devices, workloads, applications, and service identities. Make the boundary explicit so teams do not stop at human login controls.
• Extend enforcement beyond sign-in Require policy checks after authentication for session activity, device context, and transaction sensitivity. If enforcement ends at login, the programme is only proving identity once.
• Map non-human identities to the same programme Inventory service accounts, certificates, tokens, and application identities that access production resources. Give them lifecycle ownership, scope limits, and revocation paths equal to human identities.
• Use PKI as a control layer, not a slogan Where passwordless or certificate-based access is used, tie it to device trust, access scope, and continuous verification. Avoid treating credential format changes as a Zero Trust programme by themselves.
• Audit post-authentication visibility Check whether logs, analytics, and response processes can show what identities did after access was granted. Zero Trust fails if the organisation cannot see activity beyond the login event.

Key takeaways

• Zero Trust fails when organisations treat it as a sign-in control instead of an identity governance model that spans users, devices, workloads, and transactions.
• The article’s core warning is that authentication alone cannot govern post-authentication behaviour, which is where real exposure accumulates.
• Practitioners should align Zero Trust with continuous verification, lifecycle ownership for NHIs, and visibility into access after login.

Key terms

• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Identity Perimeter: The identity perimeter is the access boundary defined by who or what is requesting entry, not by where the request comes from. In zero trust, it is the point where authentication, authorization, and risk context decide whether a caller can proceed.
• Post-Authentication Enforcement: Post-authentication enforcement means access is checked again after login, at the point where a request reaches a resource or action. It matters in zero trust because identity proof alone does not prevent misuse when permissions, secrets, or sessions remain overly broad.
• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.