CISA Zero Trust Maturity Model
the five pillars, four stages, and three capabilities of ZTMM v2.0

CISA Zero Trust Maturity Model explained

The CISA Zero Trust Maturity Model (ZTMM) is the maturity inventory the Cybersecurity and Infrastructure Security Agency publishes for federal civilian agencies and any organisation that wants a published, scorecard-shaped read on Zero Trust progress. ZTMM v2.0, released in April 2023, organises Zero Trust across five pillars (Identity, Devices, Networks, Applications and Workloads, Data) plus three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance), with four maturity stages per pillar and per capability (Traditional, Initial, Advanced, Optimal).

ZTMM is the maturity inventory, not the architectural reference. The reference architecture is NIST SP 800-207, which names the seven tenets, the Policy Engine and Policy Administrator and Policy Enforcement Point components, the trust algorithm input categories, and the deployment approaches. ZTMM tracks where the programme is on the journey; SP 800-207 describes what the architecture is at the end of it. A serious Zero Trust programme reads both together.

For internal security teams, AppSec teams, product security teams, vulnerability management functions, GRC owners, security engineering teams, security architects, security operations leaders, and CISOs, ZTMM is the most frequently asked-after Zero Trust scorecard. The published per-pillar criteria turn a Zero Trust report from narrative into structured evidence, which is why ZTMM has become the default Zero Trust reporting frame across the federal civilian community, the critical infrastructure community, public-company registrants under the SEC disclosure rules, and any enterprise that wants its Zero Trust progress to be readable by an external audience without bespoke explanation.

The five ZTMM pillars

ZTMM organises the Zero Trust progression across five pillars, each with its own subcategories, its own evidence expectations, and its own maturity-stage criteria. The pillars are not independent; the Identity pillar feeds the access decisions every other pillar enforces, and the Visibility and Analytics, Automation and Orchestration, and Governance capabilities apply inside each pillar rather than next to them. The five-pillar structure makes the per-pillar gap analysis tractable.

The three cross-cutting capabilities

The three cross-cutting capabilities sit inside every pillar rather than next to the pillars. ZTMM expects each pillar to have its own visibility and analytics maturity, its own automation and orchestration maturity, and its own governance maturity, on top of the pillar-side functional maturity. The structure forces the scorecard to surface gaps in the cross-cutting dimensions independently of the underlying functional gaps.

The four maturity stages

ZTMM names four maturity stages per pillar and per cross-cutting capability. The stages are operating postures backed by evidence, not aspirational labels. The progression compounds: Optimal on a pillar requires the Advanced criteria to be in place, which requires the Initial criteria to be in place. Maturity is per pillar; the scorecard records a per-pillar and per-capability stage rather than an aggregate Zero Trust score.

How the ZTMM scorecard reads

The ZTMM scorecard is what makes the maturity model operable. The reading mechanics below are the ones a programme has to settle before the scorecard becomes useful as a planning, reporting, and audit input.

ZTMM in the federal and non-federal context

ZTMM was published for federal civilian agencies operating under OMB Memorandum M-22-09, and it has become the de-facto Zero Trust scorecard format outside that community as well. The context below explains the audiences that read against ZTMM and the surrounding mandates and reference structures.

Evidence the maturity model expects

A ZTMM scorecard reads well when the evidence is produced as a side effect of the operating work rather than reconstructed at scorecard refresh time. The minimum set below maps to the artefacts examiners, federal customers, audit committees, and customer security reviewers most often ask against, and the same artefacts feed parallel reads under NIST SP 800-207, NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, FedRAMP, CIS Controls, DORA, and NIS2 when the underlying record is structured.

Failure modes the maturity model is designed to surface

ZTMM is forgiving on the choice of identity provider, the choice of device management platform, the choice of network segmentation product, the choice of application-level access broker, and the choice of data classification toolchain. It is unforgiving about a small number of patterns that turn the scorecard cosmetic rather than operational. The patterns below recur across early and mid-stage ZTMM adoptions.

How ZTMM relates to adjacent frameworks

ZTMM sits in a busy Zero Trust and broader cybersecurity neighbourhood. The relationships below are the ones programmes encounter most often when they read ZTMM against the rest of their framework footprint. The relationships matter because programmes that try to operate each framework in isolation rebuild the same evidence multiple times.

Who reads against ZTMM

ZTMM has more than one audience inside an organisation, and each one reads the scorecard from a different angle. The audience lens below is the one we see most often when ZTMM is the Zero Trust reporting frame.

Where SecPortal fits in a ZTMM programme

SecPortal is the operating record layer for the ZTMM scorecard cycle, not a replacement for CISA, OMB, NIST, or the underlying identity, device, network, application, and data control planes a Zero Trust programme needs. The platform handles the ZTMM-side workstreams (engagement structure per pillar, finding intake, scorecard refresh cadence, evidence-pack assembly, leadership reporting, framework crosswalks) so the inputs the scorecard refresh reads against are produced as structured records rather than reconstructed at the maturity-review meeting.

Honest scope: what SecPortal is and is not

ZTMM expects the underlying identity, device, network, application, and data control planes to do the enforcement work. SecPortal sits next to those control planes as the operating record. The scope statements below clarify the line.

The asset posture inputs the Devices, Networks, Applications and Workloads, and Data pillars depend on are produced through the day-to-day vulnerability management work the same workspace already runs. The vulnerability prioritisation workflow keeps the highest-risk asset posture findings at the top of the queue feeding the pillar evidence. The asset criticality scoring workflow carries the resource classification the ZTMM Data pillar expects to underpin per-class access policy. The control-mapping cross-framework crosswalk workflow carries the same evidence pack across ZTMM, NIST CSF 2.0, NIST SP 800-53, ISO 27001, SOC 2, and the broader audit footprint. The audit fieldwork evidence request fulfillment workflow carries the evidence-pack assembly cadence the maturity review and the audit cycle both read against. The security leadership reporting workflow rolls the scorecard refresh and the per-pillar evidence into the leadership cadence the Governance capability expects.

For internal security teams running the programme, the internal security teams workspace bundles the platform with the engagement structure the scorecard refresh cadence reads against. For the AppSec function carrying Applications and Workloads pillar evidence, the AppSec teams workspace covers the development-adjacent angle. For the vulnerability management function feeding cross-pillar asset posture evidence, the vulnerability management teams workspace covers the operating cadence that produces the underlying findings. For the security engineering function owning Networks and Devices pillar evidence, the security engineering teams workspace covers the build-side mechanics. For the security architecture function holding the SP 800-207-to-ZTMM mapping, the security architects workspace carries the design-side angle. For the GRC function holding the cross-framework evidence pack, the GRC and compliance teams workspace covers the audit footprint. For security leaders carrying the scorecard cadence and the executive reporting rhythm, the CISOs and security leaders workspace covers the programme-level reporting model.

For deeper reading on the disciplines this scorecard reads against, the Zero Trust Architecture implementation guide covers the practitioner-side rollout against SP 800-207. The NIST CSF 2.0 framework page covers the broader cybersecurity outcome framework the Zero Trust programme sits inside. The NIST SP 800-53 framework page covers the control catalogue the pillar-side evidence reads against. The FedRAMP framework page covers the cloud authorisation programme that pairs with ZTMM in the federal context. The CIS Controls framework page covers the prioritised practice set that produces most of the pillar-side evidence ZTMM reads against.

For analytical context on how the maturity model evolves across cycles, the continuous control monitoring cadence research covers the operating discipline that pairs with the scorecard refresh, and the security control drift research covers the erosion patterns the maturity model is designed to surface between scorecard refreshes when the review cadence relaxes.