You do not need a two-year programme to get the high-value 80% of zero trust. You need a 90-day sprint with the right sequencing, clear ownership, and a team that understands which controls actually move the needle on breach risk versus which ones satisfy an auditor.
I have run zero trust implementations at a reinsurer handling €3B+ in annual premium, at an energy infrastructure operator, and at a mid-market fintech that processed north of €500M in payments per month. The timelines differed. The foundational sequence did not. Every time, the first 90 days delivered the majority of the risk reduction. Everything after that was incremental hardening and edge-case coverage.
The reason most zero trust programmes fail is not technical. It is that they are scoped as transformation programmes rather than security programmes. Transformation programmes need executive sponsorship, change management budgets, and multi-year roadmaps. Security programmes need a threat model, a prioritised control list, and an engineering team that understands the "why" behind each change.
Why Sequence Matters More Than Scope
Zero trust is not a product you buy and deploy. It is a set of principles — verify explicitly, use least privilege, assume breach — applied across identity, devices, network, applications, and data. Every vendor with a zero trust product will tell you to start with their layer. Ignore that. Start where the breach risk is concentrated.
The data is clear. Credential compromise is the dominant attack vector. An adversary with valid credentials inside a flat network can move laterally, escalate privileges, and exfiltrate data before your SIEM fires a single alert. The first 30 days should be entirely focused on removing the value of those credentials: enforce MFA everywhere, eliminate shared accounts, implement conditional access policies, and kill standing privileged access.
Network segmentation and device trust come second. Stopping lateral movement requires knowing which devices are compliant and restricting which systems they can reach. Application-layer controls — service-to-service authentication, workload identity, mTLS between internal services — come third. Data classification and data loss prevention last.
This is the sequence that produces the 80% risk reduction in 90 days. It is not the sequence that most zero trust vendors recommend because it does not require purchasing their network product in week one.
The 90-Day Playbook
Audit every human identity in your directory. Find service accounts with human-style credentials. Find shared accounts. Find admin accounts without MFA. The inventory alone will surface three to five critical exposures you did not know existed. Then enforce MFA for all human accounts with no exceptions — not "strongly encourage," enforce via conditional access policy. Roll out phishing-resistant MFA (FIDO2 or hardware tokens) for privileged accounts first, authenticator app for the remainder. Eliminate standing privileged access: no account should have permanent admin rights. Use Privileged Identity Management (PIM) or equivalent for just-in-time elevation with approval workflows.
Enroll devices in your MDM (Intune, Jamf, or equivalent) and define a compliance baseline: OS patch currency (no more than 30 days behind), disk encryption enforced, EDR agent present and reporting. Conditional access policies should gate access to critical applications on device compliance status. This does not require re-imaging or replacing devices — it requires defining the baseline and giving non-compliant devices a remediation window (typically two weeks). Non-compliant devices get access to a limited set of resources only.
Map your blast radius. If a workload in your development environment is compromised, how far can an attacker move? In most organisations the answer is "to production," because flat network trust combined with shared credentials connects everything. Implement network segmentation at the workload level: production, staging, and development environments should have no lateral trust. Internal firewall rules should default-deny between segments. VPN-based access should be replaced with identity-aware proxies (BeyondCorp model, Zscaler, Cloudflare Access, or equivalent) — users get access to specific applications, not network segments.
Workload identity is where most teams underinvest. Service accounts with long-lived secrets are a persistent exposure: rotate them, and you get a brief reduction in risk; eliminate them, and you eliminate the attack surface. Move to short-lived workload identity tokens (Azure Managed Identity, AWS IRSA, GCP Workload Identity Federation, or SPIFFE/SPIRE for multi-cloud) wherever the platform supports it. For services that cannot use managed identity, rotate secrets on a 30-day or shorter cycle enforced by your secrets manager, not by a calendar reminder.
Zero trust controls fail silently without detection coverage. Ensure every identity event (sign-in, MFA bypass attempt, privileged elevation) is logged and feeding your SIEM. Define and test alerts for: impossible travel sign-ins, MFA fatigue attacks (repeated push prompts), privilege escalation outside PIM, and lateral movement attempts flagged by EDR. By day 90 you should have a weekly identity and access review meeting where these alerts are triaged. The meeting is the control — the tooling is just the input.
What "Can't Stop Shipping" Actually Means
The objection I hear most from engineering leaders is that security programmes slow down delivery. That objection is usually correct — when security is implemented as a gate rather than as a guardrail.
The controls above are additive and non-disruptive when sequenced correctly. MFA enforcement for a team already on Azure AD takes two weeks, not two months, and does not touch your build pipeline, your deployment process, or your customer-facing systems. Conditional access policies apply to authentication flows, not application code. Device compliance checking happens at login, not at deploy time.
The only controls in this playbook that require engineering time are the service-to-service authentication changes. Those are the right place to invest engineering time because they produce the most durable security improvement. Managed identity eliminates an entire class of credential-based attack. The implementation work — typically two to four weeks of engineering effort spread across 30 days — is meaningful but not delivery-halting.
The approach is to run security work in parallel with feature delivery, not sequentially. Your security programme should have its own team (even if that team is one dedicated engineer plus part-time input from a senior architect), its own sprint cadence, and its own definition of done. It should never block your product team's releases.
The MFA exception that undoes everything
The single most common failure pattern in zero trust implementations is the exception list. It starts with one legacy application that breaks with MFA. Then three more. Then a VIP who finds it inconvenient. Then an integration that's 'too complex to fix right now.' Within six months you have forty exceptions and a conditional access policy that is conditional on nothing. Zero trust with exceptions is not zero trust. It is a security theatre programme with a good slide deck. Fix the legacy application. Enforce the policy. There is no exception that is worth the attack surface it creates.
The Controls That Actually Move Risk, Versus the Ones That Sound Good
After running these programmes across multiple industries, I have a clear view of which controls deliver risk reduction and which deliver compliance theatre.
| Control | Actual Risk Reduction | Implementation Effort | Sequence Priority |
|---|---|---|---|
| MFA everywhere (phishing-resistant for privileged) | Very high — directly blocks credential-based attacks | Low — days to weeks | 1 |
| Just-in-time privileged access (PIM) | High — eliminates standing attack surface | Low–medium | 1 |
| Device compliance gating | High — removes unmanaged devices from critical access | Medium | 2 |
| Network microsegmentation | High — limits blast radius post-compromise | Medium–high | 3 |
| Managed workload identity | High — eliminates long-lived service credentials | Medium | 3 |
| Identity-aware proxy (app-level access) | Medium–high — removes VPN exposure | Medium | 3 |
| Data classification and DLP | Medium — depends heavily on data volume and structure | High | 4 |
| mTLS between all internal services | Medium — valuable in mature environments | High | 4 |
| Software-defined perimeter | Medium — adds defence in depth | High | 5 |
| Network packet inspection (NGFW) | Low–medium — limited against credential-based attacks | High | 5 |
The bottom of that table is where enterprise security vendors make their margins. It is not where you should start if you want to reduce breach risk in 90 days.
Measuring Whether It's Working
At day 30, the metric that matters is MFA coverage: what percentage of sign-ins to critical applications used MFA? The target is 100% for critical apps. If you're below 95%, you have exceptions to close.
At day 60, the metric is blast radius reduction: if your highest-risk workload was compromised today, how many other systems could an attacker reach? Map it. If the answer is "most of production," your segmentation work is not done.
At day 90, the metric is detection coverage: for each of your critical identity and access controls, do you have an alert that fires when the control is bypassed or tampered with? Zero trust without detection is a single layer of defence. You need to know when it fails.
The 90-day review conversation worth having
At day 90, run a tabletop exercise using a credential compromise scenario. An employee's laptop is stolen and their credentials are used from an unfamiliar location at 2am. Walk through what happens: does MFA block it? Does conditional access flag the impossible travel? Does the EDR detect the device as non-compliant? Does your SIEM fire an alert? Does anyone see it? The gaps you find in that exercise are your day 91 priorities. The gaps you don't find are what your adversary will.
The Organizational Pattern That Makes This Work
The technical controls are the easier part. The harder part is the organisational alignment required to enforce them without creating a security-versus-engineering standoff.
The pattern that works is a security champion embedded in the engineering team — not a security team that hands requirements to engineering. That champion owns the implementation of security controls as part of the regular sprint, uses the same tools and processes as the rest of the engineering team, and is the bridge between the security posture requirements and the practical implementation constraints.
Alongside that, a monthly security review at the leadership level — CTO and CISO or equivalent — that reviews the metrics above, closes exceptions, and makes resource allocation decisions. Zero trust as a 90-day sprint needs to become zero trust as an operational discipline. The sprint delivers the foundations. The operational model sustains them.
The companies that sustain strong security posture are not the ones that ran the best implementation project. They are the ones that built the security function into how engineering operates — as a team capability rather than an external gate.
If your team needs to move from a flat network and legacy access model to a credible zero trust posture — without stopping your product roadmap — let's talk. I work with engineering and security leaders to design and run exactly this kind of programme. Book a 30-minute discovery call and let's start with your current threat model.