Most zero trust programmes stall because nobody can say, pillar by pillar, where the organisation stands today and what the next stage actually looks like. The CISA Zero Trust Maturity Model (ZTMM) Version 2.0, published in April 2023, gives that yardstick: five pillars, three cross-cutting capabilities and four stages from Traditional to Optimal. It was written for US federal agencies under Executive Order 14028 and OMB M-22-09, but CISA encourages any organisation to use it, and it has become a common reference for private sector roadmaps. This guide explains how the model is built, how to score yourself honestly, and how to move up a stage, with particular attention to service accounts, workloads and other non-human identities that the model covers but rarely names. It is for security architects, identity leads and programme owners. For the underlying architecture see the NIST SP 800-207 Zero Trust Architecture Guide.
Key takeaways
- Version 2.0 is the current model. CISA released ZTMM v1.0 in August 2021 and v2.0 in April 2023 in response to public comment, adding new functions such as Access Management, Network Resilience and Secure Application Development and Deployment Workflow.
- Score each function, not the organisation. The model has 22 functions across five pillars, and CISA states that each pillar can progress at its own pace, so a single "we are Advanced" score hides the gaps.
- Identity is the anchor pillar. Authentication, Identity Stores, Risk Assessments and Access Management decide every other pillar's access decisions, and the model's definition of identity includes non-person entities.
- Non-human identities usually score lowest. Service accounts, API keys and workload credentials tend to sit at Traditional (permanent access, manual lifecycle) even where workforce MFA is Advanced.
- Optimal is not the goal everywhere. CISA describes the model as a guide, not a set of requirements; prioritise functions by mission risk and fund the move one stage at a time.
The four stages
CISA ZTMM v2.0 defines four stages. Score each function from 1 (Traditional) to 4 (Optimal) using CISA's stage definitions.
| Score | Stage | Description |
|---|---|---|
| 1 | Traditional | Manually configured lifecycles and attribute assignment; static security policies; least privilege set only at provisioning; siloed pillars; manual response and mitigation. |
| 2 | Initial | Automation begins for attribute assignment, lifecycle configuration and policy decisions; first cross-pillar solutions and integrations with external systems; some responsive least-privilege changes after provisioning. |
| 3 | Advanced | Automated controls where applicable; cross-pillar coordination; centralised visibility and identity control; policy enforcement integrated across pillars; least privilege adjusted on risk and posture assessments. |
| 4 | Optimal | Fully automated, just-in-time lifecycles and attribute assignment; dynamic least privilege enterprise-wide; cross-pillar interoperability with continuous monitoring and comprehensive situational awareness. |
Capability areas
Each pillar contains functions, and each pillar also carries the three cross-cutting capabilities: Visibility and Analytics, Automation and Orchestration and Governance. The table lists the v2.0 functions and the identity angle for each pillar.
| Pillar | Functions (ZTMM v2.0) | Where non-human identity fits |
|---|---|---|
| Identity | Authentication; Identity Stores; Risk Assessments; Access Management | Service accounts, workload identities and AI agents are "entities" and need the same lifecycle, authentication and expiry as users. |
| Devices | Policy Enforcement and Compliance Monitoring; Asset and Supply Chain Risk Management; Resource Access; Device Threat Protection | Virtual machines, servers and containers sit here; device certificates and posture signals feed access decisions. |
| Networks | Network Segmentation; Network Traffic Management; Traffic Encryption; Network Resilience | Service-to-service connections should be authorised by workload identity, not by IP allowlists. |
| Applications and Workloads | Application Access; Application Threat Protections; Accessible Applications; Secure Application Development and Deployment Workflow; Application Security Testing | CI/CD pipelines, deployment credentials and runtime workload tokens; Optimal replaces administrator access with automation. |
| Data | Data Inventory Management; Data Categorization; Data Availability; Data Access; Data Encryption | Applications and agents reading data need time-limited, least-privilege grants and logged key use. |
Identity pillar stage by stage
| Function | Traditional | Initial | Advanced | Optimal |
|---|---|---|---|---|
| Authentication | Passwords or MFA with static access | MFA, possibly with a password as one factor, plus validation of multiple entity attributes | Phishing-resistant MFA and attributes for all identities; passwordless via FIDO2 or PIV begins | Continuous validation with phishing-resistant MFA, not only at initial access |
| Identity Stores | Self-managed, on-premises only | Self-managed and hosted stores with minimal integration (for example SSO) | Some stores securely consolidated and integrated | Stores securely integrated across partners and environments |
| Risk Assessments | Limited determination of identity risk | Manual methods and static rules | Some automated analysis and dynamic rules | Real-time, continuous analysis and dynamic rules |
| Access Management | Permanent access with periodic review | Access, including privileged, expires with automated review | Need-based and session-based access tailored to actions and resources | Automated just-in-time and just-enough access |
For workloads, read "phishing-resistant MFA" as cryptographic, short-lived credentials bound to the workload (federated tokens, X.509 SVIDs, managed identities) rather than static secrets. See the Workload Identity Federation Guide and the SPIFFE and SPIRE Guide. In the Identity pillar's Automation and Orchestration row, CISA's Advanced stage still leaves privileged user identities manual; NHI lifecycle automation is a separate gap most organisations must close themselves, as the Microsoft Midnight Blizzard breach showed when a legacy test tenant account without MFA and an over-privileged test OAuth application opened executive mailboxes.
Self-assessment questions
- Authentication: What share of human accounts use phishing-resistant MFA, and what share of workloads still authenticate with long-lived passwords, keys or tokens?
- Identity Stores: How many identity stores hold service accounts (Active Directory, cloud IAM, Kubernetes, CI/CD, SaaS), and are they federated or isolated?
- Access Management: Does any privileged access, human or non-human, expire automatically, or is it all standing?
- Risk Assessments: Is identity risk (impossible travel, anomalous API use by a service principal) scored automatically and fed into access decisions?
- Devices: Do access decisions consider device or virtual asset posture, and is the asset inventory complete?
- Networks: Are critical workloads isolated, and is east-west traffic encrypted and authorised per service?
- Applications: Do developers have standing access to production, and are workloads immutable and changed only by redeployment?
- Data: Is data categorised, and is access to sensitive data time-limited and logged for applications as well as users?
- Cross-cutting: Are identity, device and network logs correlated automatically, and are policies defined once and enforced across pillars?
Score each of the 22 functions plus the three cross-cutting capabilities per pillar, separately for human and non-human identities where they differ. Record evidence (a configuration export, a report, a log query) for every score; a stage claimed without evidence should be scored one lower.
Moving up: roadmap
- Baseline (months 0 to 3): Inventory identities, devices, applications and data stores, including service accounts and API keys with owners. Score every function and agree target stages per pillar with mission owners. See the Service Account Inventory Template.
- Traditional to Initial (months 3 to 12): Consolidate identity stores behind SSO, enforce MFA at the application layer, set expiry on privileged access, begin automated joiner, mover and leaver for users and service accounts, isolate critical workloads. Pilot each change in audit or report-only mode on one business unit first and keep the previous policy ready to restore.
- Initial to Advanced (year 2): Phishing-resistant MFA for all users, workload identity federation to replace static cloud keys, session-based access for administrators, device posture in access policy, micro-perimeters around high-value applications, removal of developer access to production.
- Advanced to Optimal (year 3 onwards): Just-in-time, just-enough access for humans and workloads, continuous evaluation during sessions, behaviour-based analytics, policy as code with automated enforcement and dynamic updates. See the JIT Access Guide.
- Re-score every 6 to 12 months: Track movement per function and report the lowest-scoring pillar to leadership, not the average.
Small vs large organisations: a small organisation on a single cloud identity provider can often reach Initial across Identity and Applications within a year by using built-in conditional access and managed identities. Large federal or regulated estates with on-premises directories and OT should expect the multi-year journey CISA describes and should fund pillars in mission priority order rather than in parallel.
Measure progress with: percentage of functions at or above target stage; share of privileged access (human and NHI) that is time-bound; share of workloads using federated or short-lived credentials; percentage of applications reachable only through policy-enforced access; mean time to revoke a compromised credential.
Practitioner checklist
- Confirm you are using ZTMM v2.0 (April 2023) and record the date of each assessment.
- Score all 22 functions and the cross-cutting capabilities per pillar, with evidence.
- Score non-human identities separately in the Identity and Applications and Workloads pillars.
- Set a target stage per function based on mission risk, not a blanket Optimal.
- Map each roadmap item to NIST CSF 2.0 (PR.AA-01, PR.AA-03, PR.AA-05, PR.IR-01) and SP 800-53 controls (AC-2, AC-6, IA-2, IA-5, SC-7, CA-7) so audit evidence is reused.
- Pilot every enforcement change in report-only mode and keep a rollback path.
- Report the weakest pillar and its trend to leadership each quarter.
- Link the ZTMM roadmap to your NIST CSF 2.0 Guide profile so both use one evidence set.
Standards and references
- CISA: Zero Trust Maturity Model Version 2.0
- CISA: Zero Trust Maturity Model
- OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- NIST: SP 800-207 Zero Trust Architecture
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Zero Trust Identity Guide · Zero Trust for AI Agents Guide · NHI Governance Maturity Model · PAM Maturity Model · Public Sector Identity Security Guide