For most organisations, the network perimeter stopped being a useful security boundary years ago. People work from anywhere, applications live in SaaS and public cloud, and attackers usually walk in through a stolen password rather than over a firewall. Zero Trust is the response to that reality, and identity is what makes it work. This is an expanded English take on the article our colleagues Joost Koiter and Richard Voorintholt wrote, with the architecture, the pitfalls and the steps we use across 40+ implementations.
The classic security model assumed a trusted inside and an untrusted outside, with a firewall in between. Once you were on the corporate network, you were trusted. That worked while staff sat in offices, applications ran in the data centre and threats came from the outside.
That picture is gone. Staff log in from home, from customer sites, from airports. Applications sit in dozens of SaaS tenants. The attacker is rarely battering the firewall. More often, they arrive with a valid login obtained through phishing or a credential leak.
For Linda, the CISO, this means the audit question "who has access to what" no longer has a tidy answer based on network zones. For Marco, the IT operations lead, it means access decisions can no longer rely on whether someone is on the VPN. The decision has to be made per request, per resource, with current context. That is what Zero Trust is for.
Organisations that postpone the move to Zero Trust pay for it in three ways, and not the ways most decks suggest.
The first cost is operational. Marco's team spends hours each week on manual provisioning, exceptions, role requests and offboarding tickets that should not exist. Every new SaaS tool adds another silo of accounts. Joiner-mover-leaver flows depend on a person remembering to file a request.
The second cost is governance. Linda has to prove during audits who has access to which application and why. If access lives in spreadsheets and ad-hoc admin consoles, that proof is fragile. One missing access review, and the audit finding writes itself.
The third cost is opportunity. Business teams want to onboard a new partner, open a new market, plug in a new application. If every change requires a redesign of network rules and a procurement round for security tooling, security becomes the brake. The organisation either slows down or quietly works around the controls. Both outcomes are bad.
Zero Trust was named in 2009 by John Kindervag, then a Forrester analyst. The principle is short: never trust, always verify. Every request to access a resource is evaluated on its own merits, regardless of where it originates.
The US National Institute of Standards and Technology turned that principle into a logical reference architecture in SP 800-207. Two components do most of the work.
The Policy Decision Point (PDP) decides whether a request is allowed. It evaluates the configured policy and pulls in context from other sources: identity information, device posture, threat intelligence, activity logs.
The Policy Enforcement Point (PEP) carries out the decision. It sits as close to the resource as possible and gates the connection between subject and resource. Allow, deny or step up.
Around those two components sit other logical roles: continuous diagnostics, threat intelligence feeds, activity logging, ID management. They are roles, not products. In real implementations, several of them collapse into the same system.
The PDP can only make a useful decision if it has a trustworthy answer to a basic question: who is this, on what device, with what entitlements? Without that answer, every other signal is noise. This is why we describe identity as the control plane of a Zero Trust architecture, not as one input among many.
That control plane has two layers. Identity and Access Management (IAM) handles authentication and authorisation in real time: is this the right person, on a known device, with the right to do this now. Identity Governance and Administration (IGA) handles the lifecycle and the audit trail: how did this entitlement get assigned, is it still appropriate, can we prove it.
If those two layers are fragmented, the PDP cannot do its job. We see this often. Single sign-on for some applications, manual provisioning for others, access reviews that live in spreadsheets, joiner flows that depend on tickets. A Zero Trust programme built on top of that fragmentation will inherit every gap.
Identity is the foundation. It is not the whole story. The example Joost and Richard often use: an employee logs in with valid credentials from a known device on a normal working day. Classic IAM says: allow. Five minutes later that same session starts pulling gigabytes of data out of a finance system. Something is wrong. Maybe a compromised account, maybe an exit-day exfiltration.
Zero Trust adds continuous context to that decision. Not only "is this person allowed", but "is this behaviour consistent with the role". That requires signals from endpoint security, network logs and application logs, fed back into the PDP, and a PEP that can act mid-session: terminate, re-authenticate, or alert the SOC.
This is why a Zero Trust programme is not an SSO upgrade. It is a redesign of how access decisions are made, with identity as the foundation and behavioural context as the responsive layer above.
A Zero Trust programme does not have to be a multi-year replacement project. We start with an MVP: one application or one user group, end-to-end Zero Trust, working in 30 days. That gives the security team a live policy to evaluate, IT operations a real workload to test provisioning and logging against, and the business something concrete to look at within a month rather than a slide deck.
From that MVP we expand. Next application, next user group, next set of policies. Iteratively, based on what the first cycle taught us. That is the practical version of at the speed of business: capability shipped every month, not an end-state on paper. In most engagements the PDP role lives on the Okta platform, because that is where our customers already have most of their identity foundation. How we run that work is described on our Okta implementation page.
What we do alongside the technology choices:
You do not need a programme charter to start. Three questions will tell you whether your foundation is in shape.
Three yes answers and you have a foundation worth building on. Any no answer is your first work package.
Want to talk it through with one of our architects? Get in touch for an honest assessment of where you stand and what the sensible next step looks like. We are an Okta Apex Partner and Okta Partner of the Year 2025 in the Benelux, with 18 years of practice and 40+ implementations behind us. We tell customers what to do next, not what to buy first.