# Zero Trust Architecture Plan: [Organisation or programme name]

> Plan for moving an organisation from perimeter-based security to a zero
> trust architecture (ZTA): principles, logical components, deployment
> approach, current state and maturity assessment, target state, roadmap by
> pillar, metrics and risks. Based on NIST SP 800-207 *Zero Trust
> Architecture* (August 2020) for tenets, logical components, deployment
> approaches and migration steps; the CISA *Zero Trust Maturity Model*
> Version 2.0 (April 2023) for pillars, cross-cutting capabilities and
> maturity stages; and NIST SP 1800-35 *Implementing a Zero Trust
> Architecture* (final, June 2025) for example builds. Replace every
> `[bracketed]` value and every row marked *Example*. Worked examples use a
> mid-sized company with on-premises applications, two cloud providers and a
> remote workforce.

<!--
Guidance: How to use this template
- Zero trust is a set of principles applied over years, not a product.
  Write the plan around protected resources and access decisions, not around
  tools you intend to buy.
- Work in this order: scope and protect surfaces (1), current state (5),
  target state (6), then the roadmap (7). A roadmap written before the
  current state assessment usually funds the wrong pillar first.
- Score maturity honestly per function (5.3). Most organisations are
  Traditional or Initial in several functions; that is the baseline, not a
  failure.
- Plan for a long hybrid period. NIST SP 800-207 section 7 expects
  perimeter-based and zero trust controls to coexist during migration.
-->

## Document control

<!-- Guidance: Identify the programme, its sponsor and the people who accept the risk of the transition. -->

| Field | Value |
|---|---|
| Document ID | [ZTA-PLAN-001] |
| Programme | [Zero trust programme name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@security-architect] |
| Executive sponsor | [@ciso] |
| Approvers / reviewers | [@cio], [@infrastructure-lead], [@identity-lead], [@app-platform-lead] |
| Last updated | YYYY-MM-DD |
| Classification | Confidential |
| Planning horizon | [YYYY to YYYY] |
| Next review | YYYY-MM-DD (at least annually and after each roadmap phase) |
| Related | [Security architecture], [Risk register], [Asset inventory], [Identity strategy] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief information security officer | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Chief information officer | [@name] | [Decision] | YYYY-MM-DD |
| Head of infrastructure and network | [@name] | [Decision] | YYYY-MM-DD |
| Head of identity and access management | [@name] | [Decision] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to scope, maturity scores, target state and roadmap phases. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft after current state workshops |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Maturity scores reviewed with pillar owners; roadmap phase 1 agreed |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by steering committee |

## Contents

<!-- Guidance: Keep aligned with the headings. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [Zero trust tenets](#2-zero-trust-tenets)
3. [Logical architecture](#3-logical-architecture)
4. [Deployment approach](#4-deployment-approach)
5. [Current state assessment](#5-current-state-assessment)
6. [Target state](#6-target-state)
7. [Roadmap by pillar](#7-roadmap-by-pillar)
8. [Access policy and trust algorithm](#8-access-policy-and-trust-algorithm)
9. [Reference implementations and example builds](#9-reference-implementations-and-example-builds)
10. [Governance and operating model](#10-governance-and-operating-model)
11. [Metrics](#11-metrics)
12. [Risks](#12-risks)
13. [Traceability](#13-traceability)
14. [Glossary and references](#14-glossary-and-references)

## 1. Introduction and scope

<!-- Guidance: Say why the organisation is adopting zero trust now, which resources are in scope first, and what success looks like in business terms. -->

### 1.1 Drivers

[*Example:* A phishing incident last year gave an attacker VPN access and
from there flat network access to file servers and a finance application.
Half the workforce is remote, 60% of business applications run in two
public clouds, and contractors use personal devices. Cyber insurance renewal
requires phishing-resistant multi-factor authentication for all staff.]

### 1.2 Objectives

| ID | Objective | Measure |
|---|---|---|
| OBJ-01 | *Example:* Remove implicit trust based on network location | No application reachable only because a user is on the corporate network or VPN |
| OBJ-02 | *Example:* Phishing-resistant authentication for all workforce identities | Share of users enrolled in FIDO2 or smart card authentication |
| OBJ-03 | *Example:* Per-session, least-privilege access to high-value resources | High-value applications behind a policy enforcement point with device posture checks |
| OBJ-04 | *Example:* Limit lateral movement | East-west traffic between segments denied by default |
| OBJ-05 | *Example:* Visibility for every access decision | Access decisions logged centrally and correlated |
| [OBJ-nn] | [Objective] | [Measure] |

### 1.3 Scope and protect surfaces

List the resources to protect first. Start with a small number of high-value
resources where a breach would cause the most harm.

| ID | Resource or protect surface | Data sensitivity | Users | Hosting | Priority |
|---|---|---|---|---|---|
| RES-01 | *Example:* Finance and payroll application | Restricted | 120 staff | On premises | 1 |
| RES-02 | *Example:* Customer database and admin console | Restricted | 40 engineers, 300 support staff | Cloud A | 1 |
| RES-03 | *Example:* Source code and CI/CD | Confidential | 400 engineers, contractors | SaaS and cloud B | 2 |
| RES-04 | *Example:* Collaboration suite | Internal | All staff | SaaS | 2 |
| RES-05 | *Example:* Building management and printers (legacy devices) | Internal | Facilities | On premises | 3 |
| [RES-nn] | [Resource] | [Class] | [Users] | [Hosting] | [1 / 2 / 3] |

Out of scope for this plan: [*Example:* operational technology in
manufacturing sites, handled by a separate programme].

## 2. Zero trust tenets

<!-- Guidance: Restate the NIST SP 800-207 tenets in your own terms and say what each means for this organisation. Reviewers use this section to check that roadmap items serve a principle. -->

NIST SP 800-207 section 2.1 sets out seven basic tenets as an ideal goal,
noting that not every tenet may be fully achievable for every strategy. The
paraphrases below are original summaries; read the publication for the full
wording.

| ID | Tenet (paraphrase of SP 800-207 section 2.1) | What it means here |
|---|---|---|
| T-1 | All data sources and computing services are treated as resources | *Example:* SaaS tenants, cloud workloads and APIs are inventoried and governed like on-premises servers |
| T-2 | Communication is secured whatever the network location; being on the internal network grants no trust | *Example:* Internal traffic to RES-01 and RES-02 is encrypted and authenticated like internet traffic |
| T-3 | Access to each resource is granted per session | *Example:* Authorisation to one application does not grant access to another; sessions are re-evaluated |
| T-4 | Access is decided by dynamic policy using the state of identity, application or service, and requesting asset, plus behavioural and environmental attributes | *Example:* Device compliance, user risk and location feed every decision for priority 1 resources |
| T-5 | The enterprise monitors and measures the integrity and security posture of all owned and associated assets | *Example:* Endpoint posture is continuously reported; unmanaged devices get restricted access |
| T-6 | Authentication and authorisation are dynamic and strictly enforced before access is allowed | *Example:* Continuous evaluation and re-authentication on risk change |
| T-7 | The enterprise collects as much information as possible about the current state of assets, network and communications and uses it to improve its security posture | *Example:* Access logs, flow logs and endpoint telemetry flow to analytics that tune policy |

## 3. Logical architecture

<!-- Guidance: Show the control plane and data plane components defined in SP 800-207 section 3 and name the product or service that plays each role. One component can be several products. -->

SP 800-207 separates a control plane, where access decisions are made, from
a data plane, where application traffic flows through enforcement points.

```mermaid
flowchart LR
  subject([Subject: user or workload on a device]) --> pep[Policy enforcement point]
  pep --> resource[(Enterprise resource)]
  subgraph cp["Control plane"]
    pe[Policy engine] --> pa[Policy administrator]
  end
  pa <-->|configure and signal| pep
  subgraph ds["Policy inputs and data sources"]
    cdm[Continuous diagnostics and mitigation, device posture]
    idm[Identity management]
    pki[Enterprise PKI]
    ti[Threat intelligence]
    logs[Network and system activity logs]
    siem[SIEM]
    dap[Data access policies]
    comp[Industry compliance requirements]
  end
  ds --> pe
```

| Component (SP 800-207) | Role | Our implementation | Owner |
|---|---|---|---|
| Policy engine (PE) | Decides whether to grant, deny or revoke access to a resource, using policy and inputs | *Example:* Identity provider conditional access plus access proxy policy service | [@team] |
| Policy administrator (PA) | Establishes or shuts down the session path between subject and resource by instructing the PEP | *Example:* Access proxy control plane; issues session tokens | [@team] |
| Policy enforcement point (PEP) | Enables, monitors and terminates connections between subject and resource | *Example:* Identity-aware proxy for web apps; service mesh sidecars for workloads | [@team] |
| Policy decision point (PDP) | The PE and PA together | *Example:* As above | [@team] |
| Data sources | Inputs to the PE: diagnostics, compliance, threat intelligence, logs, data access policy, PKI, identity, SIEM | *Example:* EDR, MDM, IdP, CA, SIEM, data classification service | [@team] |

## 4. Deployment approach

<!-- Guidance: Choose the primary approach from SP 800-207 section 3.1 and the deployment models from section 3.2 for each resource type. Most organisations combine approaches. -->

### 4.1 Approaches (SP 800-207 section 3.1)

| Approach | Core idea | Fit here | Primary for |
|---|---|---|---|
| Enhanced identity governance (3.1.1) | Identity and assigned attributes of actors are the main input to access policy | *Example:* Strong fit: SaaS and web applications | RES-03, RES-04 |
| Micro-segmentation (3.1.2) | Place individual or groups of resources in their own segment protected by gateways or host firewalls | *Example:* Needed for data centre workloads and legacy servers | RES-01, RES-05 |
| Network infrastructure and software defined perimeters (3.1.3) | Use an overlay network where the PA acts as network controller and builds per-session paths | *Example:* Replaces the remote access VPN | RES-02 admin access |

### 4.2 Deployment models (SP 800-207 section 3.2)

| Model | Description (paraphrase) | Use for |
|---|---|---|
| Device agent and gateway (3.2.1) | An agent on the device and a gateway in front of the resource communicate with the PA | *Example:* Managed laptops to internal apps |
| Enclave-based (3.2.2) | A gateway protects a group of resources (an enclave) rather than each one | *Example:* Legacy finance servers that cannot host agents |
| Resource portal (3.2.3) | A portal acts as gateway for subjects without an agent | *Example:* Contractors on unmanaged devices, browser-only |
| Device application sandboxing (3.2.4) | Approved applications run in isolated compartments on the device | *Example:* Not planned in the first phases |

## 5. Current state assessment

<!-- Guidance: Follow the discovery steps of SP 800-207 section 7.3 (actors, assets, processes) and then score the CISA ZTMM functions. Evidence, not opinion: link each score to what was observed. -->

### 5.1 Actors, assets and processes

| Step (SP 800-207 7.3) | Finding | Evidence |
|---|---|---|
| Identify actors (7.3.1) | *Example:* 2 400 employees, 350 contractors, 900 service accounts, 40 shared admin accounts | IdP and directory export |
| Identify assets (7.3.2) | *Example:* 3 100 managed laptops, unknown share of personal devices, 1 800 cloud workloads, 60 SaaS applications | MDM, CMDB, cloud inventory |
| Identify key processes and risks (7.3.3) | *Example:* Payroll run, customer support, software release; highest risk from support access to customer data | Business impact analysis |

### 5.2 Maturity stages (CISA ZTMM 2.0)

The ZTMM describes a journey from a **Traditional** starting point through
**Initial** and **Advanced** to **Optimal**, each stage needing more
automation, integration and granularity. Summarise each stage in your own
words for assessors, for example:

| Stage | Short description used in this assessment |
|---|---|
| Traditional | Manual, static configuration; siloed policies; perimeter-based trust |
| Initial | First automation and cross-pillar integration; some policies based on attributes |
| Advanced | Automated, centrally managed, integrated across pillars; context-based decisions where feasible |
| Optimal | Fully automated, dynamic, just-in-time policies with continuous monitoring across pillars |

### 5.3 Maturity scores by pillar and function

The ZTMM 2.0 has five pillars (Identity, Devices, Networks, Applications and
Workloads, Data) and three cross-cutting capabilities (Visibility and
Analytics, Automation and Orchestration, Governance). The function names
below are those of ZTMM 2.0; check the model for the criteria of each stage.

| Pillar | Function | Current stage | Evidence | Target stage |
|---|---|---|---|---|
| Identity | Authentication | *Example:* Initial (MFA, not phishing-resistant) | IdP policy report | Advanced |
| Identity | Identity Stores | *Example:* Traditional (3 directories, manual sync) | Directory inventory | Advanced |
| Identity | Risk Assessments | *Example:* Traditional | No user risk signals | Initial |
| Identity | Access Management | *Example:* Initial (standing admin rights) | Privileged account review | Advanced |
| Devices | Policy Enforcement and Compliance Monitoring | *Example:* Initial | MDM compliance 72% | Advanced |
| Devices | Asset and Supply Chain Risk Management | *Example:* Traditional | CMDB gaps | Initial |
| Devices | Resource Access | *Example:* Traditional (no posture in access decisions) | IdP configuration | Advanced |
| Devices | Device Threat Protection | *Example:* Advanced (EDR on 98% of laptops) | EDR console | Advanced |
| Networks | Network Segmentation | *Example:* Traditional (flat office and data centre network) | Firewall rules review | Advanced |
| Networks | Network Traffic Management | *Example:* Traditional | Static rules | Initial |
| Networks | Traffic Encryption | *Example:* Initial (internal HTTP in places) | Scan results | Advanced |
| Networks | Network Resilience | *Example:* Initial | Architecture review | Initial |
| Applications and Workloads | Application Access | *Example:* Initial (VPN then app login) | Access paths | Advanced |
| Applications and Workloads | Application Threat Protections | *Example:* Initial | WAF on public apps only | Advanced |
| Applications and Workloads | Accessible Applications | *Example:* Traditional (internal apps reachable only via VPN) | App inventory | Advanced |
| Applications and Workloads | Secure Application Development and Deployment Workflow | *Example:* Initial | CI/CD review | Advanced |
| Applications and Workloads | Application Security Testing | *Example:* Initial | SAST only | Advanced |
| Data | Data Inventory Management | *Example:* Traditional | No data catalogue | Initial |
| Data | Data Categorization | *Example:* Traditional | Policy exists, no labels | Initial |
| Data | Data Availability | *Example:* Initial | Backup reports | Initial |
| Data | Data Access | *Example:* Initial | Role-based, broad groups | Advanced |
| Data | Data Encryption | *Example:* Initial | At rest in cloud; gaps on premises | Advanced |
| Cross-cutting | Visibility and Analytics | *Example:* Initial | SIEM covers 40% of sources | Advanced |
| Cross-cutting | Automation and Orchestration | *Example:* Traditional | Manual provisioning | Initial |
| Cross-cutting | Governance | *Example:* Initial | Policies not enforced technically | Advanced |

## 6. Target state

<!-- Guidance: Describe the end state for the planning horizon per pillar, in concrete terms a tester could check. Targets need not all be Optimal; choose by risk and cost. -->

| Pillar | Target state at end of horizon (*Example*) |
|---|---|
| Identity | One authoritative identity store; phishing-resistant MFA for all workforce; just-in-time privileged access; user risk signals used in access policy |
| Devices | All devices accessing priority 1 resources are managed and compliant; posture checked at every session; unmanaged devices limited to browser access through a portal |
| Networks | Data centre segmented by application; remote access VPN retired; all internal traffic to priority 1 and 2 resources encrypted |
| Applications and Workloads | All internal web applications published through the identity-aware proxy; workload-to-workload calls authenticated with workload identities in the service mesh |
| Data | Data classified and labelled for priority 1 resources; access policies use classification; encryption at rest and in transit everywhere |
| Cross-cutting | All access decisions logged to the SIEM; automated deprovisioning; zero trust policies reviewed by a policy board |

Target logical view:

```mermaid
flowchart TB
  users([Employees and contractors]) --> idp[Identity provider with phishing-resistant MFA]
  devices([Managed and unmanaged devices]) --> posture[Device posture service]
  idp --> pe[Policy engine]
  posture --> pe
  siem[SIEM and analytics] --> pe
  pe --> pa[Policy administrator]
  pa --> proxy[Identity-aware proxy, web apps]
  pa --> mesh[Service mesh, workloads]
  pa --> seg[Segmentation gateways, legacy enclaves]
  proxy --> apps[(Internal and SaaS applications)]
  mesh --> svc[(Cloud workloads and APIs)]
  seg --> legacy[(Legacy servers and devices)]
  proxy --> siem
  mesh --> siem
  seg --> siem
```

## 7. Roadmap by pillar

<!-- Guidance: Sequence work by dependency and risk. Identity and device posture usually come first because every later policy depends on them. Give each item an ID, a pillar, an exit criterion and an owner. -->

### 7.1 Phases

| Phase | Theme | Duration | Exit criterion |
|---|---|---|---|
| P1 | *Example:* Foundations: identity consolidation, MFA, device inventory, logging | 6 months | All workforce on one IdP with MFA; 95% device inventory coverage |
| P2 | *Example:* First protect surfaces: RES-01 and RES-02 behind PEPs with posture checks | 6 months | No VPN-only access to RES-01 or RES-02 |
| P3 | *Example:* Segmentation and workload identity | 9 months | East-west deny by default in data centre; mesh for cloud A |
| P4 | *Example:* Data-centric controls and automation | 9 months | Classification-based access for priority 1 data; automated provisioning |

### 7.2 Roadmap items

| ID | Pillar | Item | Phase | Depends on | Exit criterion | Owner |
|---|---|---|---|---|---|---|
| ZT-ID-001 | Identity | *Example:* Consolidate three directories into one authoritative identity store | P1 | none | Single source for workforce identities | [@identity] |
| ZT-ID-002 | Identity | *Example:* Phishing-resistant MFA for administrators, then all staff | P1 to P2 | ZT-ID-001 | 100% admins, 95% staff | [@identity] |
| ZT-ID-003 | Identity | *Example:* Just-in-time privileged access; remove 40 shared admin accounts | P2 | ZT-ID-001 | No standing domain admin rights | [@identity] |
| ZT-DEV-001 | Devices | *Example:* Enrol all corporate devices in MDM; inventory personal devices that access email | P1 | none | 95% coverage | [@endpoint] |
| ZT-DEV-002 | Devices | *Example:* Device compliance as a condition for priority 1 access | P2 | ZT-DEV-001, ZT-ID-001 | Non-compliant devices denied or limited | [@endpoint] |
| ZT-NET-001 | Networks | *Example:* Replace remote access VPN with identity-aware proxy for web apps | P2 | ZT-ID-002 | VPN users below 5% | [@network] |
| ZT-NET-002 | Networks | *Example:* Segment data centre by application, deny east-west by default | P3 | ZT-VIS-001 | Flow logs show only allowed paths | [@network] |
| ZT-APP-001 | Applications and Workloads | *Example:* Publish internal web applications through the PEP | P2 | ZT-NET-001 | Priority 1 and 2 apps published | [@app-platform] |
| ZT-APP-002 | Applications and Workloads | *Example:* Workload identities and mutual TLS in cloud A service mesh | P3 | none | All service-to-service calls authenticated | [@app-platform] |
| ZT-DATA-001 | Data | *Example:* Classify and label data in RES-01 and RES-02 | P3 | none | Labels on 90% of records or files in scope | [@data-governance] |
| ZT-DATA-002 | Data | *Example:* Classification-aware access policy and data loss prevention | P4 | ZT-DATA-001 | Policy enforced in PEP | [@data-governance] |
| ZT-VIS-001 | Visibility and Analytics | *Example:* Send IdP, PEP, EDR and flow logs to the SIEM | P1 | none | 90% of sources onboarded | [@soc] |
| ZT-AUT-001 | Automation and Orchestration | *Example:* Automated joiner, mover, leaver provisioning from HR system | P4 | ZT-ID-001 | Deprovisioning within 1 hour | [@identity] |
| ZT-GOV-001 | Governance | *Example:* Zero trust policy board and policy-as-code review process | P1 | none | Monthly board; policies versioned | [@ciso] |
| [ZT-XXX-nnn] | [Pillar] | [Item] | [Phase] | [Depends on] | [Exit] | [@owner] |

### 7.3 Migration steps

Follow the incremental steps of SP 800-207 section 7.3 for each new protect
surface: identify actors (7.3.1), assets (7.3.2) and processes and risks
(7.3.3); formulate policies (7.3.4); identify candidate solutions (7.3.5);
deploy and monitor initially, often in observe-only mode (7.3.6); then
expand (7.3.7). Record each protect surface's progress in 13.

## 8. Access policy and trust algorithm

<!-- Guidance: Define how the policy engine decides. SP 800-207 section 3.3 calls this the trust algorithm and discusses criteria-based versus score-based and singular versus contextual variants. -->

### 8.1 Policy inputs

| Input | Source | Used for |
|---|---|---|
| Subject identity, group, role, authentication strength | IdP | All decisions |
| Device managed, compliant, patch level, EDR healthy | MDM and EDR | Priority 1 and 2 resources |
| User and sign-in risk | IdP risk engine, SIEM | Step-up or deny |
| Resource classification and owner policy | Data catalogue, application registry | Required strength per resource |
| Time, location, network | Request context | Anomaly signals, not sole basis |
| Threat intelligence | Feeds, SOC | Block known bad infrastructure |

### 8.2 Policy rules

| Rule ID | Resource | Condition | Decision |
|---|---|---|---|
| POL-001 *(Example)* | RES-01 Finance | Employee in finance group, phishing-resistant MFA, managed compliant device, low risk | Allow, session 8 h, re-evaluate on risk change |
| POL-002 *(Example)* | RES-01 Finance | Same, but unmanaged device | Deny |
| POL-003 *(Example)* | RES-02 Customer admin | Engineer with approved just-in-time elevation, managed device | Allow for 1 h, session recorded |
| POL-004 *(Example)* | RES-04 Collaboration | Contractor, MFA, unmanaged device | Allow browser-only via portal, no downloads |
| POL-005 *(Example)* | Any | Sign-in risk high | Deny and alert SOC |
| [POL-nnn] | [Resource] | [Condition] | [Decision] |

Policies are versioned as code, tested in report-only mode before
enforcement and reviewed by the policy board (ZT-GOV-001).

## 9. Reference implementations and example builds

<!-- Guidance: Use published example builds to check your design choices and avoid rediscovering integration problems. Map each build that resembles your environment to your roadmap items. -->

NIST SP 1800-35 (final, June 2025) documents example zero trust
implementations built by the NIST National Cybersecurity Center of
Excellence with industry collaborators using commercially available
technology, mapped to SP 800-207 and to security standards. As published,
it describes 19 example implementations; check the current guide for the
list of builds, the technologies used and the lessons learned.

| Our roadmap item | Relevant SP 1800-35 material | What we take from it |
|---|---|---|
| ZT-ID-002, ZT-DEV-002 | *Example:* Builds using the enhanced identity governance approach | Integration of IdP, device posture and PEP |
| ZT-NET-001 | *Example:* Builds using software defined perimeter components | Replacing VPN access paths |
| ZT-NET-002 | *Example:* Builds using micro-segmentation | Sequencing segmentation with monitoring first |
| [Item] | [Build or volume] | [Lesson] |

## 10. Governance and operating model

<!-- Guidance: Zero trust changes who decides access. Name the bodies, roles and processes that own policy, exceptions and operations. -->

| Element | Description |
|---|---|
| Steering committee | *Example:* CISO (chair), CIO, business unit leads; quarterly; approves phases and funding |
| Policy board | *Example:* Security architecture, identity, network, application owners; monthly; approves access policies and exceptions |
| Pillar owners | One accountable owner per pillar and cross-cutting capability |
| Exception process | Time-limited exceptions with compensating controls, recorded in the risk register |
| Change management | Every policy change tested in report-only mode, then enforced with rollback plan |
| Communications | User communications before each enforcement change; help desk briefed |

## 11. Metrics

<!-- Guidance: Measure outcomes (less implicit trust, faster detection) as well as rollout progress. Report the same metrics every quarter. -->

| ID | Metric | Baseline | Target | Source |
|---|---|---|---|---|
| M-01 | *Example:* Workforce accounts with phishing-resistant MFA | 12% | 95% | IdP |
| M-02 | *Example:* Priority 1 resources behind a PEP with posture check | 0 of 2 | 2 of 2 | Application registry |
| M-03 | *Example:* Remote access sessions over VPN | 2 100 per day | Below 100 per day | VPN logs |
| M-04 | *Example:* Standing privileged accounts | 40 shared, 120 personal | 0 shared, 20 break-glass and service | PAM |
| M-05 | *Example:* Allowed east-west flows in data centre not on the allow list | Unknown | 0 | Flow logs |
| M-06 | *Example:* Access decisions logged centrally | 40% | 100% | SIEM |
| M-07 | *Example:* Time to deprovision a leaver | 5 days | 1 hour | Identity governance |
| M-08 | *Example:* ZTMM functions at or above target stage | 3 of 25 | 25 of 25 | Section 5.3 reassessment |
| [M-nn] | [Metric] | [Baseline] | [Target] | [Source] |

## 12. Risks

<!-- Guidance: Include the threats to a ZTA itself from SP 800-207 section 5, not only programme delivery risks. -->

| ID | Risk | Source | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|---|
| RSK-01 | *Example:* Subversion of the decision process (PE or PA misconfigured or compromised) | SP 800-207 5.1 | Low | High | Policy as code with review; admin access to PE/PA under strongest controls; audit | [@name] |
| RSK-02 | *Example:* Denial of service or outage of PEP or PA blocks all access | SP 800-207 5.2 | Medium | High | Redundant PEPs and PA across regions; tested break-glass path | [@name] |
| RSK-03 | *Example:* Stolen credentials or insider within policy | SP 800-207 5.3 | Medium | High | Phishing-resistant MFA, least privilege, behavioural analytics | [@name] |
| RSK-04 | *Example:* Encrypted traffic reduces network inspection | SP 800-207 5.4 | High | Medium | Endpoint and PEP telemetry; metadata analysis | [@name] |
| RSK-05 | *Example:* Policy and log stores become high-value targets | SP 800-207 5.5 | Medium | High | Restricted access, integrity protection, retention rules | [@name] |
| RSK-06 | *Example:* Vendor lock-in through proprietary formats | SP 800-207 5.6 | Medium | Medium | Open standards for identity (SAML, OIDC, SCIM) and logs | [@name] |
| RSK-07 | *Example:* Automated non-person entities in administration misbehave or are abused | SP 800-207 5.7 | Medium | Medium | Separate identities, scoped permissions, monitoring of automation accounts | [@name] |
| RSK-08 | *Example:* User friction leads to shadow IT | Programme | Medium | Medium | Single sign-on, communication, phased enforcement | [@name] |
| [RSK-nn] | [Risk] | [Source] | [L / M / H] | [L / M / H] | [Mitigation] | [@name] |

## 13. Traceability

<!-- Guidance: Show that every objective maps to roadmap items, that every priority resource has policies, and that each is measured. -->

| Objective | Tenets | Roadmap items | Policies | Metrics |
|---|---|---|---|---|
| OBJ-01 | T-2, T-3 | ZT-NET-001, ZT-APP-001 | POL-001, POL-004 | M-02, M-03 |
| OBJ-02 | T-6 | ZT-ID-002 | POL-001 | M-01 |
| OBJ-03 | T-3, T-4, T-5 | ZT-DEV-002, ZT-ID-003 | POL-001 to POL-003 | M-02, M-04 |
| OBJ-04 | T-2 | ZT-NET-002, ZT-APP-002 | [Segment policies] | M-05 |
| OBJ-05 | T-7 | ZT-VIS-001 | All | M-06 |
| [OBJ-nn] | [Tenets] | [Items] | [Policies] | [Metrics] |

| Protect surface | Step reached (SP 800-207 7.3) | Next step | Date |
|---|---|---|---|
| RES-01 | *Example:* 7.3.4 policies formulated | 7.3.6 initial deployment in report-only mode | YYYY-MM-DD |
| RES-02 | *Example:* 7.3.6 initial deployment | 7.3.7 expand to all support staff | YYYY-MM-DD |
| [RES-nn] | [Step] | [Next] | YYYY-MM-DD |

## 14. Glossary and references

<!-- Guidance: Use the SP 800-207 vocabulary consistently so vendors and auditors understand the plan. -->

### 14.1 Glossary

| Term | Meaning |
|---|---|
| Zero trust (ZT) | Security concepts that minimise uncertainty in per-request access decisions by not granting trust based on network location or asset ownership alone |
| Zero trust architecture (ZTA) | An enterprise's plan for applying zero trust principles to its infrastructure and workflows |
| Policy engine (PE) | Component that makes the access decision |
| Policy administrator (PA) | Component that sets up or tears down the session path according to the PE's decision |
| Policy enforcement point (PEP) | Component that enables, monitors and terminates connections to a resource |
| Protect surface | A resource or group of resources protected as a unit |
| Pillar | ZTMM area of capability: Identity, Devices, Networks, Applications and Workloads, Data |
| Micro-segmentation | Dividing the network into small segments with enforcement between them |

### 14.2 References

| Reference | Use |
|---|---|
| NIST SP 800-207, *Zero Trust Architecture*, Rose, Borchert, Mitchell and Connelly, August 2020, doi:10.6028/NIST.SP.800-207 | Tenets (2), components (3), approaches (4), migration (5.1, 7.3), threats (12) |
| CISA, *Zero Trust Maturity Model*, Version 2.0, April 2023 (cisa.gov/zero-trust-maturity-model) | Pillars, functions, cross-cutting capabilities and stages (5.2, 5.3) |
| NIST SP 1800-35, *Implementing a Zero Trust Architecture*, final, June 2025 (csrc.nist.gov/pubs/sp/1800/35/final) | Example builds (9) |
| NIST SP 800-207A, *A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments*, September 2023 | Workload access in cloud-native environments (optional) |
| Security Architecture Document Template (NIST SP 800-160, STRIDE) (`security/security-architecture`) | System-level security architecture under this plan |
| Threat Model Template (STRIDE) (`security/threat-model`) | Threats per protect surface |
| NIST CSF 2.0 Profile Template (`compliance/nist-csf`) | Organisation-level cybersecurity profile |
| Access Review Template (`ops/access-review`) | Periodic access reviews during migration |

## Standard and licence note

Based on NIST SP 800-207 (August 2020), NIST SP 1800-35 (final, June 2025)
and the CISA Zero Trust Maturity Model Version 2.0 (April 2023), which are
works of the United States Government and not subject to copyright in the
United States. Section numbers, component names, pillar, function and stage
names are cited; the explanations are original paraphrases. Check the
current official versions at nist.gov and cisa.gov before relying on this
plan, as updates or revisions may have been published. Original text written
for this collection. Template licence: MIT.