TL;DR: CISA’s Zero Trust Maturity Model translates Zero Trust Architecture into five operational pillars and three maturity stages, with identity, device, network, application workload, and data controls moving from manual to dynamic enforcement. StrongDM’s summary also cites a 15.1% rise in cyberattacks and data breaches in 2021, according to the article.
At a glance
What this is: CISA’s Zero Trust Maturity Model gives agencies a staged way to operationalise Zero Trust across identity, device, network, workload, and data controls.
Why it matters: It matters because IAM teams need to align access, authentication, and policy enforcement across human, NHI, and workload identities instead of treating Zero Trust as a network-only initiative.
By the numbers:
- 2021, 021, the average number of cyberattacks and data breaches increased by 15.1%.
👉 Read StrongDM's TL;DR version of the CISA Zero Trust Maturity Model
Context
Zero Trust is not a single tool or a network redesign. It is an operating model that assumes access must be continuously verified, not granted once and trusted indefinitely. For identity teams, that changes how human users, service accounts, and workload access are governed because policy, session state, and authorization all become live controls rather than static approvals.
The CISA Zero Trust Maturity Model matters because many enterprise programmes still rely on coarse access boundaries and legacy assumptions about where trust lives. CISA’s five pillars and three maturity stages are meant to help organisations move from manual enforcement toward dynamic policy and continuous validation, which is where identity governance becomes the control plane rather than an afterthought.
Key questions
Q: How should organisations implement Zero Trust without breaking existing access workflows?
A: Start by mapping where access is still static, then introduce per-session policy at the highest-risk boundaries first. Focus on privileged users, service accounts, and workloads that touch sensitive data. The goal is not to redesign everything at once, but to prove that dynamic enforcement can replace standing trust in the places that matter most.
Q: Why do service accounts and workloads complicate Zero Trust programmes?
A: Because they often authenticate successfully but are governed like infrastructure, not identities. That creates standing access paths that are rarely reviewed with the same rigour as human access. Zero Trust only works when non-human identities are subject to the same policy discipline, telemetry, and revocation logic as any other actor.
Q: How do teams know if Zero Trust is actually improving access control?
A: Look for runtime evidence, not policy statements. If access decisions change based on device posture, session context, and resource sensitivity, the programme is moving in the right direction. If controls only show up in annual reviews or static diagrams, the architecture may be branded Zero Trust without behaving like it.
Q: What is the difference between static access control and dynamic policy in Zero Trust?
A: Static control grants access based on a fixed rule or pre-approved entitlement, while dynamic policy evaluates current conditions before and during access. In practice, dynamic policy is what lets a Zero Trust programme react to risk, posture, and resource state instead of depending on trust established at login.
Technical breakdown
CISA Zero Trust maturity stages and what changes operationally
The model groups implementation into Traditional, Advanced, and Optimal stages. Traditional environments rely on manual configuration and static policy. Advanced environments add central visibility and some cross-pillar coordination. Optimal environments shift to attributes assigned automatically and policy enforced from observed or automated triggers. The point is not perfection, but repeatable movement from fixed trust to policy-driven verification across identity, device, network, application workload, and data pillars.
Practical implication: map each identity control to a maturity stage so you can see where access is still being granted through static assumptions.
Identity, workload, and data pillars in Zero Trust architecture
CISA’s model treats identity, workload, and data as separate but linked control domains. Identity answers who or what is requesting access. Application workload controls what services may communicate and under what conditions. Data controls determine how sensitive information is protected in transit and at rest. In practice, the model only works when these pillars share telemetry and policy logic, because isolated controls create gaps that attackers can exploit between authentication, authorization, and data access.
Practical implication: align identity policy with workload and data controls so access decisions follow the resource, not just the login event.
Continuous authentication and dynamic policy enforcement
The model’s core security shift is from one-time authentication to continuous verification. That means access can change as risk changes, based on device posture, session context, observed behaviour, and asset state. Dynamic policy is the mechanism that turns Zero Trust into an operating discipline rather than a declaration. For identity governance, this is especially relevant where privileged access, service accounts, and cloud workloads need decisions that reflect current conditions instead of provisioning-time assumptions.
Practical implication: design policies that can react to current risk signals, not just initial authentication success.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Zero Trust fails when organisations treat authentication as a one-time event. The CISA model is explicit that access should be granted per session and enforced dynamically, which exposes the weakness of programmes that still think in terms of durable trust after login. That assumption is especially fragile in environments with shared infrastructure, service accounts, and cloud workloads. The practitioner conclusion is simple: identity governance has to move from login-centric control to continuous authorisation.
Per-session access is the control premise that matters most for modern identity governance. CISA’s maturity model turns the access decision into a living policy problem, not a provisioning problem. When the same account can move across databases, servers, clusters, and applications, the control surface is the session, not the account record. The implication for practitioners is that access review alone cannot carry Zero Trust without telemetry and enforcement that operate in real time.
Identity, workload, and data are inseparable in a mature Zero Trust programme. Treating them as separate projects creates false confidence because the weakest pillar becomes the path of least resistance. A workload with overly broad access can bypass an otherwise strong identity gate, and data controls cannot compensate for bad authorisation upstream. The practitioner conclusion is to govern these pillars as one policy system, not three disconnected checklists.
Dynamic policy is where Zero Trust becomes governance rather than architecture. The CISA model only reaches its intended state when attributes, device posture, and resource sensitivity can influence access automatically. That means identity teams need to own the policy logic, not just the directory or authentication stack. The practitioner conclusion is that access governance must be measurable at runtime, or the maturity model remains theoretical.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- To see how identity programmes break down when secrets and access sprawl outpace governance, read Ultimate Guide to NHIs , Key Challenges and Risks.
What this signals
Runtime governance is the real maturity test. The CISA model makes clear that Zero Trust is not proven by architecture diagrams or policy declarations. It is proven when access decisions change in response to current conditions, and that shifts IAM from provisioning-centric administration to continuous governance across human and non-human identities.
Access reviews will not save a programme that cannot enforce policy in session. If entitlements are only checked after the fact, the organisation is managing evidence, not risk. Teams that still separate identity, workload, and data controls are likely to find that their weakest layer defines the real perimeter.
With 6 distinct secrets manager instances on average across organisations, fragmentation remains a practical obstacle to any policy-driven access model, according to The State of Secrets in AppSec. The next phase of Zero Trust will reward programmes that can unify telemetry and decisioning across identity, workload, and secrets governance.
For practitioners
- Map current controls to Zero Trust maturity stages Inventory identity, device, network, workload, and data controls separately, then classify each as Traditional, Advanced, or Optimal based on whether policy is static, partially coordinated, or dynamically enforced. Use the gaps to prioritise remediation by business risk.
- Tie session policy to current risk signals Require access decisions to consider device posture, observed behaviour, and resource sensitivity instead of relying only on initial authentication. This is the practical bridge between Zero Trust intent and runtime enforcement.
- Review workload access as an identity problem Treat application workloads and service access as governed identities, not just infrastructure dependencies. Align their permissions with per-session authorisation and audit the resulting access trail for excessive standing privilege.
- Use telemetry to prove enforcement is working Measure whether policy actually changes access outcomes across identity, workload, and data requests. A Zero Trust programme without evidence of runtime enforcement is a documentation exercise, not an operating model.
Key takeaways
- CISA’s model turns Zero Trust into a maturity problem, not a slogan, because access must be continuously evaluated across identity, workload, and data.
- The strongest signal of progress is runtime enforcement, especially where current risk and session context can alter access decisions.
- IAM teams should treat non-human identities and workloads as first-class subjects of Zero Trust governance, not infrastructure exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | CISA’s model is built on NIST Zero Trust principles and per-session access. | |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control maturity depends on how access is established and governed. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Workload and service identities need the same governance discipline as human access. |
Map high-risk access paths to NIST ZTA principles and enforce per-session verification where trust is still static.
Key terms
- Zero Trust Maturity Model: A maturity model is a staged way to measure how fully an organisation has adopted a security approach. In this case, the model describes how access governance moves from static controls to dynamic, continuously verified enforcement across identity, device, network, workload, and data domains.
- Per-session Access: Per-session access means access is granted for a specific interaction rather than as a durable entitlement that persists indefinitely. For identity governance, this shifts control from provisioning time to runtime, so policy must evaluate the current session before allowing or continuing access.
- Dynamic Policy: Dynamic policy is access logic that changes based on current conditions such as device posture, resource sensitivity, or observed behaviour. It is central to mature Zero Trust programmes because it turns access from a static approval into a live decision that can be updated as risk changes.
- Application Workload: An application workload is a running service, program, or system component that requests, receives, or processes access. In Zero Trust programmes, workloads must be treated as governed identities with explicit authorisation and telemetry, not as invisible infrastructure that can be broadly trusted.
Deepen your knowledge
Zero Trust maturity, per-session authorisation, and workload identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme that has to govern both human and non-human access, it is worth exploring.
This post draws on content published by StrongDM: CISA Zero Trust Maturity Model (TL;DR Version). Read the original.
Published by the NHIMG editorial team on 2025-10-17.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org