Table of Contents
- The Perimeter Was Always a Fiction
- What Zero Trust Actually Asserts
- Authentication Is Not Authorisation
- Service Accounts Are the Weak Point
- Session Duration Is a Security Control
- Device Trust Adds Real Signal
- A Realistic Adoption Sequence
- Common Pitfalls
- Conclusion
- Frequently Asked Questions
Key takeaway: Zero trust means no request is trusted because of where it came from. Every access decision is evaluated on identity, device state, and context at request time — which makes it primarily an identity engineering programme rather than a network purchase.
The Perimeter Was Always a Fiction
The traditional model divided the world into inside and outside. A firewall separated them, and being inside conferred trust.
This model failed for reasons that have accumulated over two decades. Work happens outside the perimeter. Applications run in cloud environments the firewall does not front. Third parties need access. Mobile devices move between networks continuously. And the model’s core assumption — that inside is safe — collapses the moment any single device inside is compromised, which is the normal outcome of a successful phishing email.
The specific failure mode is that perimeter models grant broad access on the strength of one authentication event at the boundary. An attacker who gets inside inherits that breadth. This is why lateral movement is so productive in traditional networks and why intrusions escalate from one workstation to domain-wide so reliably.
Zero trust removes location as a trust input. A request from the office network and a request from a hotel receive identical scrutiny, because network position tells you nothing useful about whether a request is legitimate.
What Zero Trust Actually Asserts
Stripped of marketing, the model rests on a few principles:
Verify explicitly, per request. Every access decision evaluates current identity, device state, and context — not a trust assumption established at session start.
Least privilege, continuously. Access is scoped narrowly and expires. Standing broad access is the thing being eliminated.
Assume breach. Design as though an attacker is already present. This is what drives segmentation, short sessions, and comprehensive logging.
Authorise on multiple signals. Identity, device compliance, location, behaviour patterns, and resource sensitivity all inform the decision rather than identity alone.
Two clarifications that resolve most confusion. Zero trust is not a product — no appliance implements it, though several products contribute components. And it does not mean trusting nothing, which would prevent all function; it means trust is derived from verification rather than from position.
The reason vendors market it as a network product is that identity architecture is harder to sell than a box. The actual work sits in identity, and organisations that begin with a network purchase typically discover this several months in.
Authentication Is Not Authorisation
The distinction that determines whether an implementation works:
Authentication establishes who is making a request. Solved reasonably well by modern identity providers, multi-factor authentication, and single sign-on.
Authorisation determines what that identity may do with a specific resource, right now. This is where most implementations remain weak.
The common failure is treating successful authentication as sufficient. A user authenticates strongly and then receives access to everything their role permits, evaluated once, for the session’s duration. That is perimeter thinking with better login.
Genuine zero trust authorisation evaluates each request against current conditions:
Request: user@example.com reads customer_records/44821
Evaluate:
identity verified? yes, MFA 4 minutes ago
device compliant? yes, managed, encrypted, patched
role permits this resource? yes, support tier 2
business justification? ticket #8842 references this customer
behaviour typical? yes, consistent with role and hours
resource sensitivity? contains PII, elevated logging required
Decision: allow, log with justification, session scoped 15 minutesThe business justification check is the one most organisations omit and the one that most reduces insider risk. A support agent with role-based access to all customer records can browse them freely. The same agent required to reference an active ticket can only access records they have a reason to see — and every access carries a recorded reason.
Service Accounts Are the Weak Point
Human identity has improved substantially. Machine identity has not, and it now represents the larger exposure in most environments.
The problems are consistent:
Static long-lived credentials. API keys and passwords that never expire, stored in configuration, environment variables, and CI systems.
Excessive permissions. Service accounts frequently receive broad access because determining the minimum was tedious and nobody revisited it.
No multi-factor authentication possible. A service account cannot present a second factor in the conventional sense, so the credential is the entirety of the security.
Unclear ownership. Accounts created for a project years ago, still active, with no identifiable owner and no documented purpose. Nobody will disable them because nobody knows what breaks.
Absent monitoring. Human anomalies get noticed. A service account authenticating from a new location at an unusual hour frequently does not.
Machine identities typically outnumber human ones substantially, which makes this the larger surface by count as well as by weakness.
What improves it: workload identity federation, where the platform attests to a workload’s identity and issues short-lived credentials with no static secret to leak. Mutual TLS with short-lived certificates for service-to-service authentication. Mandatory ownership metadata so accounts have an accountable human. Scheduled review that disables unused accounts rather than accumulating them. And anomaly detection applied to machine authentication with the same seriousness as human authentication.
Workload identity federation is the highest-value item there, because it eliminates the static credential entirely rather than managing it better.
Session Duration Is a Security Control
Session lifetime receives less attention than it deserves, and it directly determines how long a compromise remains useful.
A stolen session token is valid until it expires. An eight-hour session means eight hours of access from a single theft. A fifteen-minute session with continuous re-evaluation means fifteen minutes.
The tension is genuine: short sessions improve security and degrade usability, and users who authenticate constantly develop workarounds that are worse than the original risk.
Approaches that resolve it reasonably:
Risk-based duration. Long sessions for low-sensitivity resources on compliant devices from typical locations. Short sessions for administrative access, sensitive data, or unusual context.
Continuous evaluation rather than fixed expiry. Re-check conditions during the session and revoke when they change — device falls out of compliance, location shifts impossibly, behaviour becomes anomalous. This is more effective than any fixed duration.
Step-up authentication. A normal session for routine work, with re-authentication required for sensitive operations specifically. This concentrates friction where it buys something.
Immediate revocation capability. The ability to terminate all sessions for an identity within seconds. This matters enormously during incident response and is frequently not tested until needed.
Long-lived refresh tokens deserve specific attention as a common weakness. A short access token backed by a refresh token valid for months provides the security properties of a months-long session. The refresh token is the actual session duration.
Device Trust Adds Real Signal
Identity alone is insufficient, because a legitimate credential on a compromised device produces legitimate-looking malicious requests.
Device signals worth incorporating: whether the device is managed and enrolled, disk encryption status, patch level, endpoint protection presence and health, whether it has been jailbroken or rooted, and certificate-based device identity.
Practical use is graduated rather than binary. Compliant managed devices receive full access. Non-compliant managed devices receive limited access with remediation guidance. Unmanaged personal devices receive access to a restricted set of resources, typically through a browser with no local data storage. Unknown devices receive nothing.
The main implementation obstacle is contractor and third-party access, where you cannot mandate device management. The usual answer is browser-isolated access to a narrow set of applications, which is worse ergonomically and keeps unmanaged devices away from sensitive resources.
A Realistic Adoption Sequence
Ordered so each stage delivers value independently:
Consolidate identity. One authoritative identity provider, all applications federated to it. Multiple identity sources make consistent policy impossible, and this is the prerequisite for everything else.
Phishing-resistant multi-factor authentication everywhere. Highest immediate return. Eliminates credential theft and relay as attack paths.
Inventory applications and data by sensitivity. You cannot write differentiated policy without knowing what you are protecting.
Replace VPN with per-application access. Application-level access rather than network-level. This is where lateral movement gets constrained, and it is the largest architectural change.
Add device compliance to access decisions. Requires device management to exist first.
Eliminate standing privileged access. Just-in-time elevation with approval and time limits. Administrative accounts are the highest-value target.
Fix machine identity. Workload identity federation, short-lived credentials, ownership metadata, review process.
Add context and behaviour signals. Location, timing, and pattern anomalies. This layer is refinement rather than foundation.
Most organisations attempt this in roughly the reverse order, beginning with a network product because it is procurable. Identity consolidation is unglamorous and it is the dependency for everything that follows.
Common Pitfalls
Buying a product and declaring completion. Zero trust is an architecture. Products contribute components.
Authentication without authorisation improvement. Strong login followed by broad standing access is perimeter thinking.
Ignoring machine identity. It is the larger surface and the weaker one.
Uniform session duration. Sensitivity should determine lifetime. One value for everything is either too short to tolerate or too long to be safe.
Long-lived refresh tokens behind short access tokens. The refresh token is the real session length.
No emergency revocation. Discovered during an incident, which is the worst time.
Skipping identity consolidation. Multiple identity sources make consistent policy impossible.
Conclusion
Zero trust replaces location-based trust with per-request verification. That is an identity and authorisation architecture, and network products are a component rather than an implementation.
The sequence that works starts with consolidating identity into one provider, then phishing-resistant multi-factor authentication everywhere, then replacing network-level access with per-application access. Add device compliance once device management exists. Eliminate standing administrative privilege in favour of time-limited elevation. And address machine identity seriously, because service accounts outnumber humans and are protected only by a static secret.
Throughout, the distinction that matters is authentication versus authorisation. Knowing who is asking is largely solved. Deciding what they may do with this specific resource, right now, with a recorded reason, is where the security actually comes from.
Frequently Asked Questions
Does zero trust mean removing the VPN? Usually yes, eventually. VPNs grant network-level access, which is the model being replaced. Per-application access with per-request authorisation is the destination, and the transition is typically gradual.
Where should an organisation start? Identity consolidation and phishing-resistant multi-factor authentication. Everything else depends on having one authoritative identity source, and MFA delivers the largest immediate risk reduction.
How is legacy software handled? Applications that cannot support modern authentication sit behind a proxy that enforces it, on an isolated segment, with compensating monitoring. Some genuinely cannot be brought into the model and must be contained instead.
Is this feasible for small organisations? The principles are, and small organisations frequently have an advantage — fewer legacy systems, simpler identity. A single identity provider with strong MFA and per-application access is achievable without a large programme.
What about contractors on unmanaged devices? Browser-isolated access to a narrow application set, with no local data storage. Less convenient and it keeps unmanaged devices away from sensitive resources.
How does this affect user experience? Frequently improves it. Single sign-on with device-based trust means fewer password prompts than a VPN plus separate application logins. Friction concentrates at sensitive operations rather than being distributed everywhere.
Are compliance frameworks satisfied by zero trust? It supports most access control requirements well and frameworks specify controls rather than architectures. Mapping your implementation to the required controls is a separate documentation exercise.
