Ninety days isn’t enough to implement Zero Trust in a cloud estate. It is exactly enough to make the decisions that will define the next eighteen months. This article gives you the 8-pillar framework we use, the realistic state of play across each pillar in client environments we walk into, and a phased roadmap that produces real wins in 90 days without overpromising.
A client called us last quarter with a Zero Trust deadline imposed by their board. “We need Zero Trust by year-end. Can you help us get there?”
Our honest answer was no. Twelve months isn’t long enough to implement Zero Trust at a 2,000-person enterprise, and ninety days definitely isn’t. The board had been sold a narrative that the work could be done quickly. It can’t, and pretending otherwise sets the program up to fail in year two when reality catches up.
What ninety days can do, if used well, is exactly enough. It can land two or three quick wins that demonstrate momentum. It can produce a credible architecture decision, a maturity baseline, and an eighteen-month roadmap that the board can fund. That’s a useful first quarter, and the rest of this article is how we use it.
Before you read further
If your board has given you a Zero Trust deadline of six months or less, the most useful thing to do is push back. Programs sold as fast generally fail slowly. Our experience is that the CISOs who reset expectations early get more done in eighteen months than the ones who agreed to an impossible timeline and then spent year two explaining the slip.
Table of Contents:
Why Zero Trust Frameworks Don’t Quite Line Up
If you’ve read three Zero Trust framework documents this year, you’ve probably read three different pillar counts. NIST SP 800-207 organizes the model around seven tenets. CISA’s Zero Trust Maturity Model lists five core pillars plus three cross-cutting capabilities, which is what we use in practice and what we mean when we say eight pillars. Microsoft and other vendors structure things slightly differently. The variation is more cosmetic than substantive; the underlying concepts are stable.
We use the CISA model because it cleanly separates the operational pillars (the things you secure) from the cross-cutting capabilities (the things that make security effective). Identity, devices, networks, applications, and data are what you protect. Visibility, automation, and governance are how protection actually runs. Both halves matter; programs that focus only on the first half stall around month nine.
For the foundational reference, NIST SP 800-207 is the authoritative source for the tenets, and CISA Zero Trust Maturity Model v2.0 is the most practical pillar framework.
The 8 Pillars and Where We Find Real Programs
Pillar 1: Identity
What this pillar covers: Every access decision starts with verifying who or what is requesting access. Strong authentication, continuous validation, identity-centric policy.
Where most clients actually are: Most clients we walk into have MFA at 60 to 80 percent of users, federated SSO across some applications, and conditional access policies that have grown by accretion. The hardest gap is usually service-account hygiene and legacy authentication paths that bypass MFA entirely.
The day-zero move: Block legacy authentication protocols and enforce MFA universally for human users (including admins on phishing-resistant factors). This is the single highest-impact move we can take in the first 30 days.
Pillar 2: Devices
What this pillar covers: Endpoint posture, compliance, and trust before granting access. Managed and unmanaged devices treated differently. Continuous device-health evaluation feeds the access decision.
Where most clients actually are: Endpoint posture management is usually deployed but inconsistently enforced. We frequently find conditional access policies that check device compliance for some applications and not others. Unmanaged BYOD devices are typically the largest exception.
The day-zero move: Wire device compliance signals from your EDR/MDM platform into the conditional access decision for high-risk applications first. Don’t try to enforce universally on day one; sequence by risk.
Pillar 3: Networks
What this pillar covers: Macro and micro-segmentation. Encrypted traffic by default. Network access mediated by identity and context, not perimeter location.
Where most clients actually are: VPC and VNet segmentation is usually decent at the macro level (production / non-production). Micro-segmentation between workloads in the same VPC is often missing. East-west traffic inside the perimeter is frequently unencrypted.
The day-zero move: Inventory the macro segments and document the rule of “deny by default with explicit allow” for traffic crossing them. Service-mesh mTLS or equivalent for east-west encryption is a quarter-two move; the day-zero move is the inventory.
Pillar 4: Applications and Workloads
What this pillar covers: Workload identity, secure development lifecycle, runtime protection, API security. Applications authenticate to each other; runtime behavior is monitored.
Where most clients actually are: Workload identity (managed identity, IRSA, workload identity federation) is increasingly used for new builds. Legacy applications running on static credentials remain widespread. API security tends to be perimeter-focused (WAF, gateway) with little intra-application protection.
The day-zero move: Identify the top five legacy workloads still using static credentials and put them on the road to managed identity migration. The day-zero move is the inventory; the migration runs across quarters two and three.
Pillar 5: Data
What this pillar covers: Classification, encryption, access controls based on data sensitivity, monitoring of data movement. Data-centric protection that travels with the data.
Where most clients actually are: Encryption at rest is usually present, often with provider-managed keys rather than customer-managed where the sensitivity warrants the upgrade. Classification is the laggard pillar; most clients have a policy on data classification and limited operational tagging to support it.
The day-zero move: Identify the top three data stores by sensitivity and verify customer-managed keys, audit logging, and access governance for each. Classification at scale is a multi-quarter effort; the day-zero move is the top-three review.
Pillar 6: Visibility and Analytics (cross-cutting)
What this pillar covers: Centralized telemetry, anomaly detection, dashboards that show whether the controls in the other pillars are working. The eyes and ears of the program.
Where most clients actually are: Telemetry is usually scattered across the SIEM, cloud-native logging, EDR consoles, and identity logs. Aggregation is uneven. We frequently see programs running well-tuned controls without dashboards that show whether the controls are operating effectively.
The day-zero move: Stand up a single Zero Trust dashboard that tracks four to six leading indicators (MFA coverage, conditional access enforcement, privileged session ratios, anomaly counts). Detection and response on the underlying alerts remains with your chosen SOC and IR partner; we engineer the telemetry layer.
Pillar 7: Automation and Orchestration (cross-cutting)
What this pillar covers: Automated response to detected conditions, policy-as-code, infrastructure-as-code for security controls. The reflex layer that makes the program scale.
Where most clients actually are: Automation is the pillar we see lag most predictably. Detection often produces alerts; response is usually human-driven and slow. Policy-as-code is gaining ground but is rare outside the most mature programs we work with.
The day-zero move: Pick one alert category (typically failed-MFA spikes or unusual privileged elevation) and automate the response. Single playbook in your SOAR or equivalent. Demonstrates the pattern and earns budget for the next ten.
Pillar 8: Governance (cross-cutting)
What this pillar covers: Policy ownership, exception management, change advisory, evidence flow into audit. The accountability layer that keeps the program running between executive reviews.
Where most clients actually are: Governance is the second-most-frequent stall point we see after measurement. The program runs, but there’s no formal cadence for reviewing policy effectiveness, retiring policies that no longer fit, or capturing evidence for the next audit. Programs without governance drift.
The day-zero move: Establish the Zero Trust steering committee in the first 30 days. Monthly cadence, four to six standing items, decision log. The day-zero move is the calendar invite, not the artifact.
Where we disagree with the standard advice
Most Zero Trust content treats the eight pillars as eight workstreams to be implemented in parallel over a year. We think that approach produces eight half-finished programs. We sequence the work in three windows: identity-first foundation in the first 30 days, decision and architecture commitment in days 30 to 60, and quick-win execution in days 60 to 90. The other pillars get scoped in this window but the deep build runs across the next twelve to fifteen months. Trying to do all eight in 90 days is the most common cause of programs that stall in year two.
The 90-Day Roadmap in Three Phases
This is the cadence we run in Stage 1 to Stage 3 of a Zero Trust engagement. Three phases of roughly thirty days each. Each phase has a single primary focus and produces concrete deliverables that the next phase builds on.
Phase 1: Discovery and Identity Foundation
Window: Days 1 to 30
Focus: Document the current state across all eight pillars at a maturity-baseline level. Land the identity quick wins (block legacy authentication, enforce MFA universally on human users, push admins to phishing-resistant factors). Establish the Zero Trust steering committee.
Deliverables at end of phase: Maturity scorecard across the 8 pillars, identity quick-win evidence, steering committee charter and first meeting minutes.
Phase 2: Architecture and Decisions
Window: Days 30 to 60
Focus: Land the architecture decisions that constrain the next eighteen months. Identity platform consolidation (Entra ID or Okta primary, see our companion blog for the framework). Conditional access policy architecture. Telemetry consolidation pattern. Governance cadence locked.
Deliverables at end of phase: Architecture decision documents (ADRs) with named owners, target-state diagrams across pillars, governance cadence operational.
Phase 3: Quick Wins and Roadmap Commitment
Window: Days 60 to 90
Focus: Execute two or three additional quick wins that compound off Phase 1 (typically: device compliance signals into conditional access for high-risk apps, automation of one alert category, customer-managed keys on top sensitive data stores). Commit the eighteen-month roadmap for board approval.
Deliverables at end of phase: Quick-win evidence pack, baseline metric report (the KPIs the program will track going forward), eighteen-month roadmap document with budget.
How This Plays Out in Practice
The AEC client I mentioned at the top of this article. 2,000 people. Board asked for Zero Trust by year-end. Twelve months. We pushed back hard. The CISO appreciated the honesty more than the eager-to-please answer would have earned.
We agreed on a ninety-day plan with two visible quick wins (legacy authentication blocked in week three, conditional access policies tightened for high-risk apps in week eight) plus a maturity scorecard, an architecture decision document, and an eighteen-month roadmap. The board got the ninety-day update and reset their expectations from “done by year-end” to “two-thirds done by month eighteen.”
Eighteen months later they were two-thirds done. The remaining third was scoped honestly for year three, and the CISO told us later that the most valuable thing we’d done in week one was push back on the unrealistic timeline. Programs sold as fast generally fail slowly.
Recommended Reading:
If You’re Starting Zero Trust in Cloud This Quarter
Three principles we’d apply to your first 90 days regardless of vertical or scale. First, lead with identity. Every Zero Trust framework agrees on this and so do our engagements. Second, sequence the work; trying to do all eight pillars in parallel produces eight half-built programs. Third, set realistic expectations with the board; the cost of an over-promised timeline is measured in year-two credibility loss, not just delivery slip.
Our cloud security practice engineers the foundation that makes the rest possible: landing zone, identity, conditional access, telemetry, governance. Detection and response operations are co-delivered with established SOC partners. The platform engineering and the operating model around it are in-house at BluEnt.
For the full cloud security practice, see our Cloud Security Services page. For the identity foundation Zero Trust depends on, see our Identity and Access Management page. For the landing zone context behind Pillar 3, our AWS, Azure, and Google Cloud Landing Zone comparison sits alongside this article.
The 5 Identity Decisions a CISO Makes in the First 90 Days 
How to Build a SOC 2 Compliant Identity and Access Management Program 
AWS, Azure, and Google Cloud Landing Zone Security: A Side-by-Side Comparison 
Entra ID vs Okta: A Practical Decision Framework for Enterprise IT Leaders 
