Zero trust, and the sequencing

"Explain zero trust to a director in 60 seconds, then give me the sequencing."

What it is

Zero trust is the principle that network location confers no trust. Being inside the corporate network, the VPC, or the cluster grants nothing. Every request is authenticated, authorised and encrypted on its own merits, evaluated against current policy, for that specific resource, at that moment.

The formal model is NIST SP 800-207: a Policy Enforcement Point sits in front of every resource and asks a Policy Decision Point whether this subject may perform this action on this resource right now. The decision engine considers identity, device posture, the resource's sensitivity, and behavioural and environmental signals, and it re-evaluates rather than issuing a durable pass.

It is commonly confused with three things. It is not a product, whatever any vendor's slide says. It is not "no VPN", though replacing the VPN perimeter is usually the most visible consequence. And it is not distrust of employees; the assumption is that credentials and devices get compromised, not that people are malicious.

The problem it solves

The perimeter model assumes a hard shell and a soft interior: authenticate once at the boundary, then move freely. Three things broke it.

The perimeter dissolved. Work happens on laptops in cafés, workloads run in three clouds, and SaaS holds the data. There is no boundary to defend.

Lateral movement is the actual attack. In essentially every major breach, the initial foothold was minor (a phished credential, a vulnerable edge device) and the damage came from moving sideways through a network that trusted anything already inside it. A flat internal network converts one compromised laptop into access to everything.

Standing access accumulates. People change teams and keep their old permissions. Service accounts get created for a migration and never removed. After five years the average identity can reach far more than its job requires, and nobody can say what would break if you took it away.

Zero trust attacks the blast radius rather than the initial compromise, which is the right target because you cannot prevent every compromise.

Mechanics

The 60-second explanation for a director

Rehearse this, because "explain it to a director" is testing compression, not knowledge:

"Today, being on our network means being trusted. A laptop that gets phished can reach the customer database, because the database trusts the network rather than the person. Zero trust removes that: every request gets checked against who you are, what device you are on, and whether you should have access to that specific thing, every time.

The practical effect is that one compromised laptop stops being one compromised company. It is not a product we buy, it is a multi-year programme, and the sequencing matters because the first phase pays for the rest.

We start with identity, because everything else depends on knowing who is asking. Then device posture, then service-to-service identity, then network segmentation, then data. My recommendation is to fund the identity phase this year and decide on the rest with that in place."

Answer first, consequence second, then the ask. No mention of SP 800-207, PEPs, or SASE, because a director does not need vocabulary, they need a decision.

The five pillars, and the sequencing

The sequencing is the answer that separates someone who has run a programme from someone who has read the framework. Identity, device, workload, network, data.

1. Identity, first, always. Nothing else works without a reliable answer to "who is this". Single sign-on across every application, phishing-resistant multi-factor (hardware keys or platform authenticators, not SMS), and provisioning and deprovisioning automated from the HR system so a departure removes access the same day. Then start reducing standing access: just-in-time elevation with an approval and an expiry rather than permanent admin.

It goes first for a practical reason as well as a logical one: it produces visible value on its own, so it is fundable. Single sign-on is something users like, which is rare in security work.

2. Device. Access decisions incorporate device posture: is it managed, is it patched, is the disk encrypted, is endpoint detection running. This is what turns "the right password" into "the right person on a trustworthy machine". It requires a device inventory, which most organisations discover they do not really have.

3. Workload identity. Services authenticate to each other cryptographically rather than with shared secrets. SPIFFE/SPIRE issues short-lived X.509 or JWT identities per workload; cloud-native equivalents are IAM roles for service accounts. The goal is stated crisply: no long-lived static credentials anywhere. mTLS everywhere with automated certificate rotation.

This phase is where a service mesh earns its place, because it provides identity, mTLS and authorisation policy without every service implementing them.

4. Network. Microsegmentation: default-deny between workloads, with explicit allow rules. In Kubernetes that is NetworkPolicy; in a mesh it is authorisation policy; in a VPC it is security groups scoped tightly rather than to 0.0.0.0/0. This is where lateral movement actually stops.

It comes fourth because segmentation without workload identity is segmentation by IP address, which is brittle and expires the moment something is rescheduled.

5. Data. Classification, encryption with keys you control, access logged and reviewed, retention and deletion enforced. Last because it is the hardest and because the earlier phases reduce the exposure that makes it urgent.

The identity-aware proxy, in practice

The pattern that replaces the VPN, popularised by Google's BeyondCorp:

User + device  ->  Identity-Aware Proxy  ->  Internal application
                          |
                          v
                   Policy Decision Point
                   - Who is this? (SSO, MFA)
                   - What device? (managed, patched, encrypted)
                   - What are they asking for? (app sensitivity)
                   - Anything unusual? (impossible travel, new device)
                          |
                   allow / deny / step-up

There is no network to be "on". Applications are published through the proxy, and the proxy asks the question every time. A contractor on an unmanaged laptop can reach the low-sensitivity wiki and not the production console, and that distinction is enforced per request rather than by which VPN they were given.

What actually gets built, per phase

Naming durations is what makes it a programme rather than an aspiration. A director asking about zero trust is really asking "how long and how much", and an answer without a time axis is not an answer.

A worked example: sequencing for a 400-person company

Current state: VPN into a flat network, SSO for about half the applications, shared service credentials in a secrets manager, no device inventory, Kubernetes with no network policies.

Year 1, identity. SSO for the remaining applications, hardware keys for engineers and anyone with production access, joiner/mover/leaver automation wired to the HR system, and JIT elevation for production. Measured outcome: standing production access falls from 60 people to 8, and average time-to-revoke on departure goes from "eventually" to same-day.

Year 1 second half, device, overlapping. Enrol laptops in management, feed posture into the access decision, and start blocking unmanaged devices from the sensitive tier. This is the phase with the most user friction, which is why it follows the phase users liked.

Year 2, workload. SPIFFE identities for services, mTLS in the mesh, and a campaign to delete static credentials. The measurable goal is the count of long-lived secrets, tracked publicly, driven toward zero.

Year 2 second half, network. Default-deny NetworkPolicy per namespace, added one namespace at a time behind a dry-run mode so you learn what actually talks to what before enforcing. This is the phase that stops lateral movement, and it is only tractable because workload identity landed first.

Year 3, data. Classification, key management, access review.

What I would say about the VPN, because it will be asked: it goes away gradually, application by application, as each is published through the proxy. A big-bang VPN removal is how these programmes fail, because the VPN is load-bearing for things nobody has inventoried.

What I would measure throughout, so it is a programme rather than a posture: percentage of applications behind SSO, count of accounts with standing privileged access, count of long-lived credentials, percentage of workloads with default-deny network policy, and mean time to revoke access on departure. Five numbers, reported quarterly.

Production evidence

NIST SP 800-207 is the reference architecture: the PDP/PEP split, the trust algorithm, and the seven tenets, including that access is granted per session and that policy is dynamic rather than static.

Google's BeyondCorp papers (Ward and Beyer, 2014 onward, in ;login:) describe the first large-scale production implementation: moving from a privileged corporate network to a model where all applications are accessed through an identity-aware proxy with device and user trust as inputs, and where being on the corporate network grants nothing. It is the origin of the identity-aware proxy pattern.

SPIFFE and SPIRE (CNCF) are the vendor-neutral standard for workload identity: short-lived, automatically rotated cryptographic identities issued per workload, which is what makes "no static credentials" achievable rather than aspirational.

CISA's Zero Trust Maturity Model organises the programme into the same pillars (identity, devices, networks, applications and workloads, data) with maturity stages, which is useful precisely because it gives an organisation a way to say where it is rather than whether it is "doing zero trust".

The debate

The credible criticism is that zero trust has become a marketing term attached to whatever a vendor was already selling, and that organisations buy a product, declare victory, and change nothing about their actual access model. That criticism is fair and it is the reason to lead with sequencing rather than with tooling.

The second criticism is cost and friction. Full implementation is a multi-year programme competing with product work, and the device phase in particular generates real user unhappiness. For a 30-person startup the honest answer is that SSO with hardware keys plus no shared credentials gets most of the value, and the rest is premature.

My position: it is a sequencing problem, not a product decision. Identity first, because everything downstream depends on it and it is the phase that funds itself through visible user value. Then device, workload, network, data. Adopt tooling per phase rather than buying a platform up front, and measure five numbers so the programme is legible to the people funding it. And be honest that it is three years, not a project.

Zero trust is the wrong framing when the organisation has not done the basics: if you have no asset inventory, no patching cadence and shared admin passwords, that is where the risk actually is, and a zero trust programme layered on top is expensive theatre. It is also wrong as a full programme for a small organisation where identity hygiene alone captures most of the benefit.

Follow-up Q&A

"Explain zero trust to a director in 60 seconds." Today, being on our network means being trusted, so a phished laptop can reach the customer database because the database trusts the network rather than the person. Zero trust checks every request against who you are, what device you are on, and whether you should have that specific access, every time. The effect is that one compromised laptop stops being one compromised company. It is a multi-year programme rather than a product, and I would fund the identity phase first because everything else depends on it.

"What's the sequencing and why that order?" Identity, device, workload, network, data. Identity first because every later decision needs a reliable answer to "who is asking", and because SSO and modern MFA produce visible user value, which makes them fundable. Device second because it turns "correct password" into "right person on a trustworthy machine". Workload third, because segmenting by IP address is brittle and you want to segment by cryptographic service identity. Network fourth, which is where lateral movement actually stops. Data last, because it is hardest and the earlier phases have already reduced the exposure.

"Isn't this just replacing the VPN?" That is the most visible consequence, not the substance. The substance is that authorisation becomes per request, per resource, and dynamic, rather than a single boundary check that grants broad access for a session. If you replace the VPN with an identity-aware proxy and still have a flat internal network with standing admin rights and static service credentials, you have moved the perimeter rather than removed it.

"How do you do this without a year of user complaints?" Sequence for user benefit first. SSO reduces password fatigue, so people like it. Then introduce device posture with a long dry-run period where you report what would have been blocked, so you find the exceptions before you enforce them. Same for network policy: run it in audit mode per namespace until the allow list is complete. The programmes that fail are the ones that enforce before they observe.

"What would you do first at a 30-person startup?" Not a zero trust programme. SSO on everything with hardware keys for anyone touching production, no shared credentials, and automated deprovisioning. That is a few weeks of work and captures most of the realistic risk reduction. I would say that plainly rather than starting a three-year programme, because at that size the actual risk is a phished credential and an unpatched laptop, not lateral movement across a segmented estate.

Common misconceptions

The most common is that zero trust is something you buy. Every pillar is a change to how access decisions are made; tooling supports it and does not constitute it.

The second is that it means distrusting employees. The assumption is that credentials and devices will be compromised, which is an empirical observation rather than a judgement about people.

The third is that it is all-or-nothing. It is a maturity progression, and an organisation that has finished identity and device is meaningfully more resilient than one that has not, even with a flat network.

Interview delivery note

If the question is "explain it to a director", give the director version first and only then offer the technical one. Getting that right is the actual test: "Being on our network currently means being trusted, so a phished laptop reaches the customer database. Zero trust checks every request on its own merits, so one compromised laptop stops being one compromised company."

Then the sequencing with its justification: "Identity, device, workload, network, data. Identity first because everything downstream depends on knowing who is asking, and because SSO is the one security project users actually like, which makes it fundable. Network is fourth rather than first because segmenting by IP is brittle; you want to segment by workload identity, so that has to land first."

The depth signal is the honesty about scale and time: "it's about three years for a mid-size company, and at 30 people I wouldn't start the programme at all, I'd do SSO with hardware keys and kill shared credentials." Candidates who present it as universally applicable have not had to fund it.

Further reading

• NIST SP 800-207, "Zero Trust Architecture", for the PDP/PEP model and the seven tenets.
• Ward and Beyer, "BeyondCorp: A New Approach to Enterprise Security" (;login:, 2014) and the follow-up papers on the identity-aware proxy and device trust.
• SPIFFE and SPIRE documentation, for workload identity and short-lived credentials.
• CISA's Zero Trust Maturity Model, for the pillar structure and maturity staging.