Zero Trust Frameworks Compared: Which Model to Anchor Your Programme On

Most zero trust programmes quote four or five frameworks at once and end up with a roadmap nobody can measure, because each framework answers a different question. NIST SP 800-207 defines the architecture, the CISA Zero Trust Maturity Model scores progress, the US Department of Defense (DoD) strategy and reference architecture turn the idea into a numbered backlog with a deadline, the UK NCSC principles give a design checklist, and Forrester's work supplies the business definition many boards first heard. This guide compares the five as tools, not as rivals: what each is for, its threat model, how it is structured, how programmes fail when they use it for the wrong job, and how to crosswalk them so one model anchors the programme and the others plug in. It is written for security architects, zero trust programme leads and assessors who must pick an anchor and defend the choice. Frameworks are listed in the order the reader usually meets them; order is not a ranking.

Key takeaways

• Pick one anchor by question. Architecture vocabulary comes from NIST SP 800-207, stage scoring from CISA ZTMM, a funded capability backlog from the DoD catalogue, design review tests from the NCSC principles, and an executive definition from Forrester.
• Only the DoD framework carries a deadline. DoD components must reach Target level outcomes by the end of FY2027; the others are guidance with no certification and no compliance date of their own.
• Pillars differ in count, not in substance. CISA uses five pillars plus three cross-cutting capabilities, DoD uses seven pillars that promote automation and analytics to pillars, and NIST and NCSC use components and principles instead of pillars.
• Crosswalk through the policy decision model. Every framework reduces to a policy engine deciding, an enforcement point enforcing and signals feeding both, so map controls to that triangle first and to pillars second.
• Machines are in scope in all five. Service accounts, workloads and AI agents are entities in CISA's identity pillar, enforced machine-to-machine authentication in DoD's principles and uniquely identified services in NCSC principle 2.

Short answer: which framework answers which question

The one-to-one comparison of the first two is covered in depth in NIST 800-207 vs CISA Zero Trust Maturity Model; this guide adds DoD, NCSC and Forrester and focuses on the anchor decision and the crosswalk.

NIST SP 800-207: the architecture vocabulary

What it is: NIST published SP 800-207 as a final Special Publication on 11 August 2020, after two public drafts. Its abstract sets the frame every later document borrows: zero trust moves defences from static, network-based perimeters to users, assets and resources, grants no implicit trust based on physical or network location or asset ownership, and treats authentication and authorisation as discrete functions performed before a session to a resource is established. NIST pairs it with CSWP 20, Planning for a Zero Trust Architecture, and SP 800-207A for cloud-native applications.

• Threat model: an attacker already inside the network, or a legitimate but compromised subject, moving laterally because location grants trust.
• Architecture in words: a subject on a device requests a resource; the PEP brokers the session; the PE, informed by data sources such as threat intelligence, activity logs, device posture and identity stores, computes a decision through a trust algorithm; the PA tells the PEP to open or close the path. Deployment approaches are enhanced identity governance, micro-segmentation and software-defined perimeters.
• Failure modes when used as the anchor: it has no stages and no scoring, so a programme anchored only on 800-207 can describe the target state but cannot report progress; teams also over-read the deployment approaches as product categories.
• Best use: the vocabulary for architecture diagrams, contracts and design reviews, and the reference every other framework claims alignment with.

See the NIST SP 800-207 Zero Trust Architecture Guide for the tenets one by one and the NIST SP 1800-35 Implementing a Zero Trust Architecture Guide for worked builds.

CISA ZTMM 2.0: the maturity yardstick

What it is: CISA's model describes five pillars (Identity, Devices, Networks, Applications and Workloads, Data), three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance) and four stages: Traditional, Initial, Advanced and Optimal. Version 2.0 added the Initial stage. CISA describes the model as one of many roadmaps agencies can reference, written for the US federal transition, and it is widely reused outside government.

• Threat model: implicit, static trust. The stage definitions move from manual lifecycles and static policy towards automated, just-in-time attribute assignment and dynamic least privilege, so the threat being reduced is standing access that nobody re-evaluates.
• Architecture in words: none prescribed. The model assumes an 800-207 style architecture and grades each function (for example Authentication, Identity Stores, Risk Assessments and Access Management in the Identity pillar) on its own scale.
• Failure modes: averaging functions into one organisational score, treating Optimal as the goal everywhere, and scoring only the workforce while service accounts and API keys sit at Traditional.
• Best use: baseline assessment, board reporting by pillar, and choosing the next stage per function.

See the CISA Zero Trust Maturity Model Guide and, for NHI Mgmt Group's own five-level identity-focused model, the Zero Trust Maturity Model Guide.

DoD Zero Trust Strategy and Reference Architecture: the capability backlog

What it is: the DoD Zero Trust Strategy, version 1.0 dated 21 October 2022, sets four strategic goals: Zero Trust Cultural Adoption, DoD Information Systems Secured and Defended, Technology Acceleration and Zero Trust Enablement. It defines Target level as the required minimum set of capability outcomes and activities needed against currently known threats, and Advanced level as the full set that enables adaptive responses. Components must achieve Target level outcomes by the end of FY2027. The strategy describes seven pillars with Data at the centre. The DoD CIO library also publishes the Reference Architecture, the Zero Trust Capabilities and Activities catalogue, a Capability Execution Roadmap and Zero Trust for Operational Technology Activities and Outcomes; at the time of checking (November 2026) the library lists the strategy under the Department of War name.

• Threat model: a capable, persistent adversary already present in the network. The reference architecture tenets include assume a hostile environment and presume breach, which is why its principles call for machine-to-machine authentication and near-real-time risk profiles, not only user MFA.
• Architecture in words: the same PDP and PEP model as 800-207, organised into seven pillars (User; Device; Applications and Workloads; Data; Network and Environment; Automation and Orchestration; Visibility and Analytics), each broken into numbered capabilities such as 1.3 Multi-Factor Authentication and 5.4 Micro Segmentation, each capability broken into activities.
• Failure modes: copying the whole catalogue into a commercial organisation that lacks the staff to run it, treating Advanced activities as mandatory, and confusing the strategy (goals) with the reference architecture (design) or the catalogue (work).
• Best use: the most granular public backlog; useful to any organisation that wants activities it can tick off with evidence, and essential for defence suppliers who will be asked about it.

See the DoD Zero Trust Strategy and Reference Architecture Guide for the pillar and capability detail and the OMB M-22-09 Federal Zero Trust Strategy Guide for the civilian federal mandate that sits beside it.

NCSC design principles: the design review checklist

What it is: the UK NCSC zero trust architecture collection, version 1.1 reviewed 16 January 2026, lists seven principles: know your architecture including users, devices, services and data; know your user, service and device identities; assess user behaviour, device and service health; use policies to authorise requests; authenticate and authorise everywhere; focus your monitoring on users, devices and services; and don't trust any network, including your own. The NCSC presents it as guidance to help design and review an architecture, for public and private sector enterprises and for product vendors, with no certification.

• Threat model: a hostile network everywhere, including the office LAN and home broadband, and a policy engine that is itself a high-value target. The guidance is unusually specific about protecting the engine, graded device identity confidence and keeping legacy controls until the new ones are proven.
• Architecture in words: policy engine, PEP and signals, with the same request flow as NIST but no separate policy administrator.
• Failure modes: quoting the principles without converting each into a testable design decision, and using them for progress reporting, which they were not built for.
• Best use: architecture review boards, design authority sign-off, and procurement questions for UK public and private sector buyers.

See the NCSC Zero Trust Architecture Design Principles Guide for each principle as a design decision.

Forrester Zero Trust and ZTX: the executive definition

What it is: the zero trust term comes from Forrester research credited to John Kindervag. In January 2018 Forrester described Zero Trust eXtended (ZTX) as the application of the framework to the enterprise, with an ecosystem view across Network, Data, Workforce, Workload, Automation and Orchestration, and Visibility and Analytics, and said a platform needs considerable capability in at least three of those areas plus strong API integration. In January 2022 Forrester published "The Definition of Modern Zero Trust": an information security model that denies access to applications and data by default, granting access only through policy informed by continuous, contextual, risk-based verification of users and their devices. It gives three principles: all entities are untrusted by default, least privilege access is enforced, and comprehensive security monitoring is implemented. Forrester states that the definition does not diverge from NIST SP 800-207.

• Threat model: built-in assumptions of trust in enterprise networks, framed as a business liability rather than as a specific adversary.
• Architecture in words: an ecosystem of capabilities integrated through APIs; no reference component model.
• Failure modes: using an analyst capability ecosystem as a shopping list, so the programme becomes a set of purchases; relying on research that later readers cannot access to verify.
• Best use: a one-paragraph definition for executives and a way to explain why integration across tools matters more than any single product.

How the frameworks line up: the crosswalk

Map controls to the policy decision triangle first, then to pillars. The table below shows where the same concern lives in each framework. Cells describe what each framework itself uses; NIST and NCSC do not use pillars, so their column names the tenet, component or principle that carries the concern.

The practical rule: keep one control register, give each control a single owner, and tag it with the framework references it satisfies. Do not run five parallel assessments.

Choosing the anchor: decision criteria

1. Are you a DoD component or a defence supplier? Anchor on the DoD catalogue, because Target level activities are the language your customer will audit against. Use 800-207 for diagrams.
2. Are you a US federal civilian agency? Anchor on CISA ZTMM for scoring, as OMB M-22-09 and agency reporting expect, with 800-207 as the architecture.
3. Are you a UK organisation, or do you need a design authority checklist? Anchor design on the NCSC principles and measure progress with CISA stages, since the NCSC does not define stages.
4. Do you need board buy-in before any of the above? Use Forrester's three principles as the definition in the strategy paper, then hand over to an operational framework. Do not build the roadmap on an analyst ecosystem.
5. Small or mid-sized organisation with no regulator expectation? CISA ZTMM is the lightest workable anchor: score the Identity pillar first, pick one stage up per function per year, and borrow NCSC principle 2 and 4 guidance for the design.
6. Large, multinational organisation? Anchor on 800-207 vocabulary and CISA scoring globally, add DoD activities only where defence contracts apply, and use NCSC principles in UK design reviews.

Worked scenario: one programme, three frameworks

A 6,000-person engineering firm sells to UK government and holds one US defence subcontract. It has workforce MFA, a flat internal network, about 900 service accounts and a growing set of AI agents calling internal APIs.

1. Anchor: the firm uses NIST SP 800-207 vocabulary for its target architecture and CISA ZTMM 2.0 to score every function. It applies the DoD Target level activities only to the enclave that serves the defence contract, and uses the NCSC principles as the design authority checklist for UK services.
2. Baseline: scoring shows Identity Authentication at Advanced for staff but Traditional for service accounts and agents (static keys, no expiry), Networks at Traditional (flat VLANs) and Visibility and Analytics at Initial.
3. Design decisions: NCSC principle 2 drives a rule that every service and agent has its own identity with scope-limited, time-limited tokens; principle 4 drives hardening of the policy engine and a break-glass procedure; DoD capability 5.4 drives micro-segmentation of the defence enclave.
4. Rollout: conditional access and segmentation rules run in report-only or log-only mode for four weeks, then enforce in rings (IT, one business unit, everyone). Rollback is a documented switch back to report-only per policy, owned by the policy engine team.
5. Reporting: the board sees CISA stages per pillar; the defence customer sees DoD Target activities with evidence; the UK design authority sees each principle signed off. All three views come from one control register.

Where identity and NHIs fit

All five frameworks put identity at the centre, and all five, read carefully, include machines. CISA's identity pillar covers entities, not only people; the DoD reference architecture principles require machine-to-machine authentication and authorisation; NCSC principle 2 asks for every service to be uniquely identifiable with minimum privileges and mutual authentication; Forrester's modern definition treats all entities as untrusted by default. Score service accounts, workload identities and agents as separate rows in whatever model you anchor on. See the Zero Trust Identity Guide and the Zero Trust for AI Agents Guide.

Detection and measurement

• Decision coverage: percentage of applications and APIs whose access passes through a PEP that consults the policy engine. Target a rising trend each quarter, with crown jewels first.
• Stage movement: number of CISA ZTMM functions that moved up one stage in the period, reported per pillar, never as an average.
• Machine identity share: percentage of service accounts and agents using short-lived, scoped credentials rather than static secrets.
• Implicit trust paths: count of network routes or firewall rules that grant access by location alone; should fall to zero for in-scope resources.
• Policy change revocation time: time from a posture or policy change to termination of affected live sessions, the test of whether enforcement is continuous.
• Evidence completeness: for DoD scope, percentage of Target activities with attached evidence rather than self-declaration.

Common failure patterns

• Five assessments, no programme: separate spreadsheets per framework with different owners. One register, many tags.
• Averaged maturity: a single "Advanced" score that hides Traditional service accounts and a flat network.
• Wrong document for the job: citing the DoD strategy when the requirement is in the capabilities catalogue, or quoting the NCSC principles as a scoring scheme.
• Product-led roadmap: buying against an analyst ecosystem or a deployment approach before the inventory exists, then discovering the policy engine has nothing reliable to decide on.
• People-only scope: inventories and MFA for staff while machine credentials keep standing access, which breaks the machine identity requirements in DoD, NCSC and CISA alike.
• Removing old controls too early: the NCSC explicitly advises keeping existing controls until the new ones are proven; programmes that pull the VPN first create gaps.

Framework mapping

Practitioner checklist

• Write down which question each framework answers for you and name one anchor in the programme charter.
• Build a single control register tagged with 800-207 component, CISA function, DoD capability (where relevant) and NCSC principle.
• Score every CISA function separately, with service accounts, workloads and agents as their own rows.
• Turn each NCSC principle into a testable design decision for the design authority.
• Limit DoD Target level activities to systems in defence scope unless you have the staff for the full catalogue.
• Run every new enforcement policy in report-only mode first and document the rollback per policy.
• Report stage movement per pillar and decision coverage, never a single average score.
• Re-check framework versions yearly.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• CISA: Zero Trust Maturity Model
• DoD CIO: DoD Zero Trust Strategy
• DoD CIO: Library (Reference Architecture, Capabilities and Activities, Execution Roadmap)
• NCSC: Zero trust architecture design principles
• Forrester: The Definition of Modern Zero Trust
• Forrester: What ZTX Means for Vendors and Users

Related NHI Mgmt Group resources: NIST 800-207 vs CISA Zero Trust Maturity Model · Zero Trust Implementation Roadmap Template · Top 10 Zero Trust Mistakes · Zero Trust Executive Briefing