A business is told it needs zero trust. What follows is a quotation for a platform, a migration project, and a claim that the network must be rebuilt. The business, reasonably, decides it cannot afford zero trust this year and files it under future initiatives.
That sequence is the main obstacle to zero trust adoption, and it is a marketing artefact rather than a technical requirement. Zero trust is an architectural approach. It describes where trust decisions are made, not which product makes them, and most of the movement toward it is configuration of systems a business already owns.
The business case is straightforward once the framing is corrected. Under the perimeter model, an attacker who reaches the inside of the network inherits the trust the network extends to everything inside it. Under a resource model, reaching the network grants nothing, because every request is evaluated on its own merits. The difference is what an incident costs.
What NIST actually says
It is worth starting from the definition rather than from a vendor's description, because the two differ substantially.
NIST published SP 800-207, Zero Trust Architecture, in August 2020. It defines zero trust as an evolving set of cybersecurity paradigms that move defences from static, network-based perimeters to focus on users, assets, and resources. It describes a zero trust architecture as one focused on protecting resources — assets, services, workflows, network accounts — rather than network segments.
Two things follow from that wording and neither involves buying anything. The unit of protection is the resource, not the network. And network location stops being an input to the trust decision, which means being inside the office confers no more authority than being in a coffee shop.
Microsoft's formulation of the same idea gives three guiding principles that are easier to hold in mind during a design conversation: verify explicitly, use least privilege, and assume breach. The third is the one that changes behaviour, because it converts every design question from how do we keep them out into what happens when they are already in.
The components, and what they map to in a real business
The NIST model describes a logical architecture. The names sound abstract until they are mapped onto things a business already has, at which point most of them turn out to be present in some form.
| Component | What it does | What a growing business already has |
|---|---|---|
| Policy engine | Decides whether a given request should be permitted | The conditional access rules in an identity platform |
| Policy administrator | Establishes or terminates the session once the decision is made | The identity provider issuing or refusing a token |
| Policy enforcement point | Sits in front of the resource and enforces the decision | An application gateway, a reverse proxy, an identity-aware proxy, or the application itself |
| Data sources | Feed signals into the decision: identity, device state, threat intelligence, activity | Directory, device management, endpoint protection, logs |
The practical reading of that table is that most businesses have a partial zero trust architecture already and have not recognised it. An organisation using an identity platform with conditional access is running a policy engine. What is usually missing is not a component but coverage: the engine governs the cloud applications and not the internal ones, so the perimeter model persists everywhere the new model has not reached.
Adopting it incrementally
A full architecture is a multi-year programme for a large organisation. For a growing business the useful question is which increments deliver the most reduction in blast radius for the least disruption, and they are reasonably consistent.
- 1
Make identity strong and central
One identity provider, multi-factor authentication everywhere, and no application authenticating against its own separate user list. Until identity is trustworthy, nothing built on top of it can be. This is the foundation and it is usually the largest single step.
- 2
Add context to the access decision
Conditional access rules that consider device compliance, location, application sensitivity and risk signals rather than only whether the password was correct. This is the policy engine doing its job.
- 3
Publish applications through an enforcement point
Rather than granting network reach and letting users find the application, put a proxy or gateway in front of it that evaluates every request. This is where implicit network trust actually gets removed.
- 4
Segment what remains
Legacy systems that cannot sit behind an identity-aware proxy still exist in every estate. Network segmentation limits what reaching them permits, which is the pragmatic substitute where the ideal is unavailable.
- 5
Verify device state, not just user identity
A correct password from an unmanaged, unpatched machine is a weaker signal than the same password from a compliant one. Device posture as an input is what distinguishes a mature implementation from a well-configured login page.
- 6
Log the decisions, not only the outcomes
Assume breach means assuming you will need to reconstruct what happened. Recording why access was granted or refused is what makes that possible later.
The ordering matters. Businesses that begin with the fourth step, because segmentation is familiar territory, end up with a well-segmented network still operating on implicit trust. Segmentation is a valuable control and it is not zero trust; it limits damage rather than removing the assumption that caused it.
What zero trust does not mean
Three misreadings recur, and each one leads a business somewhere expensive.
It does not mean removing the VPN. A VPN grants network reachability while zero trust network access grants application access, and the two operate at different layers rather than as replacements. Where every system a user needs can be fronted by a proxy, application-level access produces a smaller blast radius. Where the estate includes legacy client-server software, unusual protocols, or engineers reaching device consoles, a tunnel remains the practical mechanism — used alongside zero trust principles rather than instead of them.
It does not mean trusting nothing. The name is unhelpful here. Every system trusts something; the question is what, and for how long. Zero trust moves the trust anchor from network position to verified identity plus verified device plus policy, and re-evaluates it per request rather than once per session.
It does not mean buying a zero trust product. Vendors sell components that fit into the architecture, and some of them are genuinely useful. None of them delivers the architecture, because the architecture is a set of decisions about where trust is evaluated, and those decisions remain the business's own.
The honest constraints
Anything worth adopting is worth describing accurately, including where it is difficult.
- Legacy applications frequently cannot participate. Software that authenticates against its own database and cannot delegate to an identity provider will not sit cleanly behind a policy enforcement point, and rewriting it is rarely justified. Segmentation is the practical containment.
- Operational technology and appliances — cameras, controllers, older network devices — often support no modern authentication at all. They belong in isolated segments rather than in the identity model.
- The identity provider becomes critical infrastructure. Centralising authentication means an identity outage is a total outage, which has to be planned for rather than discovered.
- There is a friction cost, and it is real. Poorly tuned conditional access that challenges users constantly produces workarounds, which is a security outcome worse than where you started.
- Full implementation is expensive. Partial implementation is not, and delivers most of the risk reduction. Treating it as all-or-nothing is what stalls adoption.
Common mistakes
| Mistake | Why it happens | What to do instead |
|---|---|---|
| Treating it as a product purchase | That is how it is marketed | Start with identity coverage; buy components only where a gap is identified |
| Starting with segmentation | It is familiar and visible | Identity first; segmentation contains what identity cannot reach |
| Applying it only to cloud applications | Those are the ones the identity platform already covers | Extend coverage to internal applications, or segment what cannot be covered |
| Ignoring device state | User identity feels sufficient | A correct password from an unmanaged machine is a weaker signal; treat it as one |
| Over-tuned conditional access | Every risk signal was enabled at once | Tune so ordinary work is uneventful; users route around constant friction |
| No plan for identity provider failure | Centralisation happened gradually | Treat the identity platform as critical infrastructure with a documented failure plan |
A representative scenario
A composite of situations we see repeatedly; no client detail is included.
A business with around a hundred and twenty staff is told during a security review that it should adopt zero trust, and receives a quotation that exceeds its annual IT budget. The review that followed took a different approach: establish what already existed.
It found an identity platform already in use for email and document storage, with multi-factor authentication enabled for administrators only. Six internal applications authenticated against their own separate user lists, so leavers retained access to them after their central account was disabled. The VPN granted full network reach. Conditional access was available under the existing licence and unconfigured.
The work was sequenced by dependency. Multi-factor authentication was extended to every user, not only administrators. Four of the six internal applications were moved to authenticate against the central identity provider, which removed four separate offboarding gaps as a side effect. Conditional access was configured to require a compliant device for the two applications holding the most sensitive data. The two applications that could not delegate authentication were moved behind a segment reachable only from a defined path. VPN users were moved out of the server segment.
No zero trust platform was purchased. The architecture was not complete by NIST's model, and the blast radius of a compromised credential fell substantially, which was the point.
Implementation checklist
- One identity provider is authoritative, and applications authenticate against it rather than maintaining separate user lists.
- Multi-factor authentication covers every user, not only administrators.
- Conditional access considers device compliance, location and application sensitivity, not only credential correctness.
- Applications are published through an enforcement point rather than reached by granting network access.
- Systems that cannot participate in the identity model are segmented, and the exception is documented.
- Device posture is an input to the access decision for sensitive resources.
- Access decisions are logged with the reason, not only the outcome.
- Conditional access has been tuned so ordinary work on a compliant device is uneventful.
- The identity provider is treated as critical infrastructure, with a documented plan for its failure.
- Network location grants no authority by itself, on or off the premises.
Frequently asked questions
What is zero trust architecture?
Zero trust is an architectural approach in which access decisions are based on verified identity, device state and policy rather than on network location. NIST defines it in SP 800-207 as an evolving set of cybersecurity paradigms that move defences from static, network-based perimeters to focus on users, assets and resources, and describes a zero trust architecture as one focused on protecting resources rather than network segments. The practical consequence is that being inside the office network confers no more authority than being anywhere else, because the network is no longer an input to the trust decision.
Is zero trust a product you can buy?
No. Vendors sell components that fit into a zero trust architecture — identity platforms, identity-aware proxies, device management, network access solutions — and several are genuinely useful. None of them delivers the architecture, because the architecture is a set of decisions about where trust is evaluated and how much it grants, and those decisions remain the organisation's own. Treating it as a purchase is the main reason adoption stalls: businesses receive a quotation, conclude they cannot afford it, and defer work that is mostly configuration of systems they already own.
Does zero trust mean getting rid of the VPN?
Usually not, because the two operate at different layers rather than being alternatives. A VPN grants network reachability; zero trust network access grants access to named applications. Where every system a user needs can be fronted by a proxy, application-level access is the better fit and produces a smaller blast radius by construction. Where the estate contains legacy client-server software, unusual protocols, or engineers who need to reach device consoles, a tunnel remains the practical mechanism. Most growing businesses end up with both, applying zero trust principles to what can support them and containing the rest with segmentation.
Where should a business start with zero trust?
With identity, because everything else depends on it. That means one authoritative identity provider, multi-factor authentication for every user rather than administrators only, and applications authenticating against that provider rather than maintaining their own separate user lists. The last of those has an immediate side benefit unrelated to zero trust: it closes the offboarding gaps that separate application logins create. Only after identity is trustworthy does it make sense to add contextual access rules, publish applications through enforcement points, and use segmentation to contain whatever cannot participate.
Is network segmentation the same as zero trust?
No, though it is frequently presented that way. Segmentation limits what an attacker can reach after a compromise, which is valuable and worth doing. Zero trust removes the assumption that caused the problem — that position on a network implies authority — by evaluating every request against identity, device and policy. A business can be well segmented and still operate entirely on implicit trust within each segment. In a mature design the two are complementary: zero trust governs what can participate in the identity model, and segmentation contains the legacy systems and appliances that cannot.
What are the practical downsides of zero trust?
Three are worth planning for. Legacy applications and appliances frequently cannot delegate authentication or support modern controls at all, so they require segmentation as a containment measure rather than participation. Centralising authentication makes the identity provider critical infrastructure, which means an identity outage becomes a total outage and needs a documented failure plan. And there is a real friction cost: conditional access tuned too aggressively challenges users constantly, which produces workarounds and leaves the business less secure than a lighter control people leave in place. Tuning so that ordinary work on a compliant device is uneventful is what makes the architecture survivable in practice.
Conclusion
Zero trust is a direction rather than a destination, and the direction is away from trusting where a request came from and toward verifying who and what is making it. Most of the movement available to a growing business is configuration of an identity platform it already pays for, extended to cover applications it has not yet included.
The businesses that make progress are the ones that stop treating it as a programme requiring approval and start treating it as an ordering principle for work they were going to do anyway. The ones that stall are usually waiting for a budget cycle to fund a platform that was never the requirement.
Sources and further reading
- Secure remote access architecture— where this principle was introduced, applied to remote access
- Network segmentation for growing businesses— containing what cannot participate in the identity model
- Access control and offboarding— why separate application logins create offboarding gaps
- NIST SP 800-207: Zero Trust Architecture— the definition, and the logical component model
- Microsoft: Conditional Access overview— a policy engine in practice, and the three guiding principles
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.