SECURITY
Zero Trust is a sequence, not a product
5 min read
Zero Trust works as a sequence — identity, then devices, then applications, then data — because each stage depends on signals the previous one produces, and starting in the middle creates controls that cannot be trusted enough to enforce.
Zero Trust is sold as a product more often than it is explained as an approach. Several vendors will tell you theirs delivers it, and each is describing one component of something that is mostly a set of decisions about order.
The underlying idea is simple enough to state in a sentence: verify explicitly, grant the least access that works, and assume a breach has already happened. The difficulty is entirely in which part you do first.
Identity first, because everything else is a signal about identity
A device compliance policy is only meaningful if you know which identity the device belongs to. An application access rule is only enforceable if the application trusts your identity provider. Both depend on identity being sorted first.
Identity work means consolidating authentication into one provider where possible, multifactor everywhere including the accounts people argue should be exempt, privileged roles that are temporary rather than permanent, and legacy authentication blocked.
Devices second, because they are the next signal
Once identity is verified, the next question is what the verified person is using. Device compliance turns that into something a policy can consume: enrolled, encrypted, patched, running a supported OS.
This is the stage where the scale of the work usually becomes clear, because the enrolment gap is bigger than the plan assumed. That is better discovered here than later.
Applications third
With identity and device signals available, application access can finally be conditional on something meaningful rather than on network location.
The practical work is bringing applications behind the identity provider one at a time. The ones that resist — legacy systems with their own credential stores, appliances with local accounts — are the real inventory of technical debt, and they tend to be the ones that matter most.
- Identity: single provider, multifactor, privileged access, legacy auth blocked
- Devices: enrolment, compliance, update rings, a path for unmanaged devices
- Applications: behind the identity provider, access conditional on identity and device
- Data: classification and handling, once you know who and what can reach it
Data last, and that is not a demotion
Data classification is frequently proposed first because it sounds foundational. In practice a labelling scheme designed before access is controlled ends up protecting content that anyone in the organisation can already open.
Doing it after the access layers means the labels are applied to content whose reachability you understand, and the handling rules you attach to them are enforceable.
Measure between every stage
The sequence only works if each stage is measured in report-only mode before enforcement. Each one affects a population you have not fully enumerated, and the measurement is how you find out who that is without an outage.
This is the discipline that separates a Zero Trust programme that completes from one that is quietly abandoned after the second rollback.
Questions we get asked
Can you buy Zero Trust as a product?
No. You can buy components that implement parts of it — an identity provider, device management, network access control — but the architecture is the set of decisions about how those are sequenced and what signals each consumes.
How long does a Zero Trust programme take?
For a mid-sized organisation, the identity and device stages are typically several months each, driven by enrolment and remediation rather than configuration. Applications take as long as the legacy inventory demands, which varies enormously.
Does Zero Trust mean removing the VPN?
Eventually, for most applications, because access becomes conditional on identity and device rather than on being inside a network perimeter. In practice the VPN usually stays for a long tail of systems that cannot be brought behind the identity provider.