Visit Website →
← Back to blog

Zero Trust Roadmap for IT Leaders: CISA Aligned Plan for Quarterly Wins

September 5, 2026
Zero Trust Roadmap for IT Leaders: CISA Aligned Plan for Quarterly Wins

Build your zero trust roadmap in three phases: identity and visibility foundations in Year 1, network and application segmentation across Years 2–3, and automated, analytics-driven enforcement by Years 4–5. Map every task to the five CISA pillars, Identity, Devices, Networks, Applications and workloads, and Data, plus the three cross-cutting capabilities of visibility, automation, and governance. Start wherever risk is highest and the fix is actually achievable this quarter.

TL;DR:

  • Prioritize pilots that address high-risk applications with immediate business benefits, like MFA enforcement or orphaned service account remediation, to gain quick wins.
  • Focus on incremental progress aligned with risk impact and feasibility at each phase, rather than attempting to implement all five pillars simultaneously.
  • Establish a cross-functional governance team and track multi-tiered metrics to demonstrate maturity growth and maintain leadership support.
  • Tailor legacy system protections with compensating controls, such as network isolation or jump boxes, until full modern authentication support is feasible.
  • Select initial project areas based on real risk and practical implementation speed to build credibility and secure ongoing stakeholder buy-in.

Table of Contents

Zero trust roadmap overview: what happens in each phase

A zero trust maturity model is not a product you buy. It's a multi-year commitment, and every credible zero trust implementation plan runs 3 to 5 years, split into three working phases.

  1. Year 1: Foundations. Inventory every identity, service account, and asset you own. Roll out multi-factor authentication broadly. Stand up basic logging so you can actually see what's happening on your network. This phase is unglamorous, and it's also where most of the real risk reduction happens.
  2. Years 2–3: Scale. Segment applications and networks so a compromised laptop in accounting can't reach the finance database. Integrate telemetry across identity, device, and network tools instead of leaving them in silos. Pilot automation for policy enforcement rather than manual ticket queues.
  3. Years 4–5: Optimise. Layer in advanced analytics that flag anomalous behaviour in real time. Move to dynamic, risk-based policy enforcement instead of static rules. Embed zero trust thinking into every new project, from mergers to cloud migrations, instead of treating it as a bolt-on.

The CISA zero trust maturity model frames this as a gradient, not a checklist, and recommends small, iterative advancements you can point to every budget cycle. That matters more than it sounds. A five-year plan with no visible progress at month eighteen loses its funding long before it loses its relevance.

How the zero trust framework maps to concrete actions

CISA's zero trust maturity model breaks the work into five pillars and three supporting capabilities. Here's what each one actually looks like on a project plan, not just in a slide deck.

  • Identity: Inventory every human and service account, then kill the orphaned ones nobody remembers creating. Enforce MFA across all privileged access first, then everyone else. Move toward just-in-time and adaptive access so permissions expire instead of accumulating forever.
  • Devices: Discover every endpoint touching your network, including the ones IT never provisioned. Add posture checks so a device with disabled antivirus can't reach sensitive systems. Set managed baselines for standard hardware and build compensating controls, network isolation, jump boxes, extra monitoring, for legacy endpoints that can't run modern agents.
  • Networks: Design a microsegmentation strategy instead of relying on one flat internal network where anything that gets past the firewall can go anywhere. Replace implicit trust assumptions ("it's inside our network, so it's fine") with explicit verification at every hop. Secure service-to-service traffic, not just user-facing logins.
  • Applications & workloads: Map which applications actually hold your crown jewels. Apply contextual access rules based on device health and location, not just a password. Add runtime protections that watch for abnormal behaviour inside the application itself, which our runtime application security guide covers in more depth.
  • Data: Classify what you actually have before you try to protect it. Encrypt data in transit and at rest as a baseline, not an aspiration. Govern who can access what, and audit that access on a schedule rather than after an incident forces the question.
  • Cross-cutting: Centralize telemetry so identity, device, and network signals feed one picture. Automate policy enforcement wherever a human clicking "approve" is the bottleneck. Stand up governance processes that survive staff turnover.

Pro Tip: Don't try to advance all five pillars at the same pace. Most organizations are advanced in identity and still traditional in data governance. That unevenness is normal, and forcing parity across pillars usually wastes budget better spent on the weakest one.

Which pillars should you tackle first?

Pick pilots using a simple rubric: risk impact times feasibility times business enablement. A fix that closes a serious exposure, can be shipped in a quarter, and speeds something the business already wants (faster partner onboarding, smoother audits) beats a technically elegant project that takes eighteen months and helps no one notice.

A few pilots consistently deliver in that window:

  • MFA enforcement on your highest-risk applications, the ones holding financial data or customer records.
  • Service account remediation, since orphaned or over-privileged service accounts are one of the quietest ways attackers move laterally.
  • Asset inventory paired with endpoint detection and response on your most critical servers.
  • Microsegmentation around one or two high-value services rather than the entire network at once.

Analyst guidance consistently warns against tool-first rollouts that chase features instead of outcomes. The organizations that keep executive support are the ones translating each pilot into a business KPI: fewer access-related incidents, faster new-hire provisioning, cleaner compliance audit findings. Stalled programs share a common root cause, and it's rarely technical. It's the loss of stakeholder buy-in once leadership stops seeing visible progress.

Governance and metrics: how do you prove maturity gains?

Set up a cross-functional steering group involving security, IT operations, application owners, compliance, with a named owner per pillar and regular meetings, such as monthly for mid-sized organizations. Without that structure, pillar owners drift back to their old priorities the moment budget season ends.

Track three tiers of metrics, not one giant dashboard nobody reads:

  • Strategic: business outcomes like reduced breach impact and faster partner or vendor onboarding time.
  • Operational: mean time to detect and respond, and the percentage of your environment where policy enforcement is actually active versus just documented.
  • Tactical: percentage of assets inventoried, MFA coverage across critical systems, and percentage of services microsegmented.

Benchmark each tier against the CISA ZTMM stages, Traditional, Initial, Advanced, Optimal, so your board sees a maturity trajectory instead of a pile of disconnected security metrics.

A practitioner's view on what actually works

Every zero trust roadmap experts help build starts by consolidating fragmented telemetry, because you can't govern what you can't see across separate identity, network, and endpoint tools. One pattern that produces fast, visible results: securing Tier 0 privileged access first, domain admins, backup credentials, the handful of accounts that can compromise everything else, before touching broader employee access.

The organizations that stall are almost never the ones with the hardest technical problems. They're the ones that tried to fix every pillar simultaneously and ran out of executive patience before any single pillar showed results. Plan for your legacy systems from day one, tie every pilot to a business metric someone in the boardroom cares about, and run pilots short enough that you can report a win before the next budget review.

— Nick - Sr. Executive

What are the zero trust maturity stages?

CISA's zero trust maturity model defines four stages, and understanding where you sit on each pillar is the entire point of doing an honest assessment before you write a roadmap.

Traditional is where most organizations start: manual configurations, static policies, and implicit trust baked into network design. If your internal network still treats "inside the firewall" as synonymous with "safe," you're here.

Initial introduces some automation and risk-based decisions, but coverage is inconsistent. You might have MFA on your email but not on your file shares. Cross-pillar coordination is minimal, and policies still change on a manual schedule rather than in response to real-time risk.

Advanced brings centralized visibility and policy enforcement across most of the environment, with some cross-pillar coordination and automated response to known threats. This is a realistic multi-year target for most mid-sized organizations, not a stretch goal.

Optimal means fully automated policy enforcement, dynamic and continuous risk assessment, and interoperability across every pillar. Very few organizations sit here uniformly, and honestly, few need to. The SEI research on zero trust journeys notes that maturity varies by pillar even within the same organization, which means your assessment should score each pillar separately, not hand out one overall grade that hides where the real gaps are.

How do you integrate zero trust with legacy systems?

Almost nobody builds a zero trust architecture on a blank slate. You're layering it onto VPNs, on-premise Active Directory, and applications that were never designed for continuous verification, and that reality shapes every decision.

Start with discovery, not remediation. You need an honest inventory of which systems support modern authentication protocols and which ones simply can't, before you commit to a rollout timeline. For legacy infrastructure that can't run a modern agent or accept SAML-based single sign-on, plan compensating controls: network isolation, jump boxes, enhanced logging, and stricter network access rules that limit blast radius even without native support.

NIST's implementation examples document practical patterns for this, including microsegmentation approaches that work at the host or agent level when full network re-architecture isn't realistic, and software-defined perimeter or SASE approaches that tend to fit cloud-native services and remote access more cleanly. Choosing between them isn't about which is "better." It's about which fits the specific system you're trying to protect without a multi-year rebuild.

Don't underestimate integration work with your existing SIEM and identity providers, either. A zero trust rollout that creates a second, disconnected logging system defeats the visibility goal the whole architecture is built around. Budget explicitly for connector work and API integration, because that line item gets cut first when it's treated as optional.

How do you integrate zero trust with legacy systems? — overview diagram

Who owns what in a zero trust rollout?

A zero trust strategy fails fastest when everyone assumes someone else owns it. Clear roles up front prevent the finger pointing that happens six months in in when a pilot stalls.

The CISO or security leader owns the overall roadmap and risk prioritization, deciding which pillar gets attention first based on exposure. IT operations owns the actual implementation work, deploying MFA, configuring segmentation, patching legacy compensating controls. Application owners have to sign off on contextual access rules for their systems, because they understand the business logic better than security ever will. Compliance and legal weigh in on data classification and access governance, particularly anywhere regulated data is involved.

Executive sponsorship deserves its own line, not just a mention. Without a named executive who reviews progress and defends the budget at renewal time, zero trust programs stall regardless of how sound the technical plan is. That sponsor doesn't need to understand microsegmentation. They need to understand why access incidents dropped and be willing to say so in front of the board.

Smaller organizations without a dedicated security team often distribute these roles across a general IT manager and an external partner, which works, provided the roles are still explicit rather than assumed. Our playbook for reducing cyber risk without an in-house IT team covers how that split typically works in practice.

How do you get staff to actually adopt zero trust?

Technical rollout and organizational adoption are two different problems, and treating them as one is where a lot of otherwise sound roadmaps go sideways. Employees who've spent a decade using a single password to access everything will resist MFA prompts and adaptive access checks unless they understand why the friction exists.

Start change management before the first policy goes live, not after the help desk starts drowning in tickets. Explain the specific risk being addressed in language that connects to something employees already worry about, credential theft, phishing, a vendor breach they read about, rather than abstract "compliance requirements." A short, role-specific training session beats a company-wide email nobody opens.

Give a heads up before the change, run the actual technical piece as a phased rollout by department rather than all at once, and staff your help desk for a spike in access requests during the first two weeks after each rollout. That spike is temporary. Companies that skip that planning consistently underestimate how loud the pushback gets, and pushback loud enough reaches an executive sponsor's inbox is how progress reports turn into project cancellations.

Building digital trust internally works the same way it does with customers: consistency and clear communication earn cooperation faster than mandates do. Treat every phase rollout as a communication project with a technical component attached, not the other way around.

How much should you budget for each phase?

Year 1 costs the most relative to the risk it removes, because you're buying MFA licensing, logging infrastructure, and the inventory and discovery work that everything else depends on. Most of that spend is licensing and internal labour rather than large capital projects, which makes it easier to justify inside an existing security budget without a special funding request.

Years 2–3 shift spend toward segmentation tooling, telemetry integration, and the staff time needed to redesign network architecture around application boundaries instead of a flat internal network. This phase tends to run longer than planned if legacy systems weren't properly inventoried in Year 1, so build contingency into the timeline as much as the budget.

Years 4–5 spend goes toward analytics platforms and automation tooling, but the absolute dollar figure often drops because you're optimizing systems you already built rather than standing up new ones from scratch. Budget for staff training here too. Analytics-driven policy enforcement needs people who can interpret what the system flags, not just people who can deploy it.

Resource planning across all three phases benefits from the same rule: distribute cost as minor, iterative advancements tied to specific budget cycles rather than requesting one enormous multi-year allocation up front. Finance departments approve a $150,000 pilot with a clear KPI far more easily than they approve a five-year, seven-figure security transformation with no interim checkpoints.

How much should you budget for each phase? — overview diagram

The gap between the zero trust pitch and the zero trust reality

Most zero trust content oversells the destination and undersells the discipline it takes to get there. The pitch is "never trust, always verify." The reality is a five-year project management exercise disguised as a security initiative, and organizations that treat it purely as a technical build consistently underperform the ones that treat it as a change program with security requirements attached.

The conventional advice tells you to start with a maturity assessment, which is correct but incomplete. The assessment tells you where you are. It doesn't tell you where to start, and that's the decision most roadmaps get wrong. Teams gravitate toward the pillar where the technology is most mature, usually identity, because MFA rollouts are well understood and vendors sell them aggressively. That's not always where the risk actually sits.

If there's one thing the research and the implementation pattern both point to, it's this: pick your first pilot based on where risk and feasibility genuinely intersect, not where the tooling is easiest to buy. A modest, well-communicated win in a less glamorous pillar, data governance, service account cleanup, builds more executive trust than a flashy identity rollout that nobody outside IT notices.

How AccountNext-Nexus helps you execute a zero trust roadmap

There are alternatives to juggling separate vendors for identity, network, and compliance work: one team runs your zero trust roadmap under a single contract, with 24/7 real-time threat detection and monitoring often built into the engagement instead of billed as separate add-ons later.

AccountNext-Nexus

If you're not sure where your organization actually sits against the CISA maturity stages, a posture assessment is the sensible starting point, it tells you which pillar carries the most risk before you spend a dollar on tooling. From there, most clients run a focused pilot, MFA on high-risk applications, or service account cleanup, before committing to a full multi-year engagement. Some providers handle the technical build, the compliance mapping for standards like SOC 2 and HIPAA, and the ongoing monitoring, aiming for transparent pricing so budget conversations with finance teams don't turn into guesswork every renewal cycle.

Ready to see where your organization stands? Explore Nexus's IT and cybersecurity services and book a posture assessment to get your first-phase roadmap started.

Where to go for the technical detail this article didn't cover

Sources