Zero Trust: the end of the trusted internal network
The 'hard shell, soft centre' model no longer works. We explain what Zero Trust is, where to start a rollout and what to avoid.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 30 April 2026
- READING TIME
- 7 min read
- TOPIC
- Cloud, Infrastructure and DevSecOps
For years, network security rested on one assumption: there’s an “outside” (dangerous) and an “inside” (trusted), with a firewall in between. The problem is that once an attacker crosses that boundary — through phishing, a VPN or a vulnerable service — they move through the soft centre almost unopposed. Zero Trust flips that assumption.
What Zero Trust means
The principle is simple: never trust, always verify. No user, device or service is trusted just because it’s “inside” the network. Every access is authenticated, authorised and limited to the necessary minimum — regardless of where it comes from. The framework for this approach is described in, among others, NIST SP 800-207.
It isn’t a product you buy, but an architecture and a mindset. You can’t “switch on Zero Trust” with a single purchase — you build it step by step.
The pillars it rests on
- Strong identity. The foundation is trustworthy authentication — ideally phishing-resistant (FIDO2 keys, passkeys).
- Least-privilege access. Users and services get exactly what they need, and only for as long as they need it.
- Microsegmentation. The network is split into small zones, so compromising one element doesn’t grant access to the rest — the same logic that breaks a ransomware attack chain.
- Context and device verification. An access decision considers device posture, location and risk, not just a correct password.
- Continuous monitoring. Trust isn’t granted once and for all — it’s constantly re-evaluated.
Where to start
Don’t begin with a big “everything at once” rollout. An incremental approach works better:
- Inventory identities, devices and your most important assets.
- Strengthen authentication (phishing-resistant MFA) for critical access.
- Break up the flat network — start by segmenting the most sensitive systems.
- Replace “trust in the VPN” with per-application access, verified every time.
What to avoid
The biggest trap is treating Zero Trust as a marketing label stuck onto existing products. The second is trying to do everything at once and paralysing the organisation. Zero Trust is a direction you move toward in stages, starting where the risk is greatest. If you’d like to plan that path for your network, get in touch.
Access decisions in the NIST model
NIST SP 800-207 removes trust based solely on network location or device ownership. Access follows evaluation of the subject and device for a specific resource. A Policy Engine decides, a Policy Administrator executes the decision, and a Policy Enforcement Point permits or blocks the session.
This does not require a user login for every packet. It means the session can be reassessed using risk, device posture, behaviour and policy. A VPN may remain transport, but it should not automatically grant broad network access.
Begin with one flow
Select a high-value resource such as an administration panel or finance system. Map users, devices, data, dependencies and current paths. Define a policy based on strong identity, device state, minimum scope and complete logging.
Start in observation mode, measure legitimate cases, refine exceptions and then enforce. A repeatable small pattern is more useful than a platform purchase without a policy model.
Workload identities
Zero Trust includes services. Give each workload a separate rotating identity and grant API access by purpose and environment. A shared secret across applications prevents precise revocation and audit.
Cloud-native policy may be enforced at an API gateway, service mesh or proxy. Application authorisation remains necessary; infrastructure cannot repair broken object-level access control.
Measuring progress
Track resources under policy, phishing-resistant MFA adoption, shared accounts, session scope, revocation time and decisions using a current device signal. The outcome is reduced impact from identity compromise, not the number of installed agents.
NIST SP 1800-35 provides implementation examples. Connect the roadmap with privileged access management and resource-focused segmentation.
Sources: NIST SP 800-207 — Zero Trust Architecture, NIST SP 800-207A — cloud-native access control, NIST SP 1800-35 — Implementing a Zero Trust Architecture.


