Zero Trust: Sequencing the Work That Actually Reduces Risk

Zero trust is often presented as a product decision. It is not. It is an architectural commitment that changes how access is granted across every system an organization runs, and it takes years rather than quarters to complete. The organizations that struggle with it are usually the ones that bought tooling before deciding what they were trying to prove.

The useful executive question is not whether to adopt zero trust. It is which parts of the estate justify the effort first, and what evidence leadership should expect at each stage.

1. What the model actually asserts

Traditional network security granted trust by location. Once a user or device was inside the perimeter, access was largely implicit. That assumption fails against credential theft, contractor access, cloud services that sit outside the network entirely, and attackers who move laterally after a single foothold.

Zero trust replaces location-based trust with a per-request decision. NIST SP 800-207 sets out the reference model: every access request is authenticated, authorized and evaluated against policy, using signals about the identity, the device, and the resource being requested.

The practical consequence is that identity and device posture become the control plane. Network segmentation still matters, but it stops being the primary boundary.

2. Where the effort actually goes

Most of the work is not in the enforcement layer. It is in the prerequisites:

• A reliable inventory of applications, data stores, and who legitimately needs each one
• An identity provider that is genuinely authoritative, rather than one of several
• Device posture signals that can be trusted enough to make access decisions
• Application access paths that can be brokered rather than routed over flat internal networks
• Logging sufficient to reconstruct what was accessed and by whom

Organizations that skip the inventory step tend to discover it later, when a policy blocks something business-critical that nobody had documented.

3. A sequence that holds up

Zero trust is not delivered as a single programme. A workable order of operations:

Start with identity. Consolidate onto one authoritative identity provider, remove standing administrative access, and move privileged accounts to just-in-time elevation. This is where the largest risk reduction per unit of effort usually sits.

Then address authentication strength. Phishing-resistant methods — FIDO2 security keys or passkeys — close the attack paths that SMS codes and push approvals leave open. Start with administrators, finance, and anyone with access to customer data.

Then broker application access. Move remote access away from broad network connectivity toward per-application brokering, so a compromised endpoint does not inherit the network.

Then segment what remains. Legacy systems that cannot participate in modern authentication need compensating isolation. This is normally the slowest part, and it is reasonable for it to remain in progress for some time.

4. What leadership should ask for

Zero trust programmes fail quietly when nobody defines what progress looks like. Reasonable questions for a steering review:

• What proportion of employees authenticate with a phishing-resistant method today?
• How many accounts hold standing administrative privilege, and is that number falling?
• Which applications still rely on network location for access control?
• Can we produce an access record for a given user and system over a given period?
• Which legacy systems are we accepting risk on, and who signed that acceptance?

These are answerable without technical depth, and they track the things that actually reduce exposure.

5. The common failure modes

Three patterns recur. The first is buying a product labelled zero trust and treating the purchase as the outcome. The second is applying strict policy to the workforce while leaving service accounts, integrations, and machine identities untouched — which is where attackers increasingly concentrate. The third is a programme with no accepted endpoint, which consumes budget indefinitely because nobody defined what “done enough” means for each system.

Treat it as a multi-year architectural decision

Zero trust is worth doing, and the identity work at the front of it delivers real risk reduction early. But it is a change to how access is granted across the estate, not a control to be switched on. Organizations that scope it honestly — identity first, phishing-resistant authentication next, legacy isolation accepted as slow — tend to get further than those that start with the enforcement layer.

This article is general educational guidance, not legal advice, a certification, or a substitute for an organization-specific security assessment.