Zero Trust in the Real World

August 10, 2026

Information Security

Security Frameworks That Actually Get Adopted

In 2017, three years into Google’s efforts to eliminate the VPN, the engineering team realized that many internal applications were built on the assumption that the network itself was a form of identity. Requests from within the building were trusted without question, which needed re-engineering apps and convincing owners that new authentication wouldn’t break systems. BeyondCorp became the standard Zero Trust deployment, but the process took years due to reasons beyond cryptography.

That is the part of the Zero Trust story most vendors leave out of the pitch deck. The principle, never trust by default, verify continuously, is not difficult to state and was not difficult in 2010 when Forrester analyst John Kindervag gave it a name. What is difficult is the part that comes after the principle is accepted: rebuilding the decision-making structure of an organisation so that access stops being a network property and becomes a continuously evaluated judgment. Most programs never get there. They buy the tools the principle implies- multifactor authentication, privileged access management, microsegmentation- and assume the organisational rebuild will follow on its own. It doesn’t. The tools sit on top of an operating model that hasn’t changed, and the operating model quietly wins.

What Is Zero Trust?

Zero Trust is a decision discipline, not an architecture: no user, device, or network is inherently trustworthy. Every access request should be evaluated based on identity, device, and behaviour, not location. NIST formalised this in Special Publication 800-207, emphasising organisational access decisions rather than specific products.

Why the Vendor Version of Zero Trust Misleads

Following early 2020s ransomware and supply-chain incidents, “Zero Trust” appeared in many security products: identity platforms, network access points, endpoint suites, cloud gateways. Each covers part of NIST’s architecture. No single product guarantees the outcome; organizations using multiple “Zero Trust” tools without a decision model often get dashboards but no clear answers on access decisions.

Machine identity, such as service accounts, API credentials, and CI/CD pipelines, often outnumbers human users and accumulates permissions over time, like junk drawers filled with batteries—granted for convenience and left unchecked. Securing human logins but leaving service accounts with perpetual privileges creates a false sense of security, secured at the front door but open at the back.

The Adoption Problem Is Behavioural, Not Cultural

Security teams have a habit of describing user resistance as a culture failure, something to be fixed with training and posters. The research on compliance behaviour says otherwise, fairly consistently. People deviate from controls in rough proportion to the friction the control imposes relative to a benefit they can observe. A finance director re-authenticating four separate times on the day the books close is not making a judgment about the importance of security. She is making a judgment about getting her job done, and the control lost.

The specific conditions that produce this kind of failure are not mysterious, even if security architecture rarely accounts for them in advance. A uniform authentication requirement treats a routine, low-risk login exactly like a genuinely suspicious one, which means most users experience friction calibrated to the worst case rather than to their actual situation. Legacy applications, often the systems with the longest internal tenure and the broadest access, frequently cannot support modern authentication at all, and the exception created to work around them tends to become permanent the day it’s written. Access requests routed through a manager who wants the employee productive, a system owner who’s accountable for the resource, and a security team accountable for the control default toward approval far more often than denial, because approval is the path that avoids an argument today. None of this indicates a weak security culture. It indicates a control designed for an organisation that doesn’t quite exist.

Where to Actually Start

The instinct to scope a Zero Trust program across the entire network, in the name of thoroughness, is the instinct that kills it. A program with no visible outcome for eighteen months loses its executive sponsor long before it loses its relevance, and by the time someone asks what the investment bought, the honest answer is a slide deck.

The more durable starting point is the business workflow, not the infrastructure diagram. Map processes like order-to-cash, financial close, clinical records, and product development. Ask who needs access, why, from what device and location, for how long, and what happens if access is delayed by an hour instead of granted instantly. This question prompts honest discussions about friction costs before controls are built, not after complaints escalate.

This usually points toward privileged and administrative accounts as the sensible first domain, and not because it’s the easy option. It’s small enough in population to manage without organisation-wide disruption and consequential enough that the SolarWinds compromise of 2020 remains the cleanest illustration available: a single trusted administrative credential, once obtained, gave attackers persistent reach across thousands of otherwise reasonably well-defended environments. Securing a few hundred privileged accounts with just-in-time access, session recording, and the elimination of standing credentials produces a risk reduction that’s both real and legible to a board that doesn’t care about your architecture diagram.

Stronger Security Is Not the Same as More Friction

There’s a quiet assumption running through most security design that stops being true the moment you examine it: that more friction, applied evenly, equals more protection. It doesn’t. A managed device on the corporate network, accessing a low-sensitivity application during business hours, deserves something close to invisible verification. The same user accessing a financial system from an unrecognised device in an unfamiliar country at three in the morning deserves a genuinely different response: step-up authentication, restricted permissions, a flagged session. A control that treats both situations identically is not more secure for treating them identically. It’s just exhausting in the same uniform way regardless of what’s at stake.

Building this well requires reliable behavioural baselines, which most organisations don’t have on day one, and an honest answer for what happens when a device fails a health check, because a hard block with no remediation path becomes the next standing exception. The key principle to remember, even when dealing with the finance director on deadline day, is to verify consistently and make targeted interruptions.

The Governance Problem Nobody Wants to Own

If identity has become the new perimeter, the part of that sentence everyone skips is that maintaining a perimeter is unglamorous, continuous, thankless administrative work. Roles change. Projects end. People transfer departments, and nobody removes their old permissions because removing access requires deliberate effort that no specific person is accountable for, while accumulating it requires none. Organisations running their first serious entitlement review almost always find the same thing: permissions that match no current job, accounts belonging to people who left the company months ago, privileges nobody can explain. This isn’t a discovery about that organisation’s discipline. It’s the default outcome of any access model where permanent grants are the norm and removal is the exception.

The fix is less about better software and more about reversing which side of that equation requires effort. Time-bound access that expires unless someone actively renews it makes accumulation the thing requiring deliberate action, instead of removal. Clear ownership at the role level, rather than diffuse accountability spread across HR, IT, and whichever business unit happens to ask, means somebody is responsible for knowing what a function should be able to touch.

What Exceptions Are Actually For

Here is a single observation worth sitting with rather than burying in a list: an exception that’s been formally logged, with a named owner, a defined compensating control, and an expiration date, is safer than the same access granted informally to avoid a delay. The informal version carries identical risk and zero accountability. The formal version at least admits the risk exists.

The more valuable discipline, though, is treating exceptions as a pattern rather than a queue of individual approvals. When the same exception keeps showing up across different teams, that’s not evidence of weak compliance. It’s evidence that a control conflicts with a genuine, widespread operational need the original design never anticipated, and the right response is to redesign the control, not to keep stamping approvals on the same request indefinitely.

The Framework the Organisation Can Actually Sustain

The programs that hold up over years, rather than collapsing under their own administrative weight after eighteen months, are measured by outcomes that have nothing to do with how many products got deployed. How long it takes to revoke access after someone leaves. The age and volume of standing exceptions. How often users abandon an access request partway through, presumably because they found an easier route around it. These numbers describe whether the organisation is making better access decisions this quarter than it made last quarter, which is a far more honest question than whether the architecture has reached some declared state of completion.

A surviving framework must balance three aspects most programs optimise separately: stronger controls, reliable operations, and manageable administrative burden. Favour the first alone, and you get something architecturally elegant that nobody uses. Favour the second alone and access becomes generous to the point of meaninglessness. No framework resolves this tension permanently. There is only the discipline of holding all three at once, indefinitely.

Real-world Zero Trust is not architectural perfection. It is the unglamorous, continuous removal of trust the organisation never should have extended in the first place, at a pace the organisation can keep up with.

The following sections support discoverability and quick reference. They don’t count toward the article’s word total.

In Brief

Zero Trust involves ongoing access decisions based on identity, device, and behaviour, not network location. Its importance lies in aligning security architecture with real workflows, preventing budget loss. Successful organisations focus on adoption as a design challenge, rather than just technology.

Key Takeaways

• Recurring exception requests show a control conflicts with legitimate workflows and need redesign, not re-approval.
• Uniform authentication wastes user effort on low-risk transactions but provides little extra security for genuinely risky ones that need friction.
• Identity governance breaks down less from weak technology than from the absence of a named owner for each access decision, which is a management failure dressed up as a technical one.
• A program scoped to one business-critical workflow earns executive credibility faster than an enterprise-wide rollout that can’t show a result for eighteen months.
• The age and volume of standing exceptions is a more honest measure of program health than the number of security tools deployed.

Zero Trust Adoption Checklist

• Map access by business workflow first: order processing, financial close, clinical or customer systems, rather than by network segment.
• Govern non-human identities using the same lifecycle discipline as employees.
• Replace standing administrative access with just-in-time, session-recorded privileged access for a pilot group before expanding.
• Set new access grants to expire by default, requiring active renewal rather than deliberate removal.
• Track exception age and volume by team monthly and treat repeated requests for the same exception as a redesign trigger, not a recurring approval.
• Measure access-removal time after departure as a standing operational metric, not an annual audit finding.
• Pilot risk-adaptive authentication on a high-value app before organisation-wide rollout.

FAQ

What is Zero Trust, in plain terms? A rule for making access decisions: never assume trust based on network location, and verify identity, device condition, and context continuously rather than once at login. The rule is simple. Rebuilding the workflows to ensure the rule holds is the hard part.

Why do technically sound Zero Trust frameworks still fail to get adopted? Because architectural soundness and operational fit are different problems. A control can be perfectly correct on paper and still get routed around in practice, which means the organisation’s real security posture is weaker than the diagram suggests.

Where should a Zero Trust program start? With a small number of business-critical workflows and privileged accounts, not the whole network at once. Privileged access management produces fast, credible, board-legible risk reduction and builds the case for the next phase.

What’s the most common mistake organisations make? Treating exceptions as a discipline problem to be enforced rather than design feedback to be studied. A control that generates the same exception across multiple teams is telling you something true about its own design flaw.

How is risk-adaptive access different from standard MFA? Standard MFA treats every login equally, but risk-adaptive access adjusts responses based on context, device health, location, data sensitivity, and behaviour, so friction is applied only where genuinely needed.