Zero trust is not a product and it is not a project. It is a sequence of architectural decisions — and the order you make them in decides whether the programme survives its first year.
Key takeaways
- Identity is phase one. Everything else depends on knowing who is asking.
- MFA coverage percentage is the single most useful early metric.
- Segment by blast radius, not by org chart.
- A control you cannot evidence is a control you do not have.
What zero trust actually means
The formal definition, from NIST SP 800-207, is that access decisions are made per request, based on the identity of the requester, the state of the device, and the sensitivity of the resource — with no implicit trust granted by network location.
The practical translation is shorter: being on the corporate network stops meaning anything. Every consequence of a zero-trust programme follows from that single change, and every difficulty in implementing one comes from how many things quietly depend on network location today.
If your answer to "how does this service authenticate callers" is "it is only reachable from inside", you have found a phase-four item. Write it down now.
Why these programmes stall
Zero-trust initiatives fail in a recognisable way. A vendor is engaged, a platform is purchased, a pilot runs with the IT department, and then the programme meets an application that cannot do modern authentication, a manufacturing network that cannot be segmented without a production outage, and a finance system whose vendor supports exactly one authentication method from 2011.
The programme does not fail loudly. It stalls, becomes a partial deployment covering the easy 60%, and stays there. The remaining 40% is where the risk actually was.
The way through is sequencing: do the things that reduce the most risk per week of effort first, and be explicit that the difficult residue is a named phase with its own budget rather than an assumed continuation.
Phase one: identity (weeks 1–10)
Nothing else works until you can answer "who is this?" reliably. This phase is unglamorous, high-friction and delivers more risk reduction than the rest of the programme combined.
Multi-factor coverage to 100%
Not 94%. The gap is always the same set of accounts: service accounts, contractors, executives who were exempted, and the shared login in the warehouse. Those are precisely the accounts an attacker wants.
Track coverage as a single number, reported weekly to the executive sponsor. It is the most useful metric in the entire programme because it is unambiguous, it moves, and it correlates directly with the most common breach vector.
Prefer phishing-resistant factors — FIDO2 keys or platform authenticators — for administrative and high-value accounts. SMS is better than nothing and worse than everything else.
Eliminate standing privilege
Administrative rights become time-bound and requested, not permanently assigned. Every privileged session is recorded. Shared administrator accounts are vaulted and their credentials rotated on checkout.
Expect resistance, and expect it to be reasonable — engineers who have had persistent admin for a decade will correctly point out that just-in-time elevation adds friction. Meet it with tooling that makes elevation take under a minute, not with a policy memo.
Automate joiner, mover, leaver
Most organisations are competent at joiners and poor at movers and leavers. Access accretes: someone moves from finance to operations and keeps both entitlements. After eight years they can approve, execute and reconcile the same transaction.
Automate deprovisioning from the HR system as the authoritative source, and run a quarterly access review that requires a positive affirmation from the line manager rather than a silent default to keep.
Phase two: device trust (weeks 8–20)
Once identity is solid, add the second signal: is this device known, managed and healthy? A valid credential on an unmanaged machine is a credential in an unknown security state.
Practically this means enrolling corporate devices in management, defining a health baseline — disk encryption on, endpoint protection running, operating system within a supported patch window — and gating access to sensitive resources on that baseline.
The hard question is contractors and BYOD. The workable pattern for most mid-market organisations is tiered: unmanaged devices get browser-based access to a defined set of applications with no local data persistence; managed devices get everything. That gives contractors a working path that does not require enrolling their personal laptop, and it keeps the sensitive tier honest.
Phase three: segmentation (weeks 16–40)
Flat networks are the reason a single compromised workstation becomes a full-estate incident. Segmentation limits lateral movement, and it is the phase where operational risk is highest — a badly scoped rule takes a production system offline.
Segment by blast radius, not by organisational structure. The useful question is not "which department owns this?" but "what should be able to talk to this, and what would it cost if that were wrong?" Typical zones: user endpoints, general server workloads, sensitive data stores, operational technology, management plane, and third-party access.
The sequence that avoids outages
- Observe. Deploy the enforcement points in monitor-only mode and collect real traffic for at least four weeks, covering a month-end.
- Model. Derive the rule set from observed flows, not from documentation. The documentation is wrong; this is not a criticism, it is simply always true.
- Alert. Run the rules in alert-only mode for two weeks and triage every violation. This is where you find the quarterly batch job nobody mentioned.
- Enforce, per zone. One zone at a time, with a tested rollback and a defined change window.
Operational technology and manufacturing networks get their own track, their own risk assessment and, usually, their own outside expertise. Do not treat them as another zone.
Phase four: application access (weeks 30–60)
The endgame is that applications are reachable by authenticated, authorised, healthy sessions regardless of network location — which is what finally lets you retire the flat VPN that grants network-level access to everything.
Modern applications move first: federate them to the identity provider, enforce conditional access, done. The residue is the interesting part, and every enterprise has one:
- Legacy web applications with no modern authentication support — front them with an identity-aware proxy.
- Thick clients speaking proprietary protocols — publish through a brokered access gateway.
- Vendor-managed systems where the supplier controls the authentication method — a commercial conversation, escalated early, with contract renewal as leverage.
- Systems that genuinely cannot change — isolate into a tightly controlled zone with compensating monitoring, and put a replacement on the roadmap with a date.
Name this residue in the programme plan from week one. It is the difference between a programme that finishes and one that is quietly declared complete at 60%.
Measuring progress without deceiving yourself
Maturity-model scores are easy to move and mean little. These five numbers are harder to game:
| Metric | Why it is honest |
|---|---|
| MFA coverage (% of all accounts, including service accounts) | Unambiguous, and the denominator cannot be quietly narrowed |
| Accounts with standing administrative privilege | Should trend to zero; every exception needs a name attached |
| Applications behind conditional access (% of the application inventory) | Forces you to maintain an application inventory, which is itself valuable |
| Mean time to deprovision after a leaver date | Measured from HR record, not from the ticket being raised |
| Segments in enforce mode vs. monitor mode | Distinguishes deployed from actually enforcing |
A control you cannot evidence is a control you do not have
Every control should produce an artefact automatically: a log, a report, a policy-as-code definition in version control. If demonstrating a control to an auditor requires an engineer to take screenshots, the control will decay the moment attention moves elsewhere — and you will not know that it has.
This is also where compliance stops being separate work. SOC 2, HIPAA, PCI DSS and ISO 27001 overlap heavily. Map your control set once, tag each control with the frameworks it satisfies, and let the evidence assemble itself. Audit preparation becomes a report rather than a project.
A realistic timeline
For a mid-market organisation of 500 to 2,000 staff, with a competent existing IT function: twelve to eighteen months to complete phases one through three and to have phase four underway with the residue explicitly named and scheduled.
Anyone promising ninety days is selling a product deployment, not an architecture. That may still be worth buying — but be clear which one you are purchasing.
Frequently asked questions
No. Most mid-market organisations already own the majority of what they need in their existing identity provider and endpoint management suite. Buy to fill a specific gap — an identity-aware proxy for legacy applications, or a segmentation enforcement point — not to acquire a strategy.
You can start, but the VPN is usually the largest remaining source of implicit network trust. The realistic path is to shrink its scope progressively as applications move behind identity-aware access, then retire it once the residue is handled.
Treat it as its own zone with its own policy: named individual accounts rather than shared vendor logins, time-bound access tied to a change ticket, session recording for anything privileged, and mandatory MFA enforced by you rather than by the vendor.
