Zero trust programmes fail when they are bought as a product or run as a list of disconnected projects, with no agreed baseline, no pillar owners and no way to show the board what has changed. This template gives you a roadmap document you can complete and take to a steering committee: scope, the reference model, governance, a pillar-by-pillar baseline and target, four phases with milestones and exit criteria, metrics, exceptions and review. It uses the five pillars and three cross-cutting capabilities of the CISA Zero Trust Maturity Model so that progress can be scored, and it applies equally to organisations aligning to NIST SP 800-207 or the NCSC design principles. Replace the bracketed text and treat the example milestones as a starting point. For how the maturity stages work, see the Zero Trust Maturity Model Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [Programme sponsor] and [Quarter], with your own names and dates.
- Complete Section 4 (baseline) before Sections 6 to 9. Phases are only meaningful against a measured starting point and evidence, not opinion.
- Every milestone needs an owner, a target quarter and an exit criterion that someone outside the delivery team can verify.
- "Must" marks commitments the steering committee is asked to approve; "should" marks recommended practice that can be deferred with a recorded reason in Section 11.
- Keep non-human identities (service accounts, API keys, workload identities, AI agents) in the Identity pillar from the start. They usually outnumber people and are the identities least likely to have MFA or an owner.
- If you run OT or a hybrid Active Directory forest, add the extra milestones referenced in Sections 7 and 8 rather than writing separate roadmaps.
1. Purpose and scope
This roadmap sets out how [Organisation] will move from its current security architecture to a zero trust architecture over [Start quarter] to [End quarter]. Zero trust here means that no user, device, workload or network location is trusted by default, and every access request is authenticated, authorised and evaluated against policy using identity, device and context signals.
- In scope: [workforce users, privileged users, non-human identities, managed and unmanaged devices, on-premises networks, cloud tenants, SaaS applications, data stores, OT sites if applicable].
- Out of scope: [for example customer identity platforms, which follow a separate roadmap]. Interfaces are recorded in Section 11.
- Drivers: [for example regulatory or contractual requirement, a recent incident, cloud migration, cyber insurance conditions, customer due diligence].
2. Reference model and principles
[Organisation] adopts the CISA Zero Trust Maturity Model as its scoring model, with maturity stages Traditional, Initial, Advanced and Optimal, applied to five pillars (Identity, Devices, Networks, Applications and Workloads, Data) and three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance). Architecture decisions follow NIST SP 800-207, Zero Trust Architecture. [If applicable: defence suppliers also map to the Department of War Zero Trust capabilities; UK public sector teams also apply the NCSC zero trust architecture design principles.]
Design principles that every project in this roadmap must follow:
- Know the architecture first: users, devices, services and data are inventoried before policy is enforced on them.
- Authenticate and authorise every request, including internal and service-to-service requests.
- Use phishing-resistant authentication for privileged and remote access.
- Use policy to grant the least privilege needed, for the shortest time needed.
- Do not trust any network, including the internal network.
- Monitor users, devices and services, and feed what is learned back into policy.
3. Governance and roles
| Role | Named person | Responsibilities |
|---|---|---|
| Programme sponsor | [Name, title] | Owns outcomes, chairs the steering committee, secures funding |
| Programme lead | [Name] | Runs the roadmap, reports progress, manages dependencies, risks and exceptions |
| Zero trust architect | [Name] | Target architecture, policy model, design authority for all projects |
| Pillar owners | [Identity: Name] [Devices: Name] [Networks: Name] [Applications and Workloads: Name] [Data: Name] | Baseline, target and milestone delivery for one pillar each |
| Security operations lead | [Name] | Visibility and Analytics: log coverage, detections, response playbooks |
| Business representatives | [Names per function] | Approve changes that affect users, accept residual risk for their services |
| Risk and audit | [Name] | Independent confirmation of exit criteria |
The steering committee meets [monthly] and approves phase gates, exceptions above [risk rating] and changes to scope.
4. Baseline assessment
Score each pillar and cross-cutting capability against the CISA stages, with evidence. Use the CISA Zero Trust Maturity Model Guide for the functions to score within each pillar.
| Pillar or capability | Current stage | Evidence | Target stage by [End quarter] | Owner |
|---|---|---|---|---|
| Identity | [Traditional / Initial / Advanced / Optimal] | [for example MFA coverage report, privileged account inventory, NHI inventory] | [Advanced] | [Name] |
| Devices | [ ] | [device inventory, compliance reports] | [ ] | [Name] |
| Networks | [ ] | [segmentation diagrams, remote access paths, encryption of internal traffic] | [ ] | [Name] |
| Applications and Workloads | [ ] | [application inventory, SSO coverage, workload identity use] | [ ] | [Name] |
| Data | [ ] | [data inventory and classification, encryption, access logging] | [ ] | [Name] |
| Visibility and Analytics | [ ] | [log source coverage map] | [ ] | [Name] |
| Automation and Orchestration | [ ] | [automated responses, policy as code] | [ ] | [Name] |
| Governance | [ ] | [policies, exception register, roles] | [ ] | [Name] |
Also record the top five attack paths identified in the baseline (for example, VPN without MFA to flat internal network, shared admin accounts, long-lived cloud keys). Each phase must close at least one of them.
5. Target state
By [End quarter], [Organisation] will be able to show that:
- Identity: all workforce and privileged access uses a central identity provider with phishing-resistant MFA; privileged roles are just-in-time; every non-human identity has an owner and no static credential older than [N] days. See the Phishing-Resistant MFA Guide.
- Devices: access decisions include device compliance; unmanaged devices reach only [browser-isolated or low-risk] resources.
- Networks: no flat internal network; remote access is application-level, not network-level; east-west traffic between critical zones is deny by default. See the ZTNA Guide.
- Applications and Workloads: all applications behind SSO and policy; workloads authenticate with short-lived workload identity rather than shared secrets.
- Data: critical data is inventoried, classified and protected with access logging. See the Zero Trust Data Pillar Guide.
- Cross-cutting: telemetry from every pillar reaches the SOC; high-confidence responses are automated; exceptions are time-bound.
6. Phase 0: Mobilise and discover ([Quarter] to [Quarter], about 3 months)
| Milestone | Owner | Exit criterion |
|---|---|---|
| Programme charter, governance and pillar owners approved | [Sponsor] | Signed charter; first steering committee held |
| Inventories of users, privileged accounts, non-human identities, devices, applications and critical data stores | [Pillar owners] | Inventories reconciled against at least two sources each |
| Critical services ("protect surfaces") and their data flows mapped | [Architect] | Top [10] services documented with dependencies |
| Baseline scoring (Section 4) and top attack paths agreed | [Programme lead] | Baseline signed off by risk |
| Exception and risk acceptance process in place | [Risk] | Register live; see the Security Exceptions and Risk Acceptance Guide |
7. Phase 1: Foundations ([Quarter] to [Quarter], about 9 months)
| Pillar | Milestone | Exit criterion |
|---|---|---|
| Identity | Phishing-resistant MFA for administrators and remote access; legacy authentication blocked; emergency access accounts defined | 100% of privileged and remote sign-ins use phishing-resistant methods |
| Identity | Privileged access separated: dedicated admin accounts, just-in-time roles, privileged access workstations for the highest tier | No standing global admin assignments outside emergency accounts |
| Identity (NHI) | Owners assigned to service accounts and API keys; highest-risk secrets moved to a vault | [90]% of NHIs have a named owner |
| Devices | Device inventory feeds access policy; compliance required for privileged access | Policy in enforce mode for privileged users |
| Networks | Remote access moved to an identity-aware broker for [first applications]; internet-exposed management interfaces removed | No management interfaces reachable from the internet |
| Visibility | Identity provider, broker, endpoint and cloud control plane logs in the SIEM | Log source coverage map complete for Phase 1 systems |
| [Hybrid AD] | Tier 0 defined, cloud admins cloud-only, Entra Connect hardened as Tier 0. See the Zero Trust in Hybrid Active Directory Environments guide. | No synchronised accounts in privileged cloud roles |
Every enforcement change in this phase runs in report-only or audit mode first, then a pilot group (IT staff), then a business unit, then everyone, with the previous policy kept for immediate rollback.
8. Phase 2: Expansion ([Quarter] to [Quarter], about 12 months)
| Pillar | Milestone | Exit criterion |
|---|---|---|
| Identity | Phishing-resistant MFA for all workforce users; risk-based Conditional Access | [95]% of workforce sign-ins phishing-resistant |
| Identity (NHI) | Workload identity federation replaces static cloud keys for CI/CD and cloud workloads | Static cloud keys reduced by [80]% |
| Devices | Compliance required for all access to sensitive applications | Unmanaged device access limited to approved resources |
| Networks | Macro segmentation of data centre and cloud networks; VPN retired for [named user groups]. See the Zero Trust Network Segmentation Playbook for Flat Networks. | Deny by default between critical zones |
| Applications | All internal applications behind SSO and policy | [100]% of applications in the inventory federated |
| Data | Classification of critical data; access logging on critical stores | Critical stores classified and logged |
| [OT] | Brokered vendor access and IT/OT DMZ. See the Zero Trust for OT and ICS Guide. | No direct inbound paths to OT |
9. Phase 3: Optimisation ([Quarter] onwards)
- Continuous evaluation: session re-evaluation on risk change for sensitive applications.
- Microsegmentation: workload-level policy for the most critical services, enforced after a monitor period.
- Automation: automated containment for high-confidence detections (for example revoking sessions and disabling accounts on confirmed token theft).
- Data-centric controls: policy decisions that use data classification as an input.
- Re-score: repeat the Section 4 baseline and agree the next target stages.
10. Metrics and reporting
| Metric | Baseline | Target | Reported to |
|---|---|---|---|
| Pillars at or above target stage | [n of 8] | [8 of 8] | Board, quarterly |
| Privileged and remote sign-ins using phishing-resistant MFA | [ ]% | 100% | Steering committee, monthly |
| Non-human identities with an owner and no static credential older than [N] days | [ ]% | [ ]% | Steering committee, monthly |
| Applications reachable only through identity-aware access | [ ]% | [ ]% | Steering committee, monthly |
| Baseline attack paths closed | [0 of 5] | [5 of 5] | Board, quarterly |
| Open exceptions past expiry | [ ] | 0 | Risk committee, monthly |
11. Dependencies, risks and exceptions
- Dependencies: [identity provider licensing, device management coverage, network refresh, application owners' availability, OT outage windows].
- Risks: [user disruption, legacy applications that cannot use modern authentication, skills, vendor lock-in, budget]. Each risk has an owner and mitigation.
- Exceptions: any system that cannot meet a milestone is recorded with the reason, compensating controls, owner and expiry date not more than [12] months away.
- Funding: [capital and operating costs by phase; savings from retired VPN, MFA tokens or legacy tools].
12. Review and change control
The programme lead reviews this roadmap every [quarter] with pillar owners. Changes to scope, target stages or phase dates are approved by the steering committee and recorded in the version history below.
| Version | Date | Change | Approved by |
|---|---|---|---|
| [1.0] | [Date] | [Initial roadmap] | [Name] |
Implementation guidance
- Start with identity and remote access: they close the most common initial access paths and produce the signals every later pillar depends on. NIST SP 1800-35, the NCCoE's final practice guide with 19 example implementations, is a useful source of tested build patterns. See the NIST SP 1800-35 Implementing a Zero Trust Architecture Guide.
- Use an existing planning method: NIST CSWP 20 shows how the NIST Risk Management Framework can be applied when developing and implementing a zero trust architecture, which avoids building a parallel governance process.
- Choose protect surfaces, not technologies: phase the roadmap by the services that matter most, then apply all pillars to each, rather than finishing one pillar everywhere before starting the next.
- Scale to your size: small organisations can compress Phases 0 to 2 into one year by relying on the controls built into their identity provider and SaaS platforms, while large organisations need pillar owners and a programme office.
- Report evidence, not activity: exit criteria confirmed by risk or audit carry more weight with a board than status colours. The Zero Trust Executive Briefing sets out what the board should ask.
- Learn from common mistakes: buying a product called zero trust, enforcing before inventory and leaving service accounts until last are the usual causes of stalled programmes. See Top 10 Zero Trust Mistakes.
Related NHI Mgmt Group resources: Zero Trust Maturity Model Guide · NIST SP 800-207 Zero Trust Architecture Guide · Identity Programme Roadmap Template · NCSC Zero Trust Architecture Design Principles Guide · NHI Programme Roadmap