Zero trust misconceptions: why identity is the real perimeter

At a glance

What this is: This is an editorial on common Zero Trust misconceptions, with the central finding that identity, not the network, is the modern perimeter.

Why it matters: It matters because IAM, PAM, and NHI programmes all fail if Zero Trust is reduced to login controls instead of continuous verification across users, machines, workloads, and transactions.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Axiad's analysis of zero trust misconceptions and identity as the perimeter

Context

Zero Trust is often reduced to a product category, but the article is really about a governance mistake: treating identity verification as the whole model. The primary keyword here is zero trust, and the practical issue is that many teams still stop at authentication instead of extending verification to devices, workloads, transactions, and post-authentication behaviour.

That gap matters because modern environments no longer have a stable perimeter. Once credentials are stolen or replayed, controls that only check initial access can no longer distinguish a legitimate subject from an impersonator, which is why identity lifecycle, device trust, and workload verification all sit inside the Zero Trust problem space.

Key questions

Q: What breaks when zero trust is treated as just MFA?

A: Zero Trust collapses into a front-door control when MFA is treated as the whole model. Attackers can still use valid credentials, hijacked sessions, or privileged actions after login if the architecture does not verify devices, workloads, and transactions continuously. The result is an authentication-only programme that still leaves post-authentication risk untouched.

Q: Why do non-human identities complicate zero trust programmes?

A: NHIs complicate Zero Trust because they behave like first-class subjects but are often governed like background infrastructure. Service accounts, API keys, and workload identities can carry standing privilege, operate at machine speed, and bypass the human-focused assumptions many access models were built on. Zero Trust must explicitly include them or it will miss the real trust boundary.

Q: How do security teams know whether zero trust is actually working?

A: Teams should look for continuous verification across identity types, not just successful authentication events. Useful signals include reduced standing privilege, explicit device and workload checks, short-lived access decisions, and visible policy enforcement after login. If a session stays trusted indefinitely once it starts, the programme is still perimeter-based in practice.

Q: Who is accountable when zero trust is reduced to a single tool?

A: Accountability sits with the identity, security, and architecture owners who define the programme, not with the tool alone. Zero Trust is an architectural choice that spans identity, network, endpoint, and application controls, so governance failures happen when organisations assign ownership to one product team instead of to the end-to-end access model.

Technical breakdown

Why zero trust is not a product

Zero Trust is a security strategy that assumes no implicit trust based on network location, device origin, or prior session state. The article reflects the common confusion between strategy and implementation: some vendors describe one control such as MFA, ZTNA, or PAM as if it were the full model. In practice, Zero Trust is an architecture that combines identity verification, device posture, transaction inspection, and policy enforcement. If teams collapse the concept into a single control, they leave gaps where attackers can use valid credentials or trusted sessions to move laterally.

Practical implication: map Zero Trust to an architecture and control set, not to a single tool or authentication method.

Identity as the perimeter for users, machines, and workloads

When the network perimeter weakens, identity becomes the boundary that decides what can be trusted. That includes human users, service accounts, devices, workloads, and applications, all of which need context-aware verification rather than one-time login checks. This is where IAM and NHI governance intersect: if machine identities are unmanaged or over-privileged, Zero Trust breaks even when human authentication is strong. The article’s emphasis on PKI, passwordless access, and verified transactions points to a broader requirement, which is to validate every subject that touches the environment, not just interactive users.

Practical implication: extend Zero Trust policy to non-human identities, not just employee authentication flows.

Post-authentication control is where most misconceptions fail

The article’s example of MFA is useful because it shows the limit of front-door controls. A user can authenticate legitimately and still perform harmful actions if session context, packet inspection, entitlement scope, and transaction risk are not evaluated after login. That is the core Zero Trust error: assuming identity proof at sign-in is enough to trust later behaviour. Modern identity security needs continuous evaluation of access, device integrity, and action context, especially where stolen credentials or compromised accounts can imitate normal activity.

Practical implication: add post-authentication inspection and behavioural policy enforcement to every sensitive access path.

NHI Mgmt Group analysis

Zero Trust fails when teams confuse authentication with governance. The article shows how easily the concept is narrowed into a login problem, even though the model was meant to challenge implicit trust everywhere. That confusion is not just semantic, because it allows organisations to declare victory after MFA while leaving machines, workloads, and sessions outside the trust boundary. The implication is that Zero Trust programmes must be judged by scope, not slogans.

Identity is the perimeter, but only if it covers all identity types. Human identity, machine identity, and workload identity are now part of the same control plane, and attackers will route through whichever subject is least governed. The article’s emphasis on credential theft and post-authentication trust shows why a user-only Zero Trust model is structurally incomplete. Practitioners need to treat NHIs as first-class subjects in Zero Trust design.

PKI and passwordless controls matter because they reduce reliance on brittle shared trust states. The article points toward certificates, digital signatures, and authenticated transactions as a way to verify more than a password can prove. That aligns with identity programmes that want stronger device and workload assurance, but the operational lesson is broader: every trust decision should be explicit, contextual, and short-lived. Teams that still depend on static trust states are not operating Zero Trust, only rebranding perimeter control.

Post-authentication verification gap: The specific failure mode here is assuming a successful login equals a trusted session. That assumption was built for a world where identity proof at the front door was enough, but it fails when credentials are replayed, sessions are hijacked, or activity changes after authentication. The implication is that teams must rethink how they define trust continuity across the full session lifecycle.

Zero Trust maturity is measured by breadth, not by single-control adoption. Organisations can deploy MFA, VPN replacement, or a ZTNA product and still fail the architecture if the policy does not cover devices, workloads, and transactions. This is why Zero Trust remains hard to operationalise: the target state is a governance model, not a feature checklist. Practitioners should assess whether access decisions are continuously re-evaluated across the subjects that actually matter to the business.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how weak the visibility baseline remains for machine identity governance.
• For a broader control model, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, privilege, and rotation gaps that undermine zero trust.

What this signals

Zero Trust programmes will keep underperforming until identity scope includes NHIs and workload identities. The practical signal is not whether a team has bought a ZTNA product, but whether it can describe how service accounts, certificates, and application identities are verified and re-evaluated in the same model as people. That is where identity governance becomes architecture, not policy language.

Identity review cycles need to shift from sign-in events to session behaviour. If the programme still assumes a trusted session after the first authentication step, it will miss credential replay, token abuse, and post-login privilege misuse. The next maturity step is to align access policy, device assurance, and transaction risk into one continuous decision loop.

Standing privilege remains the most visible structural weakness in Zero Trust adoption. In our research, 97% of NHIs carry excessive privileges, which means many Zero Trust efforts are trying to protect an over-permissioned control plane. The governance takeaway is simple: a Zero Trust label does not change privilege reality, so entitlement reduction has to happen in parallel with architecture work.

For practitioners

• Redefine the trust boundary around identity, not location Document which identities are in scope for Zero Trust, including users, service accounts, workloads, devices, and APIs. Then map where each identity type is verified, where it is authorised, and where its actions are continuously re-evaluated.
• Separate authentication from ongoing authorisation Treat successful login as only the first control point. Add session, device, and transaction checks for privileged activity so that access remains conditional after authentication completes.
• Bring non-human identities into the Zero Trust programme Inventory NHIs, classify their privilege, and test whether they are governed by the same trust assumptions as employees. If machine identities are unmanaged, the architecture has a hidden exception path.
• Use certificates and strong identity proof for non-password trust Where feasible, reduce dependence on reusable passwords and shared secrets by using certificates or other cryptographic identity proofs for devices, applications, and transactions.

Key takeaways

• Zero Trust fails when organisations reduce it to authentication, because the model was always meant to govern trust continuity across identity, device, workload, and transaction.
• NHI visibility and privilege management are central to Zero Trust maturity, since machine identities often carry the hidden access paths that bypass human-focused controls.
• Teams should measure Zero Trust by continuous verification and entitlement reduction, not by the presence of one branded product or login method.

Key terms

• Zero Trust Architecture: A security model that assumes no implicit trust based on location, network, or previous access. It requires explicit verification and policy enforcement for every access decision, including human users, machines, workloads, and transactions. In practice, it is an operating model that spans identity, device, and application control.
• Non-Human Identity: A non-human identity is a machine- or workload-based subject such as a service account, API key, token, certificate, or AI agent identity. These identities authenticate and act without a person in the loop, so their privileges, lifecycle, and trust boundaries need governance that is as disciplined as human IAM.
• Post-authentication control: Post-authentication control is the set of checks that continue after a user or workload has successfully logged in. It includes session monitoring, device posture, entitlement scope, and transaction inspection. This is where many Zero Trust programmes fail, because they stop at identity proof instead of governing ongoing behaviour.
• Passwordless authentication: Passwordless authentication uses cryptographic or device-based proof instead of reusable shared secrets. It reduces dependence on passwords, which are easy to steal, reuse, and phish, but it only strengthens Zero Trust when paired with continuous access decisions and strong identity lifecycle controls.

Deepen your knowledge

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

This post draws on content published by Axiad: The Misconceptions of Zero Trust. Read the original.