Lensatic · Framework Maps

Framework Maps

A guide to the United States public sector cybersecurity frameworks: what each one is for, how they fit together, who each one binds, and where zero trust and AI land.

Find your trailhead See the stack

Content version 1.2.14, latest source check 18 Oct 2026 · Why 'Lensatic'?

Start here: the trailheads

For anyone handed a framework, a maturity model, or a zero trust deadline and asked where it fits: federal civilian agencies, Department of War (DoW) components, defense contractors, and anyone else borrowing the United States federal models. Start at the trailhead that describes you.

Zero trust, the idea most of these documents serve, means nothing is trusted because of where it connects from: every request to reach data or a system is checked against policy each time.

Federal civilian agencyYou run or build systems for a federal civilian agency, and you have been told to do zero trust.7 steps · layers 1, 2, 3, 4, 5

Steps

Layer 1 Start with Executive Order (EO) 14028, section 3, which orders the move to zero trust architecture and sets the outcome for every civilian agency. EO 14028
Layer 3 Read the Office of Management and Budget (OMB) memorandum M-22-09 for the specific goals every agency must meet, due by the end of fiscal year 2024 and still binding, organized by the five pillars of the maturity model from the Cybersecurity and Infrastructure Security Agency (CISA). M-22-09, CISA ZTMM
Layer 2 Use National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207 for what zero trust means, so the program is an architecture and not a product list. SP 800-207
Layer 3 Place yourself on the CISA maturity model's four stages, pillar by pillar; the memo's goals are the floor, and the next stage is the plan. CISA ZTMM
Layer 4 Select and tailor SP 800-53 controls through the Risk Management Framework (RMF), so the target maps to controls your assessors test and your authorizing official signs. SP 800-53, RMF / ATO
Layer 1 Express the target as a Cybersecurity Framework (CSF) 2.0 Profile, which EO 13800 already directs your agency to use, so leadership can fund it in outcome language. CSF 2.0, EO 13800
Layer 5 Assess the controls against SP 800-53A, obtain and keep the authorization under the RMF, and keep current the zero trust implementation plan the memo had you file with OMB and CISA. RMF / ATO, M-22-09

DoW componentYou are a DoW component, or a program that reports to one, working toward Target Level zero trust.7 steps · layers 1, 3, 4, 5

Steps

Layer 3 Start with the DoD (Department of Defense) Zero Trust Strategy and its execution roadmap, which set the Target Level, the deadline, and the phasing; the implementing memorandum, directive-type memorandum (DTM) 25-003, passed its printed expiry on 17 July 2026 with no replacement found, so the FY2027 deadline rests on those two documents. Keep your component's zero trust implementation plan current and ask the zero trust portfolio office what it expects now: the strategy set the first plans due to the DoW CIO (Chief Information Officer) and JFHQ-DODIN (Joint Force Headquarters-Department of Defense Information Network), now the Cyber Defense Command, by 23 September 2023, and no current source repeats the yearly submission the DTM required. DoD ZT Strategy, DoD ZT Roadmap
Layer 3 Work the seven pillars and 45 capabilities as your model; each capability breaks into activities, 152 in all, and the 91 at Target Level come first, with the 61 at Advanced Level where the mission needs them; the roadmap offers three courses of action (uplift your own infrastructure, use a commercial cloud, or use an on-premises cloud the department or a component owns) and lets you mix them, and an enterprise service can deliver some activities for you (see Questions). DoD ZT Strategy, DoD ZT Roadmap
Layer 3 If you own control systems or other operational technology, work its zero trust activities and outcomes alongside the enterprise ones; they add to your existing cybersecurity requirements, and the document says separate guidance will be developed for weapon systems and defense critical infrastructure. ZT for OT
Layer 3 Use the National Security Agency (NSA) information sheets for each pillar and the 2026 implementation guidelines to sequence the activities. NSA ZT guidance
Layer 4 Apply the DoD Zero Trust Overlays to select the SP 800-53 controls that implement each capability; the overlays are not posted publicly in 2026, so ask your component or the zero trust portfolio office for the current copy. DoD ZT Overlays, SP 800-53
Layer 5 Show proof of each Target Level outcome to your authorizing official and the DoW CIO zero trust portfolio office, keep the Risk Management Framework (RMF) authorization current, and expect the Cyber Operational Readiness Assessment (CORA) to assess the readiness of the defended network; a system that cannot meet Target Level needs a waiver request to the portfolio office, renewed every year, for the CIO's approval. DoD ZT Strategy, RMF / ATO, CORA
Layer 1 Express the target as a Cybersecurity Framework (CSF) 2.0 Profile, which Executive Order (EO) 13800 directs every agency head to use, so leadership sees the program in outcome language. CSF 2.0, EO 13800

Defense contractor handling controlled unclassified information (CUI)You are a contractor or subcontractor that handles controlled unclassified information for a DoW customer.5 steps · layers 1, 2, 3, 4, 5

If you hold only federal contract information, the Federal Acquisition Regulation (FAR) basic safeguarding clause, 52.204-21 (52.240-93 in contracts written under the FAR overhaul deviations), sets your 15 requirements; if you hold controlled unclassified information for a civilian agency, that agency's own contract clauses name the requirements; the Everyone else trailhead covers both cases.

Steps

Layer 4 Start with Special Publication (SP) 800-171 Revision 2 from the National Institute of Standards and Technology (NIST), the 110 requirements that Defense Federal Acquisition Regulation Supplement (DFARS) clause 252.204-7012 and its class deviation make you meet for controlled unclassified information; Revision 3 is NIST's current edition and applies only when a contract says so. SP 800-171
Layer 5 Know your Cybersecurity Maturity Model Certification (CMMC) level from the contract's 252.204-7021 clause: Phase 1 self-assessments against SP 800-171 Revision 2 still run, and the certified-assessment phases are suspended as of July 2026. Two duties never paused: DFARS 252.204-7012, which also has you report cyber incidents, and the DFARS 252.204-7019 provision, which asks for a current SP 800-171 self-assessment score in the Supplier Performance Risk System (SPRS). CMMC
Layer 2 Use SP 800-207 for what zero trust means. No rule at this trailhead requires it of you; the DoD Zero Trust Strategy expects the Defense Industrial Base to execute it, and it reaches you through what a customer writes into a contract. SP 800-207, DoD ZT Strategy
Layer 3 Borrow whichever model your customer uses, the DoW seven pillars or the CISA maturity model, so your target state speaks their language; for a DoW customer that is the seven-pillar view. DoD ZT Strategy, CISA ZTMM
Layer 1 Use the Cybersecurity Framework (CSF) 2.0 to tell leadership and customers where you are and where you are going. CSF 2.0

Everyone elseYou are a company, a state or local government, a university, or anyone else with no federal mandate to meet.Nothing on this stack binds you by its own force; a government contract can, and the two cases below say how.

Use the Cybersecurity Framework (CSF) 2.0 from the National Institute of Standards and Technology (NIST) to say what good looks like, NIST Special Publication (SP) 800-207 to define zero trust, the zero trust maturity model of the Cybersecurity and Infrastructure Security Agency (CISA) to set a target (its four stages are public and written to be borrowed), and SP 800-53, or a smaller catalog such as the Center for Internet Security (CIS) Controls, for controls. If a customer or regulator names a framework, start from that one and work up and down the stack from there. Verification is whoever checks your evidence: an internal audit, a certifier, or a customer assessment; the layer 5 entries here are federal. If you hold federal contract information or controlled unclassified information for a government customer, the two cases below say what applies; if you hold controlled unclassified information under a DoW contract, start at the contractor trailhead.

Federal contract information only

Federal contract information is information not intended for public release that is provided by or generated for the government under a contract. If you hold only federal contract information for any agency, the Federal Acquisition Regulation (FAR) basic safeguarding clause, 52.204-21 (52.240-93 in contracts written under the FAR overhaul deviations), sets your 15 requirements, and on a DoW contract that carries the Cybersecurity Maturity Model Certification (CMMC) clause, Level 1 is a self-assessment against those same 15. Nothing else on this stack binds you; use CSF 2.0 to talk about the rest. CMMC, CSF 2.0

Controlled unclassified information for a civilian agency

Controlled unclassified information is government information that is not classified but that a law, regulation or government-wide policy requires or permits agencies to safeguard or control. If you hold controlled unclassified information for a civilian agency, your contract clause names the requirements, normally a revision of SP 800-171, and the assessment the clause specifies proves them; CMMC does not apply. Use SP 800-207 for what zero trust means, the CISA maturity model if the agency asks for a target, and CSF 2.0 to tell the agency where you stand. SP 800-171, SP 800-207, CISA ZTMM, CSF 2.0

Pick the trailhead that describes you. Steps run in the order you do them; the layer tag on each step shows where it sits on the stack below.

The stack

The stack sorts the frameworks by the question each one answers: five layers, from the outcomes leadership funds down to who checks the evidence, with an AI column beside them. Solid chips are frameworks, dashed chips are other guides and memos placed on a layer, and dotted chips are solutions measured against a layer.

SP (Special Publication) 800-207 defines zero trust architecture: no implicit trust from network location, and every request decided by a policy engine and then allowed or blocked at a policy enforcement point. CSF (Cybersecurity Framework) 2.0 gives an organization six functions, Profiles, and Tiers to describe cybersecurity outcomes in language leadership funds against. SP 800-53 is the catalog of security and privacy controls that federal systems select from, and that CSF references and the zero trust overlays both point into. The AI RMF (Artificial Intelligence Risk Management Framework) gives an organization four functions, Govern, Map, Measure, and Manage, to handle the risks of AI systems in outcome language. The Cyber AI Profile is a draft CSF 2.0 Community Profile that crosses the six functions with three focus areas: securing AI system components, conducting AI-enabled cyber defense, and thwarting AI-enabled cyber attacks. The AI Defense Matrix lays the six CSF 2.0 functions across eight AI-specific asset classes, from models and training data to agent identities, the same two-axis move the zero trust matrix makes.

01 Outcomes and communication

What does good look like, in the language leadership funds against?

The layer that states outcomes in the words leadership already uses, so a security program can be discussed, funded, and measured without technical detail.

CSF 2.0

02 Definition

What is zero trust?

The layer the models and the memo all cite for what zero trust means; read it when a vendor or a score tries to redefine the word.

SP 800-207

03 Target state and maturity

How mature are we, and what is the target?

The layer that turns the definition into pillars, capabilities, and a maturity ladder with a target to reach.

DoD ZT Strategy CISA ZTMM NSA ZT guidance ZT for OT

Validated solutions measured against this layer

Thunderdome Flank Speed

04 Controls

Which controls implement the outcomes?

The layer where outcomes and capabilities become specific controls an engineer can build and an assessor can test.

SP 800-53 DoD ZT Overlays SP 1800-35

05 Verification

What does the inspector or assessor check?

The layer where someone outside the team checks the evidence: an inspector, an assessor, or whoever decides that the system may operate; in federal systems that is the authorizing official.

CORA RMF / ATO

The matrix

Rows are the six functions of the NIST (National Institute of Standards and Technology) Cybersecurity Framework (CSF) 2.0; columns are the zero trust pillars, the areas of an enterprise that zero trust covers, such as users, devices and data. Each cell says what that function looks like in that pillar. Codes such as GV.PO are CSF 2.0 categories, spelled out in the function cards; the numbers in the Department of War (DoW) model are its capability numbers, pillar first.

Jump to: DoW model: seven pillars, with capability numbers; CISA (Cybersecurity and Infrastructure Security Agency) model: five pillars plus three cross-cutting capabilities; the same sentences by function

The tables scroll sideways, one pillar per column. The six functions section repeats each cell's first sentence in one column.

DoW model: seven pillars, with capability numbers

Function	User	Device	Application & Workload	Data	Network & Environment	Automation & Orchestration	Visibility & Analytics
GV Govern	Policy names who may access what, under which conditions, and who owns the identity rules the policy engine enforces. Identity risk is part of the enterprise risk strategy. Categories: GV.PO, GV.RR, GV.RM	Policy sets what a device must prove before it may connect, and a named owner holds device trust, including trust in the hardware and software supply chain. Categories: GV.PO, GV.SC, GV.RR	Capabilities 3.3Policy covers how applications and workloads authenticate, authorize, and are approved for use, and trust in the software supply chain is a governance concern. Categories: GV.PO, GV.SC, GV.RR Capabilities: 3.3 Software Risk Management	Capabilities 4.2 4.1Policy defines data categories, handling rules, and who owns each data set, and data risk is part of the enterprise risk strategy. Categories: GV.PO, GV.RR, GV.RM Capabilities: 4.2 DoD Enterprise Data Governance; 4.1 Data Catalog Risk Alignment	Policy replaces location with identity and context as the basis for access, and a named owner holds the segmentation and network access rules. Categories: GV.PO, GV.RR, GV.RM	Capabilities 6.1Policy sets which decisions may be automated and which need a human, and names who owns the orchestration of policy changes. Categories: GV.PO, GV.RR Capabilities: 6.1 Policy Decision Point (PDP) & Policy Orchestration	Capabilities 7.1Policy requires that every access decision and control produce telemetry, and oversight uses that telemetry to check whether the program works. Categories: GV.PO, GV.OV Capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users)
ID Identify	Capabilities 1.1 1.6An inventory of users, roles, and privileges, including service and non-person accounts, kept current. Identity risk signals feed access decisions. Categories: ID.AM, ID.RA Capabilities: 1.1 User Inventory; 1.6 Behavioral, Contextual ID, and Biometrics	Capabilities 2.1 2.2An inventory of every device, managed or not, with an owner, a posture, and a risk rating. Categories: ID.AM, ID.RA Capabilities: 2.1 Device Inventory; 2.2 Device Detection and Compliance	Capabilities 3.1An inventory of applications, workloads, interfaces, and their data flows, with owners and risk ratings. Categories: ID.AM, ID.RA Capabilities: 3.1 Application Inventory	Capabilities 4.1 4.3Data is inventoried, labeled and tagged, and the risk to each category is assessed. Categories: ID.AM, ID.RA Capabilities: 4.1 Data Catalog Risk Alignment; 4.3 Data Labeling and Tagging	Capabilities 5.1Network flows, segments, and dependencies are mapped, and the risk of each path is assessed. Categories: ID.AM, ID.RA Capabilities: 5.1 Data Flow Mapping	Capabilities 6.5Automated runbooks and the systems they touch are inventoried, and the risk of automated action is assessed. Categories: ID.AM, ID.RA Capabilities: 6.5 Security Orchestration, Automation & Response (SOAR)	Capabilities 7.1 7.3Telemetry sources are inventoried, and gaps in visibility are treated as risks to close. Categories: ID.AM, ID.RA, ID.IM Capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 7.3 Common Security and Risk Analytics
PR Protect	Capabilities 1.3 1.7 1.2 1.4 1.9Phishing-resistant multi-factor authentication for people, certificate or managed identities for non-person accounts, least privilege, and a per-request access decision for every account. Categories: PR.AA Capabilities: 1.3 Multi-Factor Authentication (MFA); 1.7 Least Privileged Access; 1.2 Conditional User Access; 1.4 Privileged Access Management (PAM); 1.9 Integrated ICAM Platform	Capabilities 2.2 2.3 2.5 2.6Device posture (patch level, configuration, health) is checked before and during access, and access is denied or limited when posture fails. Categories: PR.AA, PR.PS Capabilities: 2.2 Device Detection and Compliance; 2.3 Device Authorization w/ Real Time Inspection; 2.5 Partially & Fully Automated Asset, Vulnerability and Patch Management; 2.6 Unified Endpoint Management (UEM) & Mobile Device Management (MDM)	Capabilities 3.4 3.2 1.7Every application call is authenticated and authorized, workloads run with least privilege, and secure development and deployment practices are enforced. Categories: PR.AA, PR.PS Capabilities: 3.4 Resource Authorization & Integration; 3.2 Secure Software Development & Integration; 1.7 Least Privileged Access	Capabilities 4.5 4.7 4.6Data is encrypted at rest and in transit, access is granted per request based on the data's label, and loss prevention controls apply. Categories: PR.DS, PR.AA Capabilities: 4.5 Data Encryption & Rights Management; 4.7 Data Access Control; 4.6 Data Loss Prevention (DLP)	Capabilities 5.2 5.3 5.4The network is segmented, traffic is encrypted, and each connection is authorized rather than trusted because of where it starts. Categories: PR.IR, PR.AA, PR.DS Capabilities: 5.2 Software Defined Networking (SDN); 5.3 Macro Segmentation; 5.4 Micro Segmentation	Capabilities 6.1 6.2Access decisions are made and enforced by machine at the speed of each request, and configuration is enforced through automation rather than by hand. Categories: PR.AA, PR.PS Capabilities: 6.1 Policy Decision Point (PDP) & Policy Orchestration; 6.2 Critical Process Automation	Capabilities 7.6Log records are generated for every access decision and made available for monitoring, logs and telemetry are protected as data in their own right, and analytics results feed the policy engine's access decisions. Categories: PR.PS, PR.DS, PR.AA Capabilities: 7.6 Automated Dynamic Policies
DE Detect	Capabilities 1.6 1.8 7.4User and privileged-account activity is baselined and analyzed for anomalies, and identity risk is scored continuously so that a session can be challenged or ended mid-flight, not only at the next sign-in. Categories: DE.CM, DE.AE Capabilities: 1.6 Behavioral, Contextual ID, and Biometrics; 1.8 Continuous Authentication; 7.4 User and Entity Behavior Analytics	Capabilities 2.2 2.7Every device that connects is detected and has its compliance confirmed, endpoint telemetry feeds detection and response tooling, and a device that drifts out of posture surfaces as an event and is reflected in its next access decision. Categories: DE.CM, DE.AE Capabilities: 2.2 Device Detection and Compliance; 2.7 Endpoint & Extended Detection & Response (EDR & XDR)	Capabilities 3.5 7.2Applications and workloads are monitored continuously, which keeps their authorization to operate current, and are checked against their profile and behavior baselines; unexpected calls or state changes are correlated with identity and device telemetry to characterize the event. Categories: DE.CM, DE.AE Capabilities: 3.5 Continuous Monitoring and Ongoing Authorizations; 7.2 Security Information and Event Management (SIEM)	Capabilities 4.4 4.6 7.1Access, sharing, transformation, and use of data are captured as active metadata in every state, loss-prevention sensing flags exfiltration attempts, and unusual access patterns are analyzed against the data's label and its normal use. Categories: DE.CM, DE.AE Capabilities: 4.4 Data Monitoring and Sensing; 4.6 Data Loss Prevention (DLP); 7.1 Log All Traffic (Network, Data, Apps, Users)	Capabilities 7.1 5.1All traffic, including traffic inside the perimeter, is logged and analyzed, decrypted for inspection only where policy allows, and unusual flows are characterized and correlated across sources. Categories: DE.CM, DE.AE Capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 5.1 Data Flow Mapping	Capabilities 6.5 7.2Detection rules run automatically across the telemetry, and alerts are triaged by machine before a human sees them. Categories: DE.CM, DE.AE Capabilities: 6.5 Security Orchestration, Automation & Response (SOAR); 7.2 Security Information and Event Management (SIEM)	Capabilities 7.1 7.2 7.3 7.4 7.5Telemetry from users, devices, networks, applications, and data is collected in one security information and event management (SIEM) platform, enriched with threat intelligence, and correlated across pillars continuously, so activity that looks normal in one pillar and abnormal across several surfaces as an event. Categories: DE.CM, DE.AE Capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 7.2 Security Information and Event Management (SIEM); 7.3 Common Security and Risk Analytics; 7.4 User and Entity Behavior Analytics; 7.5 Threat Intelligence Integration
RS Respond	Capabilities 1.2 1.4 6.1 1.5Credentials and sessions are revoked or stepped down at once when an incident touches an identity, and the policy engine tightens access automatically. Categories: RS.MA, RS.MI Capabilities: 1.2 Conditional User Access; 1.4 Privileged Access Management (PAM); 6.1 Policy Decision Point (PDP) & Policy Orchestration; 1.5 Identity Federation & User Credentialing	Capabilities 2.7 2.2A compromised device is isolated automatically and its access is cut off while the incident is handled. Categories: RS.MA, RS.MI Capabilities: 2.7 Endpoint & Extended Detection & Response (EDR & XDR); 2.2 Device Detection and Compliance	Capabilities 3.4 6.5A misbehaving workload is isolated at its enforcement point, its service credentials and tokens are revoked so the policy engine denies its calls, and its state is captured for analysis before it is stopped or torn down. Categories: RS.MA, RS.MI, RS.AN Capabilities: 3.4 Resource Authorization & Integration; 6.5 Security Orchestration, Automation & Response (SOAR)	Capabilities 4.6 4.7Access to affected data is restricted at once, and the exposure is analyzed and reported to the people who must know. Categories: RS.MA, RS.AN, RS.CO, RS.MI Capabilities: 4.6 Data Loss Prevention (DLP); 4.7 Data Access Control	Capabilities 5.3 5.4 5.2Segments and paths are closed or re-routed quickly to contain an incident. Categories: RS.MA, RS.MI Capabilities: 5.3 Macro Segmentation; 5.4 Micro Segmentation; 5.2 Software Defined Networking (SDN)	Capabilities 6.5 6.7Containment, policy change, and notification are orchestrated automatically, with a human in the loop where policy requires one. Categories: RS.MA, RS.MI, RS.CO Capabilities: 6.5 Security Orchestration, Automation & Response (SOAR); 6.7 Security Operations Center (SOC) & Incident Response (IR)	Capabilities 7.2 7.3Retained logs and analytics let responders establish what happened and its root cause, incident data is collected with its integrity and provenance preserved, and telemetry confirms that containment worked. Categories: RS.AN, RS.MA Capabilities: 7.2 Security Information and Event Management (SIEM); 7.3 Common Security and Risk Analytics
RC Recover	Capabilities 1.4 1.2 1.5After an incident, compromised credentials are rotated, standing privileges are re-approved rather than restored wholesale, and affected users are told what changed as their access is re-enabled. Categories: RC.RP, RC.CO Capabilities: 1.4 Privileged Access Management (PAM); 1.2 Conditional User Access; 1.5 Identity Federation & User Credentialing	Capabilities 2.2 2.5 2.1A rebuilt or restored device re-enrolls, re-attests its configuration and patch state, and passes the compliance check again before it regains any access, and the restoration is confirmed to the people who depend on it. Categories: RC.RP, RC.CO Capabilities: 2.2 Device Detection and Compliance; 2.5 Partially & Fully Automated Asset, Vulnerability and Patch Management; 2.1 Device Inventory	Capabilities 3.2 3.5 3.3Workloads are redeployed from a verified, known-good build through the normal pipeline rather than patched in place, and their authorization is re-established. Application owners are told when the redeployed workload is back in service, and what was learned changes the deployment checks. Categories: RC.RP, RC.CO, ID.IM Capabilities: 3.2 Secure Software Development & Integration; 3.5 Continuous Monitoring and Ongoing Authorizations; 3.3 Software Risk Management	Capabilities 4.5 4.7 4.3Data is restored from backups whose integrity is verified first, restored records keep their labels and access rules, and the owners and any external parties are told what was restored and when. Categories: RC.RP, RC.CO Capabilities: 4.5 Data Encryption & Rights Management; 4.7 Data Access Control; 4.3 Data Labeling and Tagging	Capabilities 5.3 5.4 5.1Segments and paths closed during containment are reopened in priority order as their integrity is confirmed, and resilience configurations absorb the shifted load. Normal traffic patterns are verified against the flow map before trust is widened, and the reopening order is reported to the mission owners who depend on each path. Categories: RC.RP, RC.CO Capabilities: 5.3 Macro Segmentation; 5.4 Micro Segmentation; 5.1 Data Flow Mapping	Capabilities 6.5 6.7 6.2Recovery runbooks execute the restoration steps that can be automated in a set order, and the orchestrator's step log is what the recovery status reported to stakeholders is drawn from. The runbooks are revised from the incident before the next use. Categories: RC.RP, RC.CO, ID.IM Capabilities: 6.5 Security Orchestration, Automation & Response (SOAR); 6.7 Security Operations Center (SOC) & Incident Response (IR); 6.2 Critical Process Automation	Capabilities 7.1 7.2 7.3Telemetry confirms that restored assets behave as their baselines predict before recovery is declared complete, and recovery progress is reported from the telemetry rather than from estimates. The incident's timeline, assembled from the logs, is what the lessons-learned review works from. Categories: RC.RP, RC.CO, ID.IM Capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 7.2 Security Information and Event Management (SIEM); 7.3 Common Security and Risk Analytics

CISA model: five pillars plus three cross-cutting capabilities

Function	Identity	Devices	Networks	Applications and Workloads	Data	Visibility and Analytics (cross-cutting)	Automation and Orchestration (cross-cutting)	Governance (cross-cutting)
GV Govern	Policy names who may access what, under which conditions, and who owns the identity rules the policy engine enforces. Identity risk is part of the enterprise risk strategy. Categories: GV.PO, GV.RR, GV.RM	Policy sets what a device must prove before it may connect, and a named owner holds device trust, including trust in the hardware and software supply chain. Categories: GV.PO, GV.SC, GV.RR	Policy replaces location with identity and context as the basis for access, and a named owner holds the segmentation and network access rules. Categories: GV.PO, GV.RR, GV.RM	Policy covers how applications and workloads authenticate, authorize, and are approved for use, and trust in the software supply chain is a governance concern. Categories: GV.PO, GV.SC, GV.RR DoW capabilities: 3.3 Software Risk Management	Policy defines data categories, handling rules, and who owns each data set, and data risk is part of the enterprise risk strategy. Categories: GV.PO, GV.RR, GV.RM DoW capabilities: 4.2 DoD Enterprise Data Governance; 4.1 Data Catalog Risk Alignment	Policy requires that every access decision and control produce telemetry, and oversight uses that telemetry to check whether the program works. Categories: GV.PO, GV.OV DoW capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users)	Policy sets which decisions may be automated and which need a human, and names who owns the orchestration of policy changes. Categories: GV.PO, GV.RR DoW capabilities: 6.1 Policy Decision Point (PDP) & Policy Orchestration	Who may change the policy engine's rules, who funds the program, and how oversight learns whether it works; the policy, its named owner, and the risk strategy that prioritizes the program live here. Categories: GV.PO, GV.RR, GV.RM, GV.OC, GV.OV
ID Identify	An inventory of users, roles, and privileges, including service and non-person accounts, kept current. Identity risk signals feed access decisions. Categories: ID.AM, ID.RA DoW capabilities: 1.1 User Inventory; 1.6 Behavioral, Contextual ID, and Biometrics	An inventory of every device, managed or not, with an owner, a posture, and a risk rating. Categories: ID.AM, ID.RA DoW capabilities: 2.1 Device Inventory; 2.2 Device Detection and Compliance	Network flows, segments, and dependencies are mapped, and the risk of each path is assessed. Categories: ID.AM, ID.RA DoW capabilities: 5.1 Data Flow Mapping	An inventory of applications, workloads, interfaces, and their data flows, with owners and risk ratings. Categories: ID.AM, ID.RA DoW capabilities: 3.1 Application Inventory	Data is inventoried, labeled and tagged, and the risk to each category is assessed. Categories: ID.AM, ID.RA DoW capabilities: 4.1 Data Catalog Risk Alignment; 4.3 Data Labeling and Tagging	Telemetry sources are inventoried, and gaps in visibility are treated as risks to close. Categories: ID.AM, ID.RA, ID.IM DoW capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 7.3 Common Security and Risk Analytics	Automated runbooks and the systems they touch are inventoried, and the risk of automated action is assessed. Categories: ID.AM, ID.RA DoW capabilities: 6.5 Security Orchestration, Automation & Response (SOAR)	Risk assessment finds where implicit trust remains, and improvement plans close those gaps in priority order. Categories: ID.RA, ID.IM
PR Protect	Phishing-resistant multi-factor authentication for people, certificate or managed identities for non-person accounts, least privilege, and a per-request access decision for every account. Categories: PR.AA DoW capabilities: 1.3 Multi-Factor Authentication (MFA); 1.7 Least Privileged Access; 1.2 Conditional User Access; 1.4 Privileged Access Management (PAM); 1.9 Integrated ICAM Platform	Device posture (patch level, configuration, health) is checked before and during access, and access is denied or limited when posture fails. Categories: PR.AA, PR.PS DoW capabilities: 2.2 Device Detection and Compliance; 2.3 Device Authorization w/ Real Time Inspection; 2.5 Partially & Fully Automated Asset, Vulnerability and Patch Management; 2.6 Unified Endpoint Management (UEM) & Mobile Device Management (MDM)	The network is segmented, traffic is encrypted, and each connection is authorized rather than trusted because of where it starts. Categories: PR.IR, PR.AA, PR.DS DoW capabilities: 5.2 Software Defined Networking (SDN); 5.3 Macro Segmentation; 5.4 Micro Segmentation	Every application call is authenticated and authorized, workloads run with least privilege, and secure development and deployment practices are enforced. Categories: PR.AA, PR.PS DoW capabilities: 3.4 Resource Authorization & Integration; 3.2 Secure Software Development & Integration; 1.7 Least Privileged Access	Data is encrypted at rest and in transit, access is granted per request based on the data's label, and loss prevention controls apply. Categories: PR.DS, PR.AA DoW capabilities: 4.5 Data Encryption & Rights Management; 4.7 Data Access Control; 4.6 Data Loss Prevention (DLP)	Log records are generated for every access decision and made available for monitoring, logs and telemetry are protected as data in their own right, and analytics results feed the policy engine's access decisions. Categories: PR.PS, PR.DS, PR.AA DoW capabilities: 7.6 Automated Dynamic Policies	Access decisions are made and enforced by machine at the speed of each request, and configuration is enforced through automation rather than by hand. Categories: PR.AA, PR.PS DoW capabilities: 6.1 Policy Decision Point (PDP) & Policy Orchestration; 6.2 Critical Process Automation	Policy owners approve the rules the policy engine enforces, and training builds the skills the program needs. Categories: PR.AA, PR.AT
DE Detect	User and privileged-account activity is baselined and analyzed for anomalies, and identity risk is scored continuously so that a session can be challenged or ended mid-flight, not only at the next sign-in. Categories: DE.CM, DE.AE DoW capabilities: 1.6 Behavioral, Contextual ID, and Biometrics; 1.8 Continuous Authentication; 7.4 User and Entity Behavior Analytics	Every device that connects is detected and has its compliance confirmed, endpoint telemetry feeds detection and response tooling, and a device that drifts out of posture surfaces as an event and is reflected in its next access decision. Categories: DE.CM, DE.AE DoW capabilities: 2.2 Device Detection and Compliance; 2.7 Endpoint & Extended Detection & Response (EDR & XDR)	All traffic, including traffic inside the perimeter, is logged and analyzed, decrypted for inspection only where policy allows, and unusual flows are characterized and correlated across sources. Categories: DE.CM, DE.AE DoW capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 5.1 Data Flow Mapping	Applications and workloads are monitored continuously, which keeps their authorization to operate current, and are checked against their profile and behavior baselines; unexpected calls or state changes are correlated with identity and device telemetry to characterize the event. Categories: DE.CM, DE.AE DoW capabilities: 3.5 Continuous Monitoring and Ongoing Authorizations; 7.2 Security Information and Event Management (SIEM)	Access, sharing, transformation, and use of data are captured as active metadata in every state, loss-prevention sensing flags exfiltration attempts, and unusual access patterns are analyzed against the data's label and its normal use. Categories: DE.CM, DE.AE DoW capabilities: 4.4 Data Monitoring and Sensing; 4.6 Data Loss Prevention (DLP); 7.1 Log All Traffic (Network, Data, Apps, Users)	Telemetry from users, devices, networks, applications, and data is collected in one security information and event management (SIEM) platform, enriched with threat intelligence, and correlated across pillars continuously, so activity that looks normal in one pillar and abnormal across several surfaces as an event. Categories: DE.CM, DE.AE DoW capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 7.2 Security Information and Event Management (SIEM); 7.3 Common Security and Risk Analytics; 7.4 User and Entity Behavior Analytics; 7.5 Threat Intelligence Integration	Detection rules run automatically across the telemetry, and alerts are triaged by machine before a human sees them. Categories: DE.CM, DE.AE DoW capabilities: 6.5 Security Orchestration, Automation & Response (SOAR); 7.2 Security Information and Event Management (SIEM)	Oversight reviews detection coverage and results against the policy, and gaps are handed back to the owners. Categories: DE.CM, DE.AE
RS Respond	Credentials and sessions are revoked or stepped down at once when an incident touches an identity, and the policy engine tightens access automatically. Categories: RS.MA, RS.MI DoW capabilities: 1.2 Conditional User Access; 1.4 Privileged Access Management (PAM); 6.1 Policy Decision Point (PDP) & Policy Orchestration; 1.5 Identity Federation & User Credentialing	A compromised device is isolated automatically and its access is cut off while the incident is handled. Categories: RS.MA, RS.MI DoW capabilities: 2.7 Endpoint & Extended Detection & Response (EDR & XDR); 2.2 Device Detection and Compliance	Segments and paths are closed or re-routed quickly to contain an incident. Categories: RS.MA, RS.MI DoW capabilities: 5.3 Macro Segmentation; 5.4 Micro Segmentation; 5.2 Software Defined Networking (SDN)	A misbehaving workload is isolated at its enforcement point, its service credentials and tokens are revoked so the policy engine denies its calls, and its state is captured for analysis before it is stopped or torn down. Categories: RS.MA, RS.MI, RS.AN DoW capabilities: 3.4 Resource Authorization & Integration; 6.5 Security Orchestration, Automation & Response (SOAR)	Access to affected data is restricted at once, and the exposure is analyzed and reported to the people who must know. Categories: RS.MA, RS.AN, RS.CO, RS.MI DoW capabilities: 4.6 Data Loss Prevention (DLP); 4.7 Data Access Control	Retained logs and analytics let responders establish what happened and its root cause, incident data is collected with its integrity and provenance preserved, and telemetry confirms that containment worked. Categories: RS.AN, RS.MA DoW capabilities: 7.2 Security Information and Event Management (SIEM); 7.3 Common Security and Risk Analytics	Containment, policy change, and notification are orchestrated automatically, with a human in the loop where policy requires one. Categories: RS.MA, RS.MI, RS.CO DoW capabilities: 6.5 Security Orchestration, Automation & Response (SOAR); 6.7 Security Operations Center (SOC) & Incident Response (IR)	Incident authority and escalation are set by policy, and the policy owner decides when the policy engine's rules change during an incident. Categories: RS.MA, RS.CO
RC Recover	After an incident, compromised credentials are rotated, standing privileges are re-approved rather than restored wholesale, and affected users are told what changed as their access is re-enabled. Categories: RC.RP, RC.CO DoW capabilities: 1.4 Privileged Access Management (PAM); 1.2 Conditional User Access; 1.5 Identity Federation & User Credentialing	A rebuilt or restored device re-enrolls, re-attests its configuration and patch state, and passes the compliance check again before it regains any access, and the restoration is confirmed to the people who depend on it. Categories: RC.RP, RC.CO DoW capabilities: 2.2 Device Detection and Compliance; 2.5 Partially & Fully Automated Asset, Vulnerability and Patch Management; 2.1 Device Inventory	Segments and paths closed during containment are reopened in priority order as their integrity is confirmed, and resilience configurations absorb the shifted load. Normal traffic patterns are verified against the flow map before trust is widened, and the reopening order is reported to the mission owners who depend on each path. Categories: RC.RP, RC.CO DoW capabilities: 5.3 Macro Segmentation; 5.4 Micro Segmentation; 5.1 Data Flow Mapping	Workloads are redeployed from a verified, known-good build through the normal pipeline rather than patched in place, and their authorization is re-established. Application owners are told when the redeployed workload is back in service, and what was learned changes the deployment checks. Categories: RC.RP, RC.CO, ID.IM DoW capabilities: 3.2 Secure Software Development & Integration; 3.5 Continuous Monitoring and Ongoing Authorizations; 3.3 Software Risk Management	Data is restored from backups whose integrity is verified first, restored records keep their labels and access rules, and the owners and any external parties are told what was restored and when. Categories: RC.RP, RC.CO DoW capabilities: 4.5 Data Encryption & Rights Management; 4.7 Data Access Control; 4.3 Data Labeling and Tagging	Telemetry confirms that restored assets behave as their baselines predict before recovery is declared complete, and recovery progress is reported from the telemetry rather than from estimates. The incident's timeline, assembled from the logs, is what the lessons-learned review works from. Categories: RC.RP, RC.CO, ID.IM DoW capabilities: 7.1 Log All Traffic (Network, Data, Apps, Users); 7.2 Security Information and Event Management (SIEM); 7.3 Common Security and Risk Analytics	Recovery runbooks execute the restoration steps that can be automated in a set order, and the orchestrator's step log is what the recovery status reported to stakeholders is drawn from. The runbooks are revised from the incident before the next use. Categories: RC.RP, RC.CO, ID.IM DoW capabilities: 6.5 Security Orchestration, Automation & Response (SOAR); 6.7 Security Operations Center (SOC) & Incident Response (IR); 6.2 Critical Process Automation	The policy owner declares the end of recovery against defined criteria, sets the post-incident operating norms for the program, and signs off the internal and public recovery communications. Categories: RC.CO, RC.RP

The six functions

GV Govern

Who owns cyber risk, and how is it woven into enterprise strategy?

Categories

GV.OC Organizational Context
GV.RM Risk Management Strategy
GV.RR Roles, Responsibilities, and Authorities
GV.PO Policy
GV.OV Oversight
GV.SC Cybersecurity Supply Chain Risk Management

Where zero trust lands

The zero trust policy itself, the owner of the policy engine, and device and software trust in the supply chain.

User and identity: Policy names who may access what, under which conditions, and who owns the identity rules the policy engine enforces.
Device: Policy sets what a device must prove before it may connect, and a named owner holds device trust, including trust in the hardware and software supply chain.
Network and environment: Policy replaces location with identity and context as the basis for access, and a named owner holds the segmentation and network access rules.
Application and workload: Policy covers how applications and workloads authenticate, authorize, and are approved for use, and trust in the software supply chain is a governance concern.
Data: Policy defines data categories, handling rules, and who owns each data set, and data risk is part of the enterprise risk strategy.
Visibility and analytics: Policy requires that every access decision and control produce telemetry, and oversight uses that telemetry to check whether the program works.
Automation and orchestration: Policy sets which decisions may be automated and which need a human, and names who owns the orchestration of policy changes.
Governance: Who may change the policy engine's rules, who funds the program, and how oversight learns whether it works; the policy, its named owner, and the risk strategy that prioritizes the program live here.

ID Identify

What do we have, and what are the risks to it?

Categories

ID.AM Asset Management
ID.RA Risk Assessment
ID.IM Improvement

Where zero trust lands

User, device, network, application, and data inventories, the risk signals that feed access decisions, and the improvements that tests, exercises and incidents feed back into the program.

User and identity: An inventory of users, roles, and privileges, including service and non-person accounts, kept current.
Device: An inventory of every device, managed or not, with an owner, a posture, and a risk rating.
Network and environment: Network flows, segments, and dependencies are mapped, and the risk of each path is assessed.
Application and workload: An inventory of applications, workloads, interfaces, and their data flows, with owners and risk ratings.
Data: Data is inventoried, labeled and tagged, and the risk to each category is assessed.
Visibility and analytics: Telemetry sources are inventoried, and gaps in visibility are treated as risks to close.
Automation and orchestration: Automated runbooks and the systems they touch are inventoried, and the risk of automated action is assessed.
Governance: Risk assessment finds where implicit trust remains, and improvement plans close those gaps in priority order.

PR Protect

What safeguards manage those risks?

Categories

PR.AA Identity Management, Authentication, and Access Control
PR.AT Awareness and Training
PR.DS Data Security
PR.PS Platform Security
PR.IR Technology Infrastructure Resilience

Where zero trust lands

The core: multi-factor authentication, least privilege, and per-request access (PR.AA); encryption and data loss prevention (PR.DS); segmentation (PR.IR).

User and identity: Phishing-resistant multi-factor authentication for people, certificate or managed identities for non-person accounts, least privilege, and a per-request access decision for every account.
Device: Device posture (patch level, configuration, health) is checked before and during access, and access is denied or limited when posture fails.
Network and environment: The network is segmented, traffic is encrypted, and each connection is authorized rather than trusted because of where it starts.
Application and workload: Every application call is authenticated and authorized, workloads run with least privilege, and secure development and deployment practices are enforced.
Data: Data is encrypted at rest and in transit, access is granted per request based on the data's label, and loss prevention controls apply.
Visibility and analytics: Log records are generated for every access decision and made available for monitoring, logs and telemetry are protected as data in their own right, and analytics results feed the policy engine's access decisions.
Automation and orchestration: Access decisions are made and enforced by machine at the speed of each request, and configuration is enforced through automation rather than by hand.
Governance: Policy owners approve the rules the policy engine enforces, and training builds the skills the program needs.

DE Detect

How do we find and analyze adverse events?

Categories

DE.CM Continuous Monitoring
DE.AE Adverse Event Analysis

Where zero trust lands

Continuous verification, telemetry, and behavioral analytics.

User and identity: User and privileged-account activity is baselined and analyzed for anomalies, and identity risk is scored continuously so that a session can be challenged or ended mid-flight, not only at the next sign-in.
Device: Every device that connects is detected and has its compliance confirmed, endpoint telemetry feeds detection and response tooling, and a device that drifts out of posture surfaces as an event and is reflected in its next access decision.
Network and environment: All traffic, including traffic inside the perimeter, is logged and analyzed, decrypted for inspection only where policy allows, and unusual flows are characterized and correlated across sources.
Application and workload: Applications and workloads are monitored continuously, which keeps their authorization to operate current, and are checked against their profile and behavior baselines; unexpected calls or state changes are correlated with identity and device telemetry to characterize the event.
Data: Access, sharing, transformation, and use of data are captured as active metadata in every state, loss-prevention sensing flags exfiltration attempts, and unusual access patterns are analyzed against the data's label and its normal use.
Visibility and analytics: Telemetry from users, devices, networks, applications, and data is collected in one security information and event management (SIEM) platform, enriched with threat intelligence, and correlated across pillars continuously, so activity that looks normal in one pillar and abnormal across several surfaces as an event.
Automation and orchestration: Detection rules run automatically across the telemetry, and alerts are triaged by machine before a human sees them.
Governance: Oversight reviews detection coverage and results against the policy, and gaps are handed back to the owners.

RS Respond

What do we do when something happens?

Categories

RS.MA Incident Management
RS.AN Incident Analysis
RS.CO Incident Response Reporting and Communication
RS.MI Incident Mitigation

Where zero trust lands

Automated policy change, containment, and orchestration.

User and identity: Credentials and sessions are revoked or stepped down at once when an incident touches an identity, and the policy engine tightens access automatically.
Device: A compromised device is isolated automatically and its access is cut off while the incident is handled.
Network and environment: Segments and paths are closed or re-routed quickly to contain an incident.
Application and workload: A misbehaving workload is isolated at its enforcement point, its service credentials and tokens are revoked so the policy engine denies its calls, and its state is captured for analysis before it is stopped or torn down.
Data: Access to affected data is restricted at once, and the exposure is analyzed and reported to the people who must know.
Visibility and analytics: Retained logs and analytics let responders establish what happened and its root cause, incident data is collected with its integrity and provenance preserved, and telemetry confirms that containment worked.
Automation and orchestration: Containment, policy change, and notification are orchestrated automatically, with a human in the loop where policy requires one.
Governance: Incident authority and escalation are set by policy, and the policy owner decides when the policy engine's rules change during an incident.

RC Recover

How do we restore and communicate afterward?

Categories

RC.RP Incident Recovery Plan Execution
RC.CO Incident Recovery Communication

Where zero trust lands

Restore to a known-good posture; lessons feed Improvement (ID.IM) and the Govern policy.

User and identity: After an incident, compromised credentials are rotated, standing privileges are re-approved rather than restored wholesale, and affected users are told what changed as their access is re-enabled.
Device: A rebuilt or restored device re-enrolls, re-attests its configuration and patch state, and passes the compliance check again before it regains any access, and the restoration is confirmed to the people who depend on it.
Network and environment: Segments and paths closed during containment are reopened in priority order as their integrity is confirmed, and resilience configurations absorb the shifted load.
Application and workload: Workloads are redeployed from a verified, known-good build through the normal pipeline rather than patched in place, and their authorization is re-established.
Data: Data is restored from backups whose integrity is verified first, restored records keep their labels and access rules, and the owners and any external parties are told what was restored and when.
Visibility and analytics: Telemetry confirms that restored assets behave as their baselines predict before recovery is declared complete, and recovery progress is reported from the telemetry rather than from estimates.
Automation and orchestration: Recovery runbooks execute the restoration steps that can be automated in a set order, and the orchestrator's step log is what the recovery status reported to stakeholders is drawn from.
Governance: The policy owner declares the end of recovery against defined criteria, sets the post-incident operating norms for the program, and signs off the internal and public recovery communications.

The AI column

AI RMF Cyber AI Profile AI Defense Matrix CoSAI ZT for AI SP 1353 M-25-21

Zero trust for agents is layers 2 and 3 applied to a new subject: an agent is a non-person entity, which SP (Special Publication) 800-207 and the user pillar already cover. The AI RMF (Artificial Intelligence Risk Management Framework) is the outcome layer for AI risk; the Cyber AI Profile applies the six functions to AI across its three focus areas; the AI Defense Matrix covers securing AI systems, the Profile's first focus area, not AI-enabled defense. CoSAI (Coalition for Secure AI) applies SP 800-207's policy decision point to agents: authorization stays outside the model, and each tool call gets its own access decision. The SOC (security operations center) Profile is a worked example of one Target Profile for an AI-enabled security operations center, one outcome per function. AI as the defender's tool lands in the automation pillar, where the Department of War (DoW) model names it and the CISA (Cybersecurity and Infrastructure Security Agency) model leaves it out. None of the four frameworks in this column, nor the quick-start guide beside them, binds anyone by its own force; the instrument that governs federal agencies' use of AI, OMB (Office of Management and Budget) Memorandum M-25-21 of 3 April 2025, is listed here as governance outside the cybersecurity stack, and it names none of them.

Worked example: a Profile for an AI-enabled security operations center

Function	Target outcome
Govern	Written policy on what AI agents may do autonomously and where a human decides; a named owner for AI use in security operations. Humans in Command, in writing.
Identify	Inventory of AI models, agents, tools, and the data they can reach, treated as assets with owners and risk ratings.
Protect	Agents hold their own identities with least privilege; tool and data access bounded; prompts and outputs treated as untrusted input at boundaries.
Detect	Agent actions logged and monitored like any privileged account; anomalous tool use surfaces as an event.
Respond	Documented stop, contain, and roll-back procedure for a misbehaving agent, rehearsed like any incident playbook.
Recover	Restore from known-good configurations and models; lessons learned feed the Govern policy.

Questions: which framework, when

Is CSF (Cybersecurity Framework) 2.0 mandatory?

Not by its own force. CSF 2.0 is voluntary by design, and Executive Order 13800 makes each federal agency head, civilian and Department of War (DoW), use it. For federal agencies the mandatory engine underneath is the RMF (Risk Management Framework) and SP (Special Publication) 800-53 under FISMA (Federal Information Security Modernization Act), so the CSF is the communication and prioritization layer above the controls. Its Informative References map each outcome down to the controls.

Draws on: CSF 2.0, RMF / ATO, SP 800-53, EO 13800

How does CSF 2.0 differ from ISO/IEC 27001 (International Organization for Standardization and International Electrotechnical Commission)?

CSF 2.0 is an outcomes framework; ISO/IEC 27001 is a certifiable management system standard. They are complementary: an organization can hold an ISO/IEC 27001 certificate and still use a CSF Profile to talk about outcomes, and the Informative References cross-map the two. NIST (National Institute of Standards and Technology)'s Informative Reference Catalog lists an ISO/IEC 27001:2022 to CSF 2.0 reference.

Draws on: CSF 2.0

What do we do first?

If a mandate binds you, your trailhead's first step names it, and the trailhead's later steps supply the target. In CSF 2.0 terms: scope the Profile and gather what you need, then start with the Govern outcomes: organizational context, risk strategy, and roles. Build a Current Profile and a Target Profile, analyze the gaps and plan, then implement and update. The action plan comes from the gap between the two Profiles.

Draws on: CSF 2.0

How does CSF 2.0 relate to zero trust?

SP 800-207 defines zero trust, and the zero trust models supply the pillars and the maturity ladder. CSF 2.0 does not define zero trust; it gives you the outcome language. Put your model's pillars as columns and the six functions as rows, fill the matrix, and the result is a zero trust Target Profile: leadership reads it in outcome language, and the Informative References under the Subcategories of each cell's Categories carry it down to SP 800-53 or your own control catalog. It also puts zero trust in Govern, Identify, and Detect, not only in Protect. Maturity stays with the zero trust model you use; CSF 2.0 Tiers characterize the rigor of an organization's cybersecurity risk governance and management practices.

Draws on: SP 800-207, CSF 2.0, CISA ZTMM, DoD ZT Strategy, SP 800-53

Where are the mappings?

On the NIST site: the CSF 2.0 Reference Tool and the Informative Reference Catalog map each Subcategory to SP 800-53 and other sources. For either pillar model, each matrix cell carries CSF 2.0 categories; the Subcategories under those categories carry the Informative References to SP 800-53; the CISA (Cybersecurity and Infrastructure Security Agency) model prints no control mapping of its own. For the DoW pillars, the DoD (Department of Defense) Zero Trust Overlays map each capability to SP 800-53 controls; they are not posted publicly in 2026, so a DoW component asks its own leadership or the zero trust portfolio office for the current copy, and anyone borrowing the pillars works from the capability list and the catalog. NIST's practice guide on implementing a zero trust architecture, SP 1800-35 (final, June 2025), also publishes mappings of zero trust architecture principles and technologies to commonly used security standards and guidelines; they map its example builds, not the CISA or DoW pillar models.

Draws on: CSF 2.0, SP 800-53, DoD ZT Overlays, CISA ZTMM, SP 1800-35

Where do SP 800-171, CMMC (Cybersecurity Maturity Model Certification), FedRAMP (Federal Risk and Authorization Management Program), ISO/IEC 27001, CIS (Center for Internet Security) Controls, STIGs (security technical implementation guides), IL4 (Impact Level) through IL6, and MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) land?

SP 800-171 and CMMC are the contractor trailhead: a requirements baseline and the assessment that proves it, layers 4 and 5. FedRAMP is the governmentwide program that certifies cloud services for agency use, so it is verification (layer 5); its Rev5 path assesses an SP 800-53 baseline (layer 4), and its 20x path, widely available since June 2026, assesses Key Security Indicators instead. ISO/IEC 27001 sits beside CSF 2.0 as a management system standard. CIS Controls are a control catalog, layer 4. STIGs and SRGs (security requirements guides) are the DoW configuration baseline at layer 4. IL4 through IL6 are DoW cloud impact levels that set the baseline and the authorization bar, layers 4 and 5 again. ATT&CK is not a layer: it is the map of adversary behavior the stack defends against, most useful under Detect and Respond, and CORA (Cyber Operational Readiness Assessment) scores against its tactics.

Draws on: SP 800-171, CMMC, SP 800-53, RMF / ATO, CORA, CSF 2.0

Where do validated solutions and enterprise services land?

They are not frameworks. A solution such as Thunderdome or Flank Speed is an implementation vehicle measured against the layer 3 activities: an assessment tests which of the DoW zero trust activities the service delivers. An organization that adopts one may inherit some of those activities, not all of them (inherit is this app's word: the DoW activities table splits each activity between enterprise and component responsibility instead), and the way to say which are inherited and which are its own is an activity-level instrument: a record, activity by activity, of what the solution delivers and what the organization still does.

Draws on: Thunderdome, Flank Speed, DoD ZT Strategy, DoD ZT Roadmap, ZT for OT, CISA ZTMM, NSA ZT guidance

Where does operational technology land, and where does IEC 62443 fit?

Operational technology (OT) lands at layer 3. On the DoW side it has its own baseline: activities and outcomes that adapt the enterprise zero trust activities to OT and control systems under the same seven pillars, stay aligned with the enterprise IT (information technology) activities, and are implemented in addition to existing cybersecurity requirements; the document says separate guidance will be developed for weapon systems and defense critical infrastructure. Civilian agencies have no separate OT baseline on this stack: the CISA maturity model is still their model, CISA's 2026 companion, Adapting Zero Trust Principles to Operational Technology, applies it to OT, and NIST SP 800-82 Revision 3 is NIST's guide to OT security. IEC 62443, from the International Electrotechnical Commission, is a series of standards for the security of industrial automation and control systems, not a zero trust model: the DoW document names it, with the Purdue Model, among the established reference architectures it treats as authoritative for classifying OT systems.

Draws on: ZT for OT, DoD ZT Strategy, CISA ZTMM

Sources

Every framework and source on the stack, with its title as printed, publisher, edition, date, a link to the primary, and the verification status with its date. Provenance is a feature.

What the status labels mean

Verified: the publisher's own copy was read on the date shown and matches.
Authored: this app's own synthesis of the cited sources, not a quotation. Trailhead steps, matrix cells and helper answers are all authored, even where no label is shown.
Unverified: the publisher's copy could not be reached; the note lists every address tried.
Conflict: the sources disagree; the note gives both and a date to check again.

Frameworks

NIST Cybersecurity Framework 2.0 (CSF 2.0) Verified, checked 29 Sep 2026 The NIST (National Institute of Standards and Technology) Cybersecurity Framework (CSF) 2.0. NIST, Version 2.0 (NIST CSWP [Cybersecurity White Paper] 29), 26 Feb 2024.

CSF 2.0 gives an organization six functions, Profiles, and Tiers to describe cybersecurity outcomes in language leadership funds against.

Answers: What does good look like, and how do we say it to the people who fund it?

Layer 1 Outcomes and communication

Nature: Guidance
Binds: Federal civilian agencies; Department of War (DoW) components
Deadline: None
Note: Voluntary by design for everyone outside the executive branch; every federal agency head, civilian and DoW, is directed to use it by Executive Order 13800, as the communication layer above the mandatory RMF (Risk Management Framework) and SP (Special Publication) 800-53. Verified, checked 9 Sep 2026

Publisher: NIST
Edition: Version 2.0 (NIST CSWP 29)
Date: 26 Feb 2024
Primary: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
Verification: Verified, checked 29 Sep 2026 NIST CSWP 29 PDF (Portable Document Format) fetched: title, version 2.0 and 26 February 2024 match. The 22 Category names were checked against Appendix A Table 1 and the five Organizational Profile steps against section 3.1, Figure 3. The Community Profile definition was read on 17 September 2026 in section 3.1, printed page 6, and in the glossary entry CSF Community Profile, printed page 26.

Tiers characterize the rigor of an organization's cybersecurity risk governance and management practices (section 3.2); CSF 2.0 does not print the CSF 1.1 sentence that Tiers are not maturity levels. The CSF 2.0 Reference Tool is at https://csrc.nist.gov/projects/cybersecurity-framework/filters and the Informative Reference Catalog at https://csrc.nist.gov/projects/olir/informative-reference-catalog. A Community Profile, in the framework's own words, is a baseline of CSF outcomes that is created and published to address shared interests and goals among a number of organizations (section 3.1).

NIST SP 800-207 Verified, checked 29 Sep 2026 Zero Trust Architecture. NIST, NIST SP 800-207, Aug 2020.

SP 800-207 defines zero trust architecture: no implicit trust from network location, and every request decided by a policy engine and then allowed or blocked at a policy enforcement point.

Answers: What is zero trust, as an architecture rather than a product or a score?

Layer 2 Definition

Nature: Definition
Binds: Voluntary for all
Deadline: None
Note: A definition, not a mandate; the civilian memo and the DoW strategy both point to it for what zero trust means. Verified, checked 29 Sep 2026

Publisher: NIST
Edition: NIST SP 800-207
Date: Aug 2020
Primary: https://csrc.nist.gov/pubs/sp/800/207/final
Verification: Verified, checked 29 Sep 2026 CSRC (Computer Security Resource Center) record and PDF fetched: title Zero Trust Architecture, August 2020 (final posted 11 August 2020); section 3 defines the policy engine, policy administrator and policy enforcement point; the word pillar does not appear.

A companion, NIST SP 800-207A (September 2023), applies the model to access control for cloud-native applications across multiple clouds.

DoD Zero Trust Strategy and Capabilities (DoD ZT Strategy) Verified, checked 9 Sep 2026, recheck after 15 Dec 2026 DoD (Department of Defense) Zero Trust Strategy. DoD CIO (Chief Information Officer), Version 1.0, 21 Oct 2022.

The DoD Zero Trust Strategy sets seven pillars, 45 capabilities, and two levels, Target and Advanced, with Target Level zero trust due across the department by the end of fiscal year 2027.

Answers: What is the target state for DoW components, and which pillars and capabilities define it?

Layer 3 Target state and maturity

Nature: Strategy
Binds: DoW components
Deadline: Target Level zero trust across the department by the end of fiscal year 2027 (DoD ZT Strategy)
Note: Directs DoW components; other organizations may borrow the pillar model but are not bound by it. Verified, checked 9 Sep 2026

Publisher: DoD CIO
Edition: Version 1.0
Date: 21 Oct 2022
Primary: https://dowcio.war.gov/Portals/0/Documents/Library/DoD-ZTStrategy.pdf
Verification: Verified, checked 9 Sep 2026, recheck after 15 Dec 2026 PDF fetched from the CIO library at dowcio.war.gov, which also serves the older dodcio.defense.gov address. Printed date 21 October 2022, version 1.0; cleared for open publication 7 November 2022; announced 22 November 2022, the date usually cited for it. Pillars, the two levels and the FY2027 mandate were read from the document; its Appendix A chart depicts the 45 capabilities, and the counts are printed in the companion roadmap.

Documents

DoD Zero Trust Strategy, Version 1.0, 21 Oct 2022. Primary Verified, checked 29 Sep 2026
Implementing the DoD Zero Trust Strategy, Directive-type Memorandum 25-003, incorporating change 1 of 2 September 2025, 17 Jul 2025. Primary Verified, checked 17 Sep 2026, recheck after 15 Dec 2026 The issuance that turned the strategy into direction to components and established the zero trust portfolio office in policy (the office itself dates from January 2022). Its printed expiry of 17 July 2026 has passed; on 17 September 2026 the issuance library still listed it without a cancellation or extension, and no instruction had replaced it.

The implementing directive-type memorandum (DTM) 25-003 carries a printed expiry of 17 July 2026; on 17 September 2026 the issuance library still listed it with that expiry and no cancellation, extension or successor, and no replacement instruction was found, so the FY2027 deadline rests on the strategy and the roadmap. Operational technology has its own activities and outcomes, listed at this layer as a separate entry.

CISA Zero Trust Maturity Model (CISA ZTMM) Verified, checked 30 Sep 2026 Zero Trust Maturity Model. CISA (Cybersecurity and Infrastructure Security Agency), Version 2.0, Apr 2023.

The CISA Zero Trust Maturity Model gives civilian agencies five pillars, three cross-cutting capabilities, and four maturity stages from Traditional to Optimal.

Answers: How mature is a civilian agency's zero trust posture, and what does the next stage look like?

Layer 3 Target state and maturity

Nature: Model
Binds: Federal civilian agencies
Deadline: None
Note: Written for federal civilian agencies; it binds only through M-22-09, whose goals it organizes and which lets agencies reference it, and version 2.0 was revised to align with the memo. The memo, not the model, carries the deadline. Verified, checked 30 Sep 2026

Publisher: CISA
Edition: Version 2.0
Date: Apr 2023
Primary: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model
Verification: Verified, checked 30 Sep 2026 Version 2.0 PDF fetched from cisa.gov: cover April 2023 (resource page revision date 11 April 2023); five pillars, three cross-cutting capabilities and four stages as printed. The landing page carries CISA's Archived Content banner, which CISA's home page and the model's resource page (https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model) do not; the resource page, revision date 11 April 2023, lists version 2.0 as the only edition and no successor. Re-read on 30 September 2026: the resource page, now the entry's address (a3001), prints 'Revision Date April 11, 2023' and 'CISA's Zero Trust Maturity Model Version 2.0' and carries no archive alert; the landing page at https://www.cisa.gov/zero-trust-maturity-model (a3002) still carries the Archived Content alert, and CISA's home page (a3003) does not; the version 2.0 PDF the resource page links (https://www.cisa.gov/sites/default/files/2023-04/CISA_Zero_Trust_Maturity_Model_Version_2_508c.pdf, a3004) prints April 2023 and Version 2.0 on its cover (page 1), the five pillars and three cross-cutting capabilities on page 6, and the stages Traditional, Initial, Advanced and Optimal on page 8.

The stages are Traditional, Initial, Advanced and Optimal. Companion CISA publications on microsegmentation (2025) and operational technology (2026) are not new editions of the model.

NSA zero trust guidance series (NSA ZT guidance) Verified, checked 9 Sep 2026 NSA (National Security Agency) Zero Trust Guidance: Zero Trust Cybersecurity Information Sheets; Zero Trust Implementation Guidelines. NSA, eight cybersecurity information sheets (2021 to 2024) and four implementation guidelines (2026), 28 May 2026.

NSA's zero trust guidance covers each pillar in an information sheet and, since 2026, phases the DoW Target Level activities in implementation guidelines, so a program can sequence its work.

Answers: In what order do we build each pillar, and what does each phase of the work look like?

Layer 3 Target state and maturity

Nature: Guidance
Binds: Voluntary for all
Deadline: None
Note: Guidance, not a mandate; written for owners of National Security Systems and DoW networks, and usable by anyone. Verified, checked 9 Sep 2026

Publisher: NSA
Edition: Eight cybersecurity information sheets (2021 to 2024) and four implementation guidelines (2026)
Date: 28 May 2026
Primary: https://www.nsa.gov/Cybersecurity/ZIG/
Verification: Verified, checked 9 Sep 2026 NSA's zero trust hub page and its information-sheet listing were read on 9 September 2026; the hub launched 28 May 2026 per NSA's release of that date. All eight information sheets are listed with dates from 25 February 2021 to 10 July 2024. The implementation guidelines (primer, discovery phase, phases one and two) were announced by NSA on 14 and 30 January 2026. The label ZIG belongs to the 2026 implementation guideline series, not to the pillar information sheets.

Documents

Embracing a Zero Trust Security Model, Version 1.0, 25 Feb 2021. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL (Uniform Resource Locator) was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF
Advancing Zero Trust Maturity Throughout the User Pillar, Version 1.1 (April 2023 update), 3 Apr 2023. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2023/Mar/14/2003178390/-1/-1/0/CSI_Zero_Trust_User_Pillar_v1.1.PDF
Advancing Zero Trust Maturity Throughout the Device Pillar, Version 1.0, 19 Oct 2023. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2023/Oct/19/2003323562/-1/-1/0/CSI-DEVICE-PILLAR-ZERO-TRUST.PDF
Advancing Zero Trust Maturity Throughout the Network and Environment Pillar, Version 1.0, 5 Mar 2024. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2024/Mar/05/2003405462/-1/-1/0/CSI-ZERO-TRUST-NETWORK-ENVIRONMENT-PILLAR.PDF
Advancing Zero Trust Maturity Throughout the Data Pillar, Version 1.0, 9 Apr 2024. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2024/Apr/09/2003434442/-1/-1/0/CSI_DATA_PILLAR_ZT.PDF
Advancing Zero Trust Maturity Throughout the Application and Workload Pillar, Version 1.0, 22 May 2024. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2024/May/22/2003470825/-1/-1/0/CSI-APPLICATION-AND-WORKLOAD-PILLAR.PDF
Advancing Zero Trust Maturity Throughout the Visibility and Analytics Pillar, Version 1.0, 30 May 2024. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2024/May/30/2003475230/-1/-1/0/CSI-VISIBILITY-AND-ANALYTICS-PILLAR.PDF
Advancing Zero Trust Maturity Throughout the Automation and Orchestration Pillar, Version 1.0, 10 Jul 2024. Primary Unverified Title and date confirmed on NSA's information-sheet listing page on 9 September 2026; the PDF at this URL was not fetched, and its printed version was read from an archived copy. URL tried: https://media.defense.gov/2024/Jul/10/2003500250/-1/-1/0/CSI-ZT-AUTOMATION-ORCHESTRATION-PILLAR.PDF
Zero Trust Implementation Guideline Primer, initial release, 14 Jan 2026. Primary Unverified Title and release date from NSA's press release and hub page, read on 9 September 2026; the PDF at this URL was not fetched. URL tried: https://media.defense.gov/2026/Jan/08/2003852320/-1/-1/0/CTR_ZERO_TRUST_IMPLEMENTATION_GUIDELINE_PRIMER.PDF
Zero Trust Implementation Guideline: Discovery Phase, initial release, 14 Jan 2026. Primary Unverified Title and release date from NSA's press release and hub page, read on 9 September 2026; the PDF at this URL was not fetched. URL tried: https://media.defense.gov/2026/Jan/08/2003852321/-1/-1/0/CTR_ZIG_DISCOVERY_PHASE.PDF
Zero Trust Implementation Guideline: Phase One, initial release, 30 Jan 2026. Primary Unverified Title and release date from NSA's press release and hub page, read on 9 September 2026; the PDF at this URL was not fetched. URL tried: https://media.defense.gov/2026/Jan/30/2003868308/-1/-1/0/CTR_ZIG_PHASE_ONE.PDF
Zero Trust Implementation Guideline: Phase Two, initial release, 30 Jan 2026. Primary Unverified Title and release date from NSA's press release and hub page, read on 9 September 2026; the PDF at this URL was not fetched. URL tried: https://media.defense.gov/2026/Jan/30/2003868302/-1/-1/0/CTR_ZIG_PHASE_TWO.PDF

NSA's guideline hub page states that the 2026 implementation guidelines were developed in accordance with, synchronized with, and approved by the DoW CIO zero trust portfolio office, and NSA's 30 January 2026 release states that phase one covers 36 activities and phase two 41 of the 91 Target Level activities; the discovery phase is not counted here.

Zero Trust for Operational Technology Activities and Outcomes (ZT for OT) Verified, checked 29 Sep 2026 Zero Trust for Operational Technology Activities and Outcomes. DoD CIO, Version OT.1.3 (as of 25 September 2025), 18 Nov 2025.

The zero trust baseline for operational technology adapts the DoW activities to operational technology and control systems: 105 activities, 84 at Target Level and 21 at Advanced, under the same seven pillars.

Answers: What does Target Level zero trust ask of control systems and other operational technology?

Layer 3 Target state and maturity

Nature: Model
Binds: DoW components
Deadline: None
Note: Written for DoW-owned operational technology and control systems up to and including the point of demarcation with weapon systems and defense critical infrastructure, for which the document says separate guidance will be developed, and implemented in addition to all existing cybersecurity requirements. The document cites DTM 25-003 as directing Target Level zero trust for control systems, though the memorandum's own paragraph 11.a names systems on the department's information network without naming control systems, and its printed expiry of 17 July 2026 has passed. The document prints no deadline of its own and says its Advanced activities will not be held to the Target timeline. The office's senior advisor said in December 2025 that the department's operational technology dates are Target Level by the end of FY2030 and Advanced by the end of FY2033, subject to change in the next strategy; no publisher document prints them. Verified, checked 30 Sep 2026

Publisher: DoD CIO
Edition: Version OT.1.3 (as of 25 September 2025)
Date: 18 Nov 2025
Primary: https://dowcio.war.gov/Portals/0/Documents/Library/ZT-OperationalTechnologyActivitiesOutcomes_v2.pdf
Verification: Verified, checked 29 Sep 2026 PDF fetched from the CIO library on 16 September 2026; cleared for open publication 18 November 2025. The activity chart prints Version OT.1.3 as of 25 September 2025 and counts 84 Target, 21 Advanced and 105 total activities under the User, Device, Application & Workload, Data, Network & Environment, Automation & Orchestration and Visibility & Analytics pillars. The current file name carries a v2 suffix that the document itself does not print; the November 2025 file name without the suffix returns 404 (https://dowcio.war.gov/Portals/0/Documents/Library/ZT-OperationalTechnologyActivitiesOutcomes.pdf).

The activities are aligned with the enterprise IT (information technology) activities so the two can interoperate, and some OT tools may start local and join the enterprise tools later. The document names the Purdue Model, IEC 62443 (International Electrotechnical Commission) and UFC (Unified Facilities Criteria) 4-010-06 as established reference architectures for classifying OT systems, and lists IEC 62443 as a series of standards for the cybersecurity of OT control systems.

NIST SP 800-53 Verified, checked 29 Sep 2026 Security and Privacy Controls for Information Systems and Organizations. NIST, Revision 5 (includes updates as of 10 December 2020), Sep 2020.

SP 800-53 is the catalog of security and privacy controls that federal systems select from, and that CSF references and the zero trust overlays both point into.

Answers: Which specific controls implement an outcome or a capability?

Layer 4 Controls

Nature: Catalog
Binds: Federal civilian agencies; DoW components
Deadline: None
Note: Federal information systems, civilian and DoW, must select from it under FISMA (Federal Information Security Modernization Act) and OMB (Office of Management and Budget) Circular A-130; anyone else may use it voluntarily. Verified, checked 9 Sep 2026

Publisher: NIST
Edition: Revision 5 (includes updates as of 10 December 2020)
Date: Sep 2020
Primary: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
Verification: Verified, checked 29 Sep 2026 CSRC record fetched: title as printed; Revision 5 published September 2020 with updates as of 10 December 2020 at this URL; the record's planning note dates Release 5.2.0 to 27 August 2025 (listed under documents).

Documents

Security and Privacy Controls for Information Systems and Organizations, Revision 5 (includes updates as of 10 December 2020), Sep 2020. Primary Verified, checked 29 Sep 2026
Security and Privacy Controls for Information Systems and Organizations, Release 5.2.0, 27 Aug 2025. Primary Verified, checked 30 Sep 2026 The live control catalog; no new PDF.

Release 5.2.0 (August 2025) responds to Executive Order (EO) 14306 on software update and patch reliability: it adds SA-15(13), SA-24 and SI-02(07), revises SI-07(12), and is the release the CSF 2.0 Informative References map to; the 2020 PDF was not reissued.

DoD Zero Trust Overlays (DoD ZT Overlays) Unverified Zero Trust Overlays. DoD CIO, version not confirmed on a publisher page, Jun 2024.

The DoD Zero Trust Overlays map each zero trust capability and activity to the SP 800-53 controls that implement it.

Answers: Which SP 800-53 controls implement each DoW zero trust capability?

Layer 4 Controls

Nature: Overlay
Binds: DoW components
Deadline: None
Note: Applies to DoW components implementing the strategy; it changes which controls are selected, not whether SP 800-53 applies. Authored

Publisher: DoD CIO
Edition: Version not confirmed on a publisher page
Date: Jun 2024
Primary: https://dodcio.defense.gov/Portals/0/Documents/Library/ZeroTrustOverlays.pdf
Verification: Unverified Document not reachable on any publisher host on 9 September 2026. Tried: https://dodcio.defense.gov/Portals/0/Documents/Library/ZeroTrustOverlays.pdf (404), the same path on dowcio.war.gov (404), the release-day filename ZeroTrustOverlays-2024Feb.pdf on both hosts (404), and the Zero-Trust pages on both hosts (404); neither library page lists it. Title and the 4 June 2024 release are corroborated by the department's own news article and video of that date; version, applicability and the SP 800-53 mapping could be read only from archived copies, which are not primaries.

Launched 29 May 2024 per the department's November 2024 zero trust newsletter and announced publicly on 4 June 2024, and missing from the CIO library since about September 2025; nothing on the publisher's site rescinds or replaces it. From a non-publisher archived copy, not from the verified fields: that copy printed Version 1.1, June 2024, and states that SP 800-53 Revision 5 controls are mapped to the activities and outcomes defined for each zero trust capability.

Cyber Operational Readiness Assessment (CORA) Verified, checked 17 Sep 2026 Cyber Operational Readiness Assessment (CORA) program. JFHQ-DODIN (Joint Force Headquarters-Department of Defense Information Network), program; no printed edition, 28 Feb 2024.

CORA is the DoW network readiness assessment that scores risk on high-priority cyber terrain against adversary tactics rather than against a checklist.

Answers: What does the assessor check when the cyber readiness of a DoW network is assessed?

Layer 5 Verification

Nature: Assessment
Binds: DoW components
Deadline: None
Note: A readiness assessment of DoW networks; it verifies, it does not define. Cleared contractors with SIPRNet (Secret Internet Protocol Router Network) connections are assessed by DCSA (Defense Counterintelligence and Security Agency) under the same program. Verified, checked 17 Sep 2026

Publisher: JFHQ-DODIN
Edition: Program; no printed edition
Date: 28 Feb 2024
Primary: https://www.dcdc.mil/News-Information/DCDC-News/Article-Display/Article/3689211/jfhq-dodin-to-officially-launch-its-new-cyber-operational-readiness-assessment/
Verification: Verified, checked 17 Sep 2026 JFHQ-DODIN news release of 28 February 2024, read in a browser from dcdc.mil (jfhq-dodin.mil now redirects there). The release describes risk-based key indicators built from MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) tactics and 'high-priority cyber terrain'; it does not mention zero trust and does not say DISA (Defense Information Systems Agency) runs or supports the program. Re-read on 16 September 2026: the release describes the change from the Command Cyber Readiness Inspection as a move from an inspection compliance mindset to an operational readiness mindset. For the portfolio office's assessments: the Department of the Navy CIO's article of 28 October 2024 (https://www.doncio.navy.mil/ContentView.aspx?ID=18012) and the execution roadmap v1.1 (https://dowcio.war.gov/Portals/0/Documents/Library/ZT-ExecutionRoadmap-v1.1.pdf), whose assessment slide sets the aim to validate that solutions meet the zero trust activities and outcomes. Re-read on 17 September 2026; the sentence on the change of mindset is the release's own text, not a quotation.

The program launched on 1 March 2024 after a nine-month pilot. The command that launched CORA was later designated a subordinate unified command under section 1502 of the FY2025 NDAA (National Defense Authorization Act) and renamed the DoD Cyber Defense Command (DCDC) by the Secretary. The release does not connect CORA to zero trust; the stack places it at layer 5 because it is the department's operational readiness assessment of its networks, renamed from the Command Cyber Readiness Inspection. The verbs at this layer differ: the DoW CIO's zero trust portfolio office conducted one purple team test of a solution against the zero trust activities and sponsored a second, and its execution roadmap names validating that solutions meet the activities as the aim of assessment; CORA assesses the cyber readiness of DoW networks for the commanders and directors of their areas of operation. Wording settled by the ruling of Lensatic's owner on 17 September 2026: Lensatic calls CORA a readiness assessment, not an inspection, because the launch release says the program moved from an inspection compliance mindset to an operational readiness mindset (https://www.dcdc.mil/News-Information/DCDC-News/Article-Display/Article/3689211/jfhq-dodin-to-officially-launch-its-new-cyber-operational-readiness-assessment/).

RMF and ATO evidence (RMF / ATO) Verified, checked 30 Sep 2026, recheck after 15 Dec 2026 Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. NIST, NIST SP 800-37 Revision 2, Dec 2018.

The Risk Management Framework is the seven-step process that produces the evidence an authorizing official uses to grant an authorization to operate.

Answers: What evidence does an assessor examine, and who decides the system may operate?

Layer 5 Verification

Nature: Assessment
Binds: Federal civilian agencies; DoW components
Deadline: None
Note: Mandatory for federal agencies, civilian and DoW, under FISMA and OMB Circular A-130. Verified, checked 9 Sep 2026

Publisher: NIST
Edition: NIST SP 800-37 Revision 2
Date: Dec 2018
Primary: https://csrc.nist.gov/pubs/sp/800/37/r2/final
Verification: Verified, checked 30 Sep 2026, recheck after 15 Dec 2026 CSRC pages fetched: SP 800-37 Revision 2, December 2018 (final 20 December 2018), seven steps Prepare through Monitor; SP 800-53A Revision 5, January 2022. The authorization definition is the OMB Circular A-130 definition quoted in the glossary. The CSRMC (Cybersecurity Risk Management Construct) sentences rest on the CIO announcement of 24 September 2025 (https://dowcio.war.gov/In-the-News/Article/4367432/), read on 30 September 2026, which calls the RMF the previous Risk Management Framework and presents the construct in five phases, and on the construct itself (https://media.defense.gov/2025/Sep/24/2003808112/-1/-1/1/DOD-CIO-CYBER-SECURITY-RISK-MANAGEMENT-CONSTRUCT.PDF), read on 30 September 2026: its five phases, Design, Build, Test, Onboard and Operations, each name the RMF steps they carry, and it prints no date and does not cancel DoD Instruction 8510.01. DoD Instruction 8510.01, read on 30 September 2026, is effective 19 July 2022, reissues and cancels the 2014 instruction, and says nothing of being cancelled; the CIO library (https://dowcio.war.gov/Library/), read on 29 September 2026, still listed Instruction 8510.01 for the RMF. The construct and the instruction returned 403 to a plain read later that day.

Documents

Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, NIST SP 800-37 Revision 2, Dec 2018. Primary Verified, checked 29 Sep 2026
Assessing Security and Privacy Controls in Information Systems and Organizations, NIST SP 800-53A Revision 5, Jan 2022. Primary Verified, checked 29 Sep 2026 The assessment procedures an assessor runs against SP 800-53 controls.
Risk Management Framework for DoD Systems, DoD Instruction 8510.01, 19 Jul 2022. Primary Verified, checked 9 Sep 2026 The instruction that runs the RMF for DoW systems.

The seven steps span two layers: Prepare comes first and serves both; Categorize, Select and Implement sit with the controls layer; Assess, Authorize and Monitor are the verification layer. On 24 September 2025 the DoW CIO announced a Cybersecurity Risk Management Construct (CSRMC) that it presents as the successor to the RMF process; DoD Instruction 8510.01 was still the instruction in the CIO library on 29 September 2026. The construct's five phases are organized around the RMF steps.

NIST AI Risk Management Framework 1.0 (AI RMF) Verified, checked 29 Sep 2026 Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST, Version 1.0 (NIST AI 100-1), 26 Jan 2023.

The AI RMF gives an organization four functions, Govern, Map, Measure, and Manage, to handle the risks of AI systems in outcome language.

Answers: What does good look like for AI risk, in the language leadership funds against?

AI column

Nature: Guidance
Binds: Voluntary for all
Deadline: None
Note: Voluntary for all organizations. Verified, checked 29 Sep 2026

Publisher: NIST
Edition: Version 1.0 (NIST AI 100-1)
Date: 26 Jan 2023
Primary: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
Verification: Verified, checked 29 Sep 2026 NIST AI 100-1 PDF and the NIST landing page fetched: title as printed, January 2023 on the cover, released 26 January 2023 per the page; four functions Govern, Map, Measure, Manage.

NIST states that AI RMF 1.0 is being revised under the 2025 AI Action Plan; a Generative AI Profile (NIST AI 600-1) followed on 26 July 2024.

NIST IR 8596, Cyber AI Profile (draft) Verified, checked 29 Sep 2026, recheck after 15 Dec 2026 Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile): NIST Community Profile. NIST, initial preliminary draft (NIST IR [NIST Internal Report] 8596 iprd), 16 Dec 2025.

The Cyber AI Profile is a draft CSF 2.0 Community Profile that crosses the six functions with three focus areas: securing AI system components, conducting AI-enabled cyber defense, and thwarting AI-enabled cyber attacks.

Answers: How do the six CSF functions apply when AI is the system being secured, the attacker's tool, or the defender's tool?

AI column

Nature: Guidance
Binds: Voluntary for all
Deadline: None
Note: A draft Community Profile; voluntary, and still changing. Verified, checked 9 Sep 2026

Publisher: NIST
Edition: Initial preliminary draft (NIST IR 8596 iprd)
Date: 16 Dec 2025
Primary: https://csrc.nist.gov/pubs/ir/8596/iprd
Verification: Verified, checked 29 Sep 2026, recheck after 15 Dec 2026 CSRC record and PDF fetched: initial preliminary draft published 16 December 2025, comment period closed 30 January 2026; the draft is organized by CSF 2.0 outcomes across three focus areas. No initial public draft had appeared by 9 September 2026; on 9 September 2026 the NCCoE (National Cybersecurity Center of Excellence) project page listed the status as reviewing comments after working sessions in April and May 2026 (the page could not be reached on 17 September 2026). The initial public draft, when it appears, changes this entry. Rechecked 17 September 2026: no initial public draft on CSRC (the ipd path returns 404); the preliminary draft of 16 December 2025 remains the only release, and CSRC and the PDF cover print the subtitle NIST Community Profile. NIST IR 8607 (August 2026, section 4) planned the initial public draft for public comment in summer 2026 (https://doi.org/10.6028/NIST.IR.8607); it had not appeared on CSRC by 17 September 2026.

Focus areas as printed in the draft: Securing AI System Components (Secure), Conducting AI-Enabled Cyber Defense (Defend), Thwarting AI-Enabled Cyber Attacks (Thwart). A companion NIST project drafts SP 800-53 control overlays for securing AI systems.

The AI Defense Matrix lays the six CSF 2.0 functions across eight AI-specific asset classes, from models and training data to agent identities, the same two-axis move the zero trust matrix makes.

Answers: Which defenses does each part of an AI system need, function by function?

AI column

Nature: Guidance
Binds: Voluntary for all
Deadline: None
Note: A public reference, not a standard; nothing binds anyone to it. Verified, checked 9 Sep 2026

Publisher: aidefensematrix.com
Authors: Lenny Zeltser, Sounil Yu
License: CC BY-SA (Creative Commons Attribution-ShareAlike) 4.0 (attribution required on reuse)
Edition: None printed (copyright 2026)
Date: 2026
Primary: https://aidefensematrix.com/
Verification: Verified, checked 29 Sep 2026 Site fetched: title and a one-line subtitle, eight rows by the six CSF 2.0 functions, Creative Commons Attribution-ShareAlike 4.0, copyright 2026; no version number or publication date is printed, and public release was about May 2026. The .org domain does not resolve.

A private work by its two authors, credited in the citation fields, published under a Creative Commons Attribution-ShareAlike 4.0 license and positioned as the security-for-AI companion to the Cyber Defense Matrix. It is the one entry on the stack that is not a government or standards-body work.

CoSAI Zero Trust for AI Systems (CoSAI ZT for AI) Verified, checked 30 Sep 2026 Zero Trust for AI Systems. Coalition for Secure AI (CoSAI), an OASIS Open Project, Version 1.0, 4 Sep 2026.

Zero Trust for AI Systems keeps authorization outside the model, beyond what it calls the AI threat boundary: an agent gets a scoped share of its user's rights, and a policy decision point checks each tool call.

Answers: Where must authorization sit when an AI agent acts for a user?

AI column

Nature: Guidance
Binds: Voluntary for all
Deadline: None
Note: A paper from an OASIS Open Project, outside the standards track; nothing binds anyone to it. Verified, checked 30 Sep 2026

Publisher: Coalition for Secure AI (CoSAI), an OASIS Open Project
License: Copyright 2026 OASIS Open, all rights reserved, with limited permissions if the notice is kept (attribution required on reuse)
Edition: Version 1.0
Date: 4 Sep 2026
Primary: https://github.com/cosai-oasis/ws2-defenders/blob/main/zero-trust/Zero-Trust-for-AI-Systems.pdf
Verification: Verified, checked 30 Sep 2026 PDF fetched: the cover prints the title, Version 1.0 and 4 September 2026; printed page 2 says the CoSAI Project Governing Board approved it that day, and page 9 places the model and its data pipeline inside the AI threat boundary of Figure 1 (page 8), limits an agent to a subset of its user's rights and makes each tool call a separate authorization. Added to the repository late on 15 September 2026, Eastern time (commit a733bdb), beside its Markdown source; no release or tag. The repository names Apache 2.0 and, for documentation and data, Creative Commons Attribution 4.0; this entry follows the paper's own notice.

From CoSAI's Workstream 2. A framework in the AI column because it maps zero trust onto the parts of an AI system: policies for each part (Table 1) and controls at maturity tiers (Table 2).

NIST SP 1353 (initial public draft) Verified, checked 18 Oct 2026, recheck after 15 Nov 2026 NIST Cybersecurity Framework 2.0: Quick-Start Guide for Using Artificial Intelligence (AI) for CSF Analysis and Reporting. NIST, initial public draft (NIST SP 1353 ipd), 19 Aug 2026.

SP 1353 is a draft quick-start guide on using AI tools to do CSF analysis and reporting; it is a how-to, not a framework.

Answers: How can a team use AI tools in a CSF assessment without handing them the judgment the Profile needs?

AI column

Nature: Guidance
Binds: Voluntary for all
Deadline: None
Note: A draft guide; voluntary. Verified, checked 9 Sep 2026

Publisher: NIST
Edition: Initial public draft (NIST SP 1353 ipd)
Date: 19 Aug 2026
Primary: https://csrc.nist.gov/pubs/sp/1353/ipd
Verification: Verified, checked 18 Oct 2026, recheck after 15 Nov 2026 CSRC record fetched: initial public draft published 19 August 2026, comments due 15 October 2026, part of the CSF 2.0 quick-start guide series. Rechecked 17 September 2026: still the initial public draft, comments due 15 October 2026, no second draft or final. Rechecked 30 September 2026: still the initial public draft of 19 August 2026, comments due 15 October 2026, with one history entry. Rechecked 18 October 2026: still the initial public draft of 19 August 2026, the public comment period closed on 15 October 2026, one history entry, no second draft or final.

Placed in the AI column as a quick-start guide rather than a framework. Its comment period closed on 15 October 2026, and it was still the initial public draft on 18 October 2026.

Authorities, programs and guides the page cites

Executive Order 14028 (EO 14028) Verified, checked 29 Sep 2026 Improving the Nation's Cybersecurity. The White House, Executive Order 14028, 12 May 2021.

EO 14028 orders every federal agency head to modernize cybersecurity, including a plan to adopt zero trust architecture.

Role: Root mandate for the federal civilian trailhead.

Nature: Mandate
Binds: Federal civilian agencies; DoW components
Deadline: Section 3(b)(ii): each agency head develops a plan to implement zero trust architecture within 60 days of the order (EO 14028)
Note: Binds every agency under 44 U.S.C. (United States Code) 3502, DoW included; under section 9, National Security Systems follow equivalent or stricter requirements that the National Manager sets in a National Security Memorandum rather than the order's own programs; it directs the move, and M-22-09 sets the targets. Verified, checked 30 Sep 2026

Publisher: The White House
Edition: Executive Order 14028
Date: 12 May 2021
Primary: https://www.govinfo.gov/content/pkg/FR-2021-05-17/pdf/2021-10460.pdf
Verification: Verified, checked 29 Sep 2026 Federal Register text read from the govinfo PDF (86 FR 26633): signed 12 May 2021, published 17 May 2021. Section 3, Modernizing Federal Government Cybersecurity: 3(a) says the government must advance toward Zero Trust Architecture and 3(b)(ii) gives each agency head 60 days to develop a plan to implement it.

Later orders cross-reference it without amending it, per the Federal Register record read on 9 September 2026.

OMB Memorandum M-22-09 Verified, checked 29 Sep 2026 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles. OMB, M-22-09, 26 Jan 2022.

M-22-09 is the federal zero trust strategy memo: it sets the goals every executive department and agency must meet, organized by the CISA maturity model.

Role: Cited by the civilian trailhead for its goals and its deadline.

Nature: Mandate
Binds: Federal civilian agencies; DoW components
Deadline: Specific zero trust security goals by the end of fiscal year 2024 (M-22-09)
Note: Binds the heads of executive departments and agencies under 44 U.S.C. 3502, DoW included; the maturity model organizes the goals, the memo requires them. Verified, checked 29 Sep 2026

Publisher: OMB
Edition: M-22-09
Date: 26 Jan 2022
Primary: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
Verification: Verified, checked 29 Sep 2026 Memo PDF fetched from whitehouse.gov (identical copy on the archived site): dated 26 January 2022; requires specific zero trust security goals by the end of fiscal year 2024; goals organized using CISA's zero trust maturity model; addressed to the heads of executive departments and agencies.

Executive Order 13800 (EO 13800) Verified, checked 29 Sep 2026 Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure. The White House, Executive Order 13800, 11 May 2017.

EO 13800 directs every federal agency head to use the NIST Cybersecurity Framework to manage the agency's cyber risk.

Role: The order that makes the CSF the federal outcome language; cited by the civilian trailhead's Profile step.

Nature: Mandate
Binds: Federal civilian agencies; DoW components
Deadline: None
Note: Directs every agency head, DoW included, to use the Framework; for everyone outside the executive branch the Framework stays voluntary. Verified, checked 29 Sep 2026

Publisher: The White House
Edition: Executive Order 13800
Date: 11 May 2017
Primary: https://www.govinfo.gov/content/pkg/FR-2017-05-16/pdf/2017-10004.pdf
Verification: Verified, checked 29 Sep 2026 Federal Register text read from the govinfo PDF (82 FR 22391): signed 11 May 2017, published 16 May 2017. Section 1(c)(ii): each agency head shall use the Framework 'or any successor document' to manage the agency's cybersecurity risk, with a risk management report due within 90 days.

CSF 2.0 states that it succeeds the Framework for Improving Critical Infrastructure Cybersecurity named in this order.

DoD Zero Trust Execution Roadmap and Capabilities (DoD ZT Roadmap) Verified, checked 29 Sep 2026 Zero Trust Execution Roadmap. DoD CIO, v1.1, 22 Nov 2024.

The execution roadmap sequences the 152 zero trust activities, 91 of them at Target Level, by course of action and fiscal year toward the strategy's deadline.

Role: Phasing for the DoW trailhead.

Nature: Strategy
Binds: DoW components
Deadline: The strategy's Target Level deadline, the end of fiscal year 2027 (DoD ZT Strategy)
Note: Directs DoW components; it sequences the strategy, it does not add obligations. Verified, checked 29 Sep 2026

Publisher: DoD CIO
Edition: v1.1
Date: 22 Nov 2024
Primary: https://dowcio.war.gov/Portals/0/Documents/Library/ZT-ExecutionRoadmap-v1.1.pdf
Verification: Verified, checked 29 Sep 2026 Fetched from the CIO library: cover 'Zero Trust Execution Roadmap v1.1', 22 November 2024, cleared 9 December 2024; PDF title 'DoD Zero Trust Capability Execution Roadmap (COA 1)'; prints 45 capabilities (42 Target, 3 Advanced) and 152 activities (91 Target, 61 Advanced). The companion capabilities and activities document was fetched from the same library; its cover prints v1.1 and 22 January 2025.

Documents

Zero Trust Execution Roadmap, v1.1, 22 Nov 2024. Primary Verified, checked 29 Sep 2026
DOD Zero Trust Execution Roadmap (COAs 1-3), v1.1, 22 Jan 2025. Primary Verified, checked 29 Sep 2026 The activity-level detail: responsibility (enterprise or component), predecessors, and end states for each activity.

NIST SP 800-171 Verified, checked 29 Sep 2026 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. NIST, Revision 2 (includes updates as of 28 January 2021), 28 Jan 2021.

SP 800-171 lists the security requirements a nonfederal organization must meet to protect the controlled unclassified information it handles for the government.

Role: Control layer for the defense contractor trailhead.

Nature: Catalog
Binds: Defense contractors handling CUI
Deadline: None
Note: Binds contractors through DFARS (Defense Federal Acquisition Regulation Supplement) 252.204-7012, which a class deviation pins to Revision 2, and through the CMMC (Cybersecurity Maturity Model Certification) program, not directly. Verified, checked 9 Sep 2026

Publisher: NIST
Edition: Revision 2 (includes updates as of 28 January 2021)
Date: 28 Jan 2021
Primary: https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final
Verification: Verified, checked 29 Sep 2026 CSRC record fetched: Revision 2, February 2020 with updates as of 28 January 2021, withdrawn on 14 May 2024 and superseded by Revision 3. Kept as the entry edition because DFARS class deviation 2024-O0013 binds this revision.

Documents

Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Revision 2 (includes updates as of 28 January 2021), 28 Jan 2021. Primary Verified, checked 29 Sep 2026 The edition DFARS 252.204-7012 and CMMC Level 2 assess against.
Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Revision 3, 14 May 2024. Primary Verified, checked 30 Sep 2026, recheck after 15 Dec 2026 NIST's current edition; applies to a contract only when the contract says so. A FAR proposed rule of 23 June 2026 (91 FR 37550) would require Revision 3 for controlled unclassified information in contracts under the FAR; it was not final on 30 September 2026.
Class Deviation 2024-O0013, Revision 1: Safeguarding Covered Defense Information and Cyber Incident Reporting, 22 May 2024. Primary Verified, checked 9 Sep 2026 The acquisition deviation that pins the clause to Revision 2.

NIST withdrew Revision 2 on 14 May 2024 in favor of Revision 3. Class Deviation 2024-O0013 keeps Revision 2 in force for DFARS 252.204-7012 until rescinded, and the CMMC program rule assesses Level 2 against its 110 requirements.

Cybersecurity Maturity Model Certification (CMMC) Program Verified, checked 29 Sep 2026 Conflict: a conflict is recorded inside Cybersecurity Maturity Model Certification (CMMC) Program. DoD CIO, 32 CFR (Code of Federal Regulations) Part 170, final rule (89 FR 83092), 15 Oct 2024.

CMMC is the DoW program that verifies, at three levels, that a contractor meets the security requirements for the information it handles, by self-assessment, by an accredited third-party assessor, or by a government assessment.

Role: Certification layer for the defense contractor trailhead.

Nature: Assessment
Binds: Defense contractors handling FCI (Federal contract information) or CUI
Deadline: Phase 1 began 10 November 2025 when the acquisition rule took effect; the rule's later phases, due one year apart through 10 November 2028, are suspended, implementation was paused in Phase 1 on 13 July 2026, and no new date had been set by 30 September 2026 (CMMC)
Note: Binds defense contractors and subcontractors when the clause is in the contract. Conflict, recheck after 10 Nov 2026
Two layers, rechecked 30 September 2026. Rule text, unamended: the electronic Code of Federal Regulations is current to 28 September 2026 and shows no change to part 170 since 16 December 2024, and the Federal Register shows no rule or notice amending either rule since 13 July 2026 (c013); 32 CFR 170.3(e)(2) (c016) starts Phase 2 one year after Phase 1, which would be 10 November 2026, and DFARS 204.7504 phases the clause through 10 November 2028. Department policy in effect: the CIO and acquisition memoranda of 13 July 2026 suspend the Phase 2 transition with no new date and let solicitations and contracts call only for Level 1 and Level 2 self-assessments, alongside select government-led assessments; Class Deviation 2026-O0025 carries that into contracting, first in Revision 2 of 16 July 2026 and now in Revision 3 of 3 September 2026, still the latest revision when read on 30 September 2026 (the class deviation list did not load from here). The department's CMMC page, read on 30 September 2026 (c011), still reports the 13 July 2026 suspension of Phase 2 with the Phase 1 self-assessment requirements in place. No task force report or new Phase 2 date had been published by 30 September 2026. Both layers recorded; the memoranda and the deviation are listed under documents.

Publisher: DoD CIO
Edition: 32 CFR Part 170, final rule (89 FR 83092)
Date: 15 Oct 2024
Primary: https://www.govinfo.gov/content/pkg/FR-2024-10-15/pdf/2024-22905.pdf
Verification: Verified, checked 29 Sep 2026 Both final rules read from govinfo PDFs: the program rule published 15 October 2024, effective 16 December 2024; the acquisition rule published 10 September 2025, effective 10 November 2025. The rule's title carries no version number; CMMC 2.0 appears only in its comment responses.

Documents

Cybersecurity Maturity Model Certification (CMMC) Program, 32 CFR Part 170, final rule (89 FR 83092), 15 Oct 2024. Primary Verified, checked 29 Sep 2026
Defense Federal Acquisition Regulation Supplement: Assessing Contractor Implementation of Cybersecurity Requirements, 48 CFR Parts 204, 212, 217 and 252, final rule (90 FR 43560), 10 Sep 2025. Primary Verified, checked 29 Sep 2026
Forging the Arsenal of Freedom: Department of War Suspends CMMC Phase II Requirements, news release, 13 Jul 2026. Primary Verified, checked 30 Sep 2026 The department's announcement of the pause.
Implementing Suspension of CMMC Phase II (memorandum), Acquisition and Sustainment memorandum with Attachment 1, CMMC procedures, 13 Jul 2026. Primary Verified, checked 29 Sep 2026 The acquisition memorandum that carries the CIO's suspension into requirement documents, solicitations and contracts; the news release is corroboration.
Removing Barriers to Defense Industrial Base Expansion: Immediate Suspension and Strategic Review of Cybersecurity Maturity Model Certification Requirements, CIO memorandum, 13 Jul 2026. Primary Verified, checked 29 Sep 2026 The CIO memorandum that suspends Phase 2 and starts the review.
Class Deviation 2026-O0025, Revision 3: Revolutionary FAR Overhaul Part 40 and DFARS Part 240, superseding Revision 2 of 16 July 2026, 3 Sep 2026. Primary Verified, checked 17 Sep 2026 The contracting instrument that carries the suspension; the codified rule text is unchanged.

Commonly called CMMC 2.0. Level 1 is a self-assessment against the 15 requirements of FAR 52.204-21. Level 2 covers the 110 requirements of SP 800-171 Revision 2 and under the rule is either self-assessed or certified by a C3PAO (CMMC Third-Party Assessment Organization), as the contract specifies. Level 3 adds 24 requirements from SP 800-172 and under the rule is assessed by the government's DCMA (Defense Contract Management Agency) DIBCAC (Defense Industrial Base Cybersecurity Assessment Center). The department's suspension of 13 July 2026 (listed under documents, with the memoranda and the class deviation that carries it into contracts) limits new CMMC requirements to Level 1 and Level 2 self-assessments, has Level 2 C3PAO and Level 3 DIBCAC requirements removed from active solicitations and, before the next option is exercised or at the next scheduled administrative modification, from existing contracts, and leaves the DFARS 252.204-7012 obligation in place; no task force report had been published by 30 September 2026.

NIST SP 1800-35 Verified, checked 29 Sep 2026 Implementing a Zero Trust Architecture: High-Level Document. NIST, NIST SP 1800-35, final, 10 Jun 2025.

SP 1800-35 is NIST's practice guide for implementing a zero trust architecture consistent with SP 800-207, built from example implementations and mapped to common standards.

Role: Implementation guidance at layer 4 for any trailhead; cited by the mapping helper.

Layer 4 Controls

Nature: Guidance
Binds: Voluntary for all
Deadline: None
Note: A practice guide: it binds no one and adds no controls; it shows how the SP 800-207 model becomes a working build. Verified, checked 29 Sep 2026

Publisher: NIST
Edition: NIST SP 1800-35, final
Date: 10 Jun 2025
Primary: https://csrc.nist.gov/pubs/sp/1800/35/final
Verification: Verified, checked 29 Sep 2026 CSRC record fetched: title as printed, final, June 2025 (document history final 10 June 2025), DOI (Digital Object Identifier) 10.6028/NIST.SP.1800-35, from the National Cybersecurity Center of Excellence; the record's abstract says the guide includes mappings of ZTA principles and technologies to commonly used security standards and guidelines.

Implementation guidance, not a catalog: placed at layer 4 because it shows how the definition becomes a working build and maps that build to common standards.

OMB Memorandum M-25-21 Verified, checked 29 Sep 2026 Accelerating Federal Use of AI through Innovation, Governance, and Public Trust. OMB, M-25-21, 3 Apr 2025.

M-25-21 is the memo that governs how federal agencies use AI, with named accountable officials, use-case inventories, and minimum practices for high-impact uses.

Role: Governance of federal AI use, outside the cybersecurity stack; listed in the AI column and cited by its note.

AI column

Nature: Mandate
Binds: Federal civilian agencies; DoW components
Deadline: A Chief AI Officer retained or designated within 60 days of 3 April 2025; the memo's other actions run on its own clock (M-25-21)
Note: Binds the heads of executive departments and agencies under 44 U.S.C. 3502(1); it does not cover AI used as a component of a National Security System, the DoW and the Intelligence Community are exempt from its use-case inventory clause, and it names none of the frameworks or the quick-start guide in this column. Verified, checked 29 Sep 2026

Publisher: OMB
Edition: M-25-21
Date: 3 Apr 2025
Primary: https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf
Verification: Verified, checked 29 Sep 2026 Memo PDF fetched from whitehouse.gov: dated 3 April 2025, subject as printed, addressed to the heads of executive departments and agencies; rescinds and replaces its predecessor; agency as defined in 44 U.S.C. 3502(1).

Governance outside the cybersecurity stack: it tells agencies how to govern their use of AI, not how to secure it, which is why it is listed with the column as governance rather than as a framework on it.

Validated solutions

DISA Thunderdome Verified, checked 30 Sep 2026 DISA awards Thunderdome production agreement. DISA, production agreement awarded 28 July 2023; no printed edition, 2 Aug 2023.

Thunderdome is the zero trust network access and application security architecture of the Defense Information Systems Agency (DISA), which deploys it to Defense Agencies and Field Activities as it moves them onto one consolidated network.

Answers: What does an enterprise zero trust service deliver, and how was it measured against the model?

Layer 3 Target state and maturity

Assessed against: DoD ZT Roadmap. DISA reported in May 2025 that after extensive testing Thunderdome met 152 of 152 key zero trust activities as the DoW CIO and the department set them out, the total the execution roadmap counts as full achievement of Advanced Level. DISA's report names no tester and no test date. Verified, checked 16 Sep 2026

DISA newsroom story of 9 May 2025 (https://www.disa.mil/newsroom/article/partnerships-power-progress-disa-deputy-director-emphasizes-industry-collaborati-MCI2K3VHU665FZ3MIKMCB6BPQ7I4), read in a browser on 16 September 2026, states the 152 of 152 result as testing measured against the activities the CIO defines. The execution roadmap v1.1 (https://dowcio.war.gov/Portals/0/Documents/Library/ZT-ExecutionRoadmap-v1.1.pdf) prints 91 Target plus 61 Advanced activities, 152 in total, as full achievement of Advanced Level. No DISA or CIO page names a purple team, a test date or an ordinal for Thunderdome; the purple team wording, and the claim that it was the second solution after Flank Speed, appear only in April 2025 news coverage. The DoW CIO's written statement for the record to a House Armed Services subcommittee on 8 May 2025 says the department declared Thunderdome and Flank Speed Advanced Level successes in FY2025, without giving a count or saying who assessed them or when (listed under documents). The Department of the Navy CIO's and the portfolio office's own published count for Flank Speed is 151 of 152. Pages checked: the DISA newsroom, the CIO library (https://dowcio.war.gov/Library/), the office's November 2024 newsletter (https://dowcio.war.gov/Portals/0/Documents/Library/ZT-NewsletterNov.pdf).

What an adopting organization still owns

Defense Agencies and Field Activities moving onto DISA's consolidated network do not run that move themselves: DISA, their single service provider, surveys their sites, buys and installs the equipment and migrates their users, and they are to have Thunderdome's zero trust capabilities from the day they migrate. Verified, checked 29 Sep 2026
DISA's FY2026 procurement justification (https://comptroller.war.gov/Portals/45/Documents/defbudget/FY2026/budget_justification/pdfs/02_Procurement/PROC_DISA_PB_2026.pdf), line item 98, read on 16 September 2026: DISA is the single service provider for the network the Defense Agencies and Field Activities consolidate onto; its program office surveys sites, purchases and installs equipment and then migrates users; migrating agencies will have Thunderdome zero trust capabilities from day one. The book states an aim, not a result, and does not say which zero trust activities that covers.
Adopting Thunderdome does not by itself change which activities the DoW activity list marks as component responsibility, such as manual data tagging (4.3.2) and macro-segmentation (5.3.2), and the strategy still expects each component to show proof of the outcomes it delivers to its authorizing official or the portfolio office. Authored
The app's own reading, not a DISA or CIO statement: no publisher primary checked on 16 September 2026 lists what an adopter of a validated solution still owns. In the activities table's Responsibility column, component means any DoW component, adopters and DISA alike; the table does not address solutions or their adopters. The strategy lets components select their own solutions as long as they deliver the capability outcomes and show the proof. DISA's FY2026 and FY2027 procurement justifications say the migration makes Defense Agencies and Field Activities zero trust compliant from day one without saying which activities that covers, so this reading may not hold for their network activities such as macro-segmentation.
A mission partner that runs its own Thunderdome tenancy, rather than the DISA-managed option, should expect to plan its own move onto the service and to design the access and segmentation policies the service enforces. Authored
The app's own reading, not a DISA statement. DISA's former Thunderdome page, now 404 and read only in archived copies (https://web.archive.org/web/20250122131546/https://disa.mil/en/About/Thunderdome), offered mission partners a DISA-managed option or a self-managed tenancy and listed nothing left to the partner. The execution roadmap's key considerations for the commercial cloud course of action (https://dowcio.war.gov/Portals/0/Documents/Library/ZT-ExecutionRoadmap-v1.1.pdf) say not to assume security responsibility transfers to the provider and that enforcement policies and network segmentation still need careful design; they do not name Thunderdome. A wider caveat in this spirit appears only in sponsored media, which is not cited.

Nature: Enterprise service
Binds: Organizations that adopt it
Deadline: None
Note: Has no force of its own; it applies to the organizations that adopt it. Defense Agencies and Field Activities receive it as DISA, their single service provider for a consolidated network, migrates them, and the department's FY2027 budget request counts 119 sites where Thunderdome migrations were completed in FY2025. Verified, checked 29 Sep 2026

Publisher: DISA
Edition: Production agreement awarded 28 July 2023; no printed edition
Date: 2 Aug 2023
Primary: https://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=16374
Verification: Verified, checked 30 Sep 2026 DISA release of 28 July 2023, bylined to DISA public affairs and read on 16 September 2026 where the Department of the Navy CIO's online magazine republished it on 2 August 2023: a follow-on production agreement awarded 28 July 2023 for DISA's zero trust network access and application security architecture. DISA's own distribution of the release on a newswire service, headed 'News provided by Defense Information Systems Agency' and dated 28 July 2023 (https://www.prnewswire.com/news-releases/disa-awards-thunderdome-production-agreement-301888665.html), read on 30 September 2026, is the publisher's copy read: the same headline, and a follow-on production agreement awarded that day for its zero trust network access and application security architecture. The magazine page could not be re-read on 30 September 2026: it returned a rejection page. DISA's release of 6 March 2023 (https://www.doncio.navy.mil/CHIPS/ArticleDetails.aspx?ID=16121) says the prototype proved that commercial technologies, including secure access service edge, software-defined wide area networks and customer edge security stacks, and application security stacks, can improve both security and network performance in an existing enterprise environment. DISA's own Thunderdome page is gone: disa.mil/en/About/Thunderdome gave no response and www.disa.mil/en/About/Thunderdome returned 404.

Documents

Statement on Information Technology and Artificial Intelligence Posture of Department of Defense, record version, as printed on the cover: before the Subcommittee on Cyber, Innovative Technologies, and Information Systems, Committee on Armed Services, U.S. House of Representatives, 119th Congress (the committee lists the hearing under the Subcommittee on Cyber, Information Technologies, and Innovation), 8 May 2025. Authors: Katherine E. Arrington, Performing the Duties of Department of Defense Chief Information Officer. Primary Verified, checked 29 Sep 2026 The department CIO's written statement for the record; cited for the Advanced Level statement only.

Navy Flank Speed Verified, checked 16 Sep 2026 Department of the Navy Enterprise Information Technology Service Designation for Flank Speed and Hyperion Messaging and Collaboration Services. Department of the Navy CIO, Joint memorandum Ser CIO/25-0001, 15 Jan 2025.

Flank Speed is the Navy's unclassified Microsoft 365 cloud environment, whose productivity and messaging services are designated a Department of the Navy enterprise IT service.

Answers: What does a zero trust assessment of an enterprise cloud service report, and against how many of the activities?

Layer 3 Target state and maturity

Assessed against: DoD ZT Roadmap. A spring 2024 purple team assessment (attack and defense teams working together), sponsored by the DoW CIO's zero trust portfolio office and involving a coalition of DoW and industry experts, covered all 152 activities; the Department of the Navy CIO reported all 91 Target Level activities and 60 of the 61 Advanced activities met, which the office's November 2024 newsletter counts as 151 of 152. Verified, checked 16 Sep 2026

Department of the Navy CIO article of 28 October 2024 (https://www.doncio.navy.mil/ContentView.aspx?ID=18012) and the office's November 2024 newsletter (https://dowcio.war.gov/Portals/0/Documents/Library/ZT-NewsletterNov.pdf), both read on 16 September 2026. An earlier assessment in summer 2023 tested the 91 Target activities. In a written statement for the record to a House Armed Services subcommittee on 8 May 2025 (listed under documents), the DoW CIO said Flank Speed and Thunderdome both achieved Advanced Level, without giving a count. A reported 152 of 152 result for Flank Speed appears only in news coverage and conflicts with both publisher pages.

What an adopting organization still owns

A February 2022 Navy message says Echelon II command information officers and their teams lead the planning and scheduling that give their commands' users access and migrate their email accounts, and that commands work with the SharePoint Online development team to establish sites, move command data and shift workflows. Verified, checked 16 Sep 2026
NAVADMIN 030/22 (Navy specific administrative message) of 7 February 2022 (https://www.mynavyhr.navy.mil/Portals/55/Messages/NAVADMIN/NAV2022/NAV22030.txt), read on 16 September 2026: Echelon II command information officers lead the planning and scheduling for access and account migration, and commands work with the SharePoint Online team to establish sites, move command data and shift workflows. It describes moving onto the service, not zero trust activities.
The published count covers Flank Speed as assessed in spring 2024, not the other systems of the commands that use it, and no publisher page names the one Advanced activity the assessment did not find met. Authored
The app's own reading, not a Navy or CIO statement. The activities table marks work as enterprise or component, and a component there is a DoW component, here the Department of the Navy, which delivers Flank Speed; the commands that use it are not components. The Navy reports the service met all 91 Target activities, which include those the table marks as component work, and 60 of 61 Advanced activities without naming the one not met. No Navy or CIO page checked on 16 September 2026 states what a command using Flank Speed still owns for zero trust.

Nature: Enterprise service
Binds: Organizations that adopt it
Deadline: None
Note: Has no force of its own; it applies to the commands that adopt it. It is centrally funded at the Navy enterprise level, and Navy and Department of the Navy Secretariat commands that want its services request them from the service's account team. Verified, checked 16 Sep 2026

Publisher: Department of the Navy CIO
Edition: Joint memorandum Ser CIO/25-0001
Date: 15 Jan 2025
Primary: https://www.doncio.navy.mil/FileHandler.ashx?id=23732
Verification: Verified, checked 16 Sep 2026 Joint memorandum of the Department of the Navy CIO and the Assistant Secretary of the Navy for Research, Development and Acquisition, read on 16 September 2026: Flank Speed and Hyperion are the Navy and Marine Corps unclassified Microsoft 365 cloud environments; the designation covers the Impact Level 5 software-as-a-service productivity and messaging services.

Documents

DON's Flank Speed Service Sets New Standard for Zero Trust in DOD, Department of the Navy CIO article, 28 Oct 2024. Primary Verified, checked 16 Sep 2026
Zero Trust PfMO (Portfolio Management Office) Newsletter, Nov 2024. Primary Verified, checked 29 Sep 2026
Statement on Information Technology and Artificial Intelligence Posture of Department of Defense, record version, as printed on the cover: before the Subcommittee on Cyber, Innovative Technologies, and Information Systems, Committee on Armed Services, U.S. House of Representatives, 119th Congress (the committee lists the hearing under the Subcommittee on Cyber, Information Technologies, and Innovation), 8 May 2025. Authors: Katherine E. Arrington, Performing the Duties of Department of Defense Chief Information Officer. Primary Verified, checked 29 Sep 2026 The department CIO's written statement for the record; cited for the Advanced Level statement only.

Glossary

Every abbreviation Framework Maps uses, spelled out, with a plain sentence on what it is. Each spelling was checked against its publisher; an entry carries a badge only where that could not be confirmed. Each section also spells out an abbreviation where it first appears, except AI, which every reader knows.

AI: artificial intelligence. In the AI Risk Management Framework from NIST (National Institute of Standards and Technology), an AI system is an engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations or decisions. See: AI RMF
AI RMF: Artificial Intelligence Risk Management Framework. NIST's framework for managing the risks that artificial intelligence poses to individuals, organizations and society. See: AI RMF
ATO: authorization to operate. A senior official's decision to let an information system operate and to accept the risk that remains. See: RMF / ATO
ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. MITRE's public catalog of the tactics and techniques attackers use, built from observed attacks; the long form is printed in a 2017 MITRE technical report, and MITRE now uses ATT&CK as a registered trademark.
C3PAO: CMMC (Cybersecurity Maturity Model Certification) Third-Party Assessment Organization. An organization authorized or accredited to conduct CMMC Level 2 certification assessments. See: CMMC
CC BY: Creative Commons Attribution. An open license that lets anyone share and adapt the material for any purpose, even commercially, provided they give appropriate credit, link to the license and say if they made changes; Lensatic's own text was released under it through content version 0.6.0.
CC BY-SA: Creative Commons Attribution-ShareAlike. An open license that allows reuse with credit, provided anyone who distributes an adaptation uses the same license. See: AI Defense Matrix
CFR: Code of Federal Regulations. The codification of the general and permanent rules that federal departments and agencies publish in the Federal Register. See: CMMC
CIO: Chief Information Officer. The senior official responsible for an organization's information technology; the department's CIO publishes its zero trust strategy. See: DoD ZT Strategy
CIS: Center for Internet Security. A nonprofit that publishes the CIS Controls and the CIS Benchmarks, guidance for securing computer systems and data.
CISA: Cybersecurity and Infrastructure Security Agency. The federal agency that works with partners to defend against cyber threats; it published the civilian Zero Trust Maturity Model. See: CISA ZTMM
CMMC: Cybersecurity Maturity Model Certification. The department's program for verifying that contractors meet the security requirements for the information they handle. See: CMMC
COA: course of action. One of the three routes the department's zero trust roadmap offers: uplifting legacy systems, commercial cloud, or purpose-built on-premise cloud. See: DoD ZT Roadmap
Community Profile: A baseline of CSF (Cybersecurity Framework) outcomes created and published to address shared interests and goals among a number of organizations, typically for a sector, technology or threat type. See: CSF 2.0, Cyber AI Profile
CORA: Cyber Operational Readiness Assessment. The department's readiness assessment of its networks; in 2024 its former cyber readiness inspection program was reworked and renamed CORA. See: CORA
CoSAI: Coalition for Secure AI. An OASIS Open Project in which experts from many organizations write guidance for securing AI systems. See: CoSAI ZT for AI
CSF: Cybersecurity Framework. NIST's taxonomy of high-level cybersecurity outcomes that any organization can use to understand, assess, prioritize and communicate its cybersecurity efforts. See: CSF 2.0
CSRC: Computer Security Resource Center. NIST's website for its computer security publications, projects and glossary.
CSRMC: Cybersecurity Risk Management Construct. An approach to cybersecurity risk in five phases that the Department of War (DoW) CIO announced on 24 September 2025 and presents as the successor to the RMF process. See: RMF / ATO
CSWP: Cybersecurity White Paper. A NIST publication series; CSF 2.0 was published as CSWP 29. See: CSF 2.0
CUI: Controlled Unclassified Information. Government information that is not classified but that a law, regulation or government-wide policy requires or permits agencies to safeguard or control. See: SP 800-171
DCDC: Department of Defense Cyber Defense Command. The U.S. (United States) Cyber Command component that leads network operations, security and defense across the department's information network; its site now also uses the name Department of War Cyber Defense Command. See: CORA
DCMA: Defense Contract Management Agency. The department agency that works directly with defense suppliers so the government receives quality products on time and at projected cost. See: CMMC
DCSA: Defense Counterintelligence and Security Agency. The department agency that vets the federal and contractor workforce and oversees industrial security for cleared contractors; it also runs cyber operational readiness assessments of contractors with approved SIPRNet (Secret Internet Protocol Router Network) systems. See: CORA
DFARS: Defense Federal Acquisition Regulation Supplement. The department's implementation of, and supplement to, the Federal Acquisition Regulation, including the contract clauses on contractor cybersecurity. See: CMMC, SP 800-171
DIB: Defense Industrial Base. The U.S. and allied companies and organizations that research, design, produce, deliver and maintain the department's systems and parts. See: CMMC
DIBCAC: Defense Industrial Base Cybersecurity Assessment Center. The Defense Contract Management Agency center that assesses contractors' compliance with DFARS cybersecurity clauses and NIST SP (Special Publication) 800-171, and the only body designated to assess CMMC Level 3. See: CMMC
DISA: Defense Information Systems Agency. The department agency that plans, builds and operates information-sharing capabilities and a global enterprise infrastructure; it runs Thunderdome. See: Thunderdome
DLP: Data Loss Prevention. A system's ability to identify, monitor and protect data in use, in motion and at rest. See: DoD ZT Roadmap
DoD: Department of Defense. The department's name in law; titles of documents issued under it are shown here as printed, with DoD. See: DoD ZT Strategy
DOI: Digital Object Identifier. A persistent identifier for a publication or other object; NIST technical publications carry one. See: SP 1800-35
DON: Department of the Navy. The military department for the Navy and Marine Corps; a joint memorandum from its CIO designated Flank Speed's productivity and messaging services an enterprise IT service. See: Flank Speed
DoW: Department of War. The secondary name the department has used since September 2025; its title in law is still Department of Defense.
DTM: directive-type memorandum. A department issuance that establishes or implements policy, assigns responsibilities and may provide procedures. See: DoD ZT Strategy
EDR: Endpoint Detection & Response. Tools that monitor, detect and remediate malicious activity on endpoints. See: DoD ZT Roadmap
EO: Executive Order. A directive from the President to the executive branch, published in the Federal Register. See: EO 14028, EO 13800
FAR: Federal Acquisition Regulation. The primary document of the system of uniform policies and procedures for acquisition by all executive agencies; agency regulations such as DFARS implement or supplement it.
FCI: Federal contract information. Information not intended for public release that is provided by or generated for the government under a contract. See: CMMC
FedRAMP: Federal Risk and Authorization Management Program. The governmentwide program that provides a standardized approach to security and risk assessment for cloud products and services.
FISMA: Federal Information Security Modernization Act. The federal law, first enacted in 2002 as the Federal Information Security Management Act and amended in 2014 by the Federal Information Security Modernization Act, that requires each agency to develop, document and implement an agency-wide information security program. See: CSF 2.0
FR: Federal Register. The official daily publication of federal rules, proposed rules, notices and executive orders, cited by volume and page, as in 86 FR 26633.
FY: fiscal year. The federal budget year, which begins on 1 October and ends on 30 September of the following year, as in FY2027.
H.R.: House of Representatives. The prefix on a bill introduced in the House, as in H.R. 8800; the number stays with the bill through every stage.
IBM: International Business Machines. The technology company that designed the IBM Plex typefaces Lensatic is set in and holds their copyright.
ICAM: Identity, Credential and Access Management. The programs, processes, technologies and people used to create trusted digital identities, bind them to credentials, and use those credentials for access. See: DoD ZT Roadmap
IEC: International Electrotechnical Commission. The international body that writes standards for electrical and electronic technology, including the IEC 62443 series. See: ZT for OT
IL: Impact Level. The department's cloud security levels, set by how sensitive the information is and the potential impact if it is compromised.
IR: Incident Response. The remediation or mitigation of violations of security policies and recommended practices. See: DoD ZT Roadmap
ISO: International Organization for Standardization. An international standards organization.
IT: information technology. Equipment and systems used to acquire, store, process and move data or information.
JFHQ-DODIN: Joint Force Headquarters-Department of Defense Information Network. The command that launched CORA in 2024, since renamed the Cyber Defense Command. See: CORA
MDM: Mobile Device Management. The administration of mobile devices such as smartphones, tablets and laptops, usually through a third-party product. See: DoD ZT Roadmap
MFA: Multi-Factor Authentication. Proving identity, for a user or a non-person entity, with at least two of three factors: something you know, something you have, or something you are. See: DoD ZT Roadmap
MIT License: A short permissive software license: anyone may use, copy, modify, merge, publish, distribute, sublicense or sell the code, provided the copyright notice and the permission notice stay with it; Lensatic's code was released under it through content version 0.6.0.
MITRE: The organization that maintains ATT&CK, a public catalog of the tactics and techniques attackers use.
NAVADMIN: Navy specific administrative message. An administrative message specific to the Navy, as the Navy glosses the term; one sets out who leads migration onto Flank Speed. See: Flank Speed
NCCoE: National Cybersecurity Center of Excellence. A NIST hub where industry, government and academia work together on businesses' most pressing cybersecurity challenges; it produced the zero trust practice guide. See: SP 1800-35
NDAA: National Defense Authorization Act. The law, passed for each fiscal year, that authorizes appropriations for the Department of Defense and sets defense policies.
NIST: National Institute of Standards and Technology. A U.S. Department of Commerce agency, founded in 1901, that publishes the Cybersecurity Framework and the Special Publications cited here. See: CSF 2.0
NIST IR: NIST Internal Report. A NIST report series; the Cyber AI Profile draft is NIST IR 8596. See: Cyber AI Profile
NSA: National Security Agency. The agency that leads U.S. government cryptology, including cybersecurity products and services; it publishes zero trust guidance for owners of National Security Systems, department networks and the defense industrial base. See: NSA ZT guidance
OASIS Open: A nonprofit standards body that hosts open projects, CoSAI among them. See: CoSAI ZT for AI
OFL: SIL Open Font License. A free license for typefaces, published by SIL: anyone may use, change and share the fonts, including inside software, but may not sell the fonts on their own; the typefaces Lensatic uses are under version 1.1.
OMB: Office of Management and Budget. The White House office whose memoranda direct federal agencies, including the zero trust memo M-22-09. See: M-22-09, M-25-21
OT: operational technology. Programmable systems and devices that interact with the physical environment, such as industrial control and building automation systems. See: ZT for OT
PAM: Privileged Access Management. How an organization controls, monitors, secures and audits privileged identities, for example through password vaulting. See: DoD ZT Roadmap
PDF: Portable Document Format. A file format that represents formatted, page-oriented documents.
PDP: Policy Decision Point. The part of a zero trust system that computes access decisions by evaluating the applicable policies. See: DoD ZT Roadmap, SP 800-207
PfMO: Portfolio Management Office. The office in the department CIO's organization that provides strategic guidance, aligns efforts and prioritizes resources to accelerate zero trust adoption. See: DoD ZT Strategy
PMO: Program Management Office. The department CIO's CMMC office, which oversees the CMMC program, including its accreditation body. See: CMMC
RMF: Risk Management Framework. NIST's process that builds security, privacy and cyber supply chain risk management into a system's development life cycle. See: RMF / ATO
S.: Senate. The prefix on a bill introduced in the Senate, as in S. 4784; the number follows the order in which bills are introduced.
SDN: Software Defined Networking. Programmable network infrastructure that separates the control and data planes so the network can be centrally managed. See: DoD ZT Roadmap
SIEM: Security Information and Event Management. A program that provides centralized logging for many types of logs. See: DoD ZT Roadmap
SIL: The language-development organization, now SIL Global, that publishes the SIL Open Font License.
SIPRNet: Secret Internet Protocol Router Network. The department's classified network for moving secret information, provided as a DISA transport service. See: CORA
SOAR: Security Orchestration, Automation & Response. Tools that ingest alert data and trigger automated response and remediation to speed up security operations and incident response. See: DoD ZT Roadmap
SOC: security operations center. The unit that runs an organization's security operations; the AI column's worked example is a Profile for an AI-enabled one.
SP: Special Publication. A NIST publication series; the SP 800 documents cover computer security. See: SP 800-53
SPRS: Supplier Performance Risk System. The system in which the department sees contractors' SP 800-171 assessment scores and their CMMC status; under DFARS 252.204-7019 an offeror that must meet SP 800-171 needs a current score posted there to be considered for award. See: SP 800-171, CMMC
SRG: security requirements guide. A compilation of security requirements grouped by technology area and product specificity. See: SP 800-53
STIG: security technical implementation guide. An implementation guide for securing a specific product and version, based on department policy and security controls. See: SP 800-53
U.S.: United States. The abbreviation for United States, as in U.S. Government.
U.S.C.: United States Code. The consolidation and codification, by subject matter, of the general and permanent laws of the United States.
UEM: Unified Endpoint Management. A centralized solution that manages computers and mobile devices, with or without an agent, from a single console. See: DoD ZT Roadmap
UFC: Unified Facilities Criteria. Department of Defense criteria for the planning, design, construction, sustainment, restoration and modernization of facilities; UFC 4-010-06 covers the cybersecurity of facility-related control systems. See: ZT for OT
URL: Uniform Resource Locator. An identifier that names a resource and also says how to locate it, as a web page's address does.
XDR: Extended Detection & Response. Detection and response tooling that extends beyond endpoints to activity such as cloud and network. See: DoD ZT Roadmap
ZIG: Zero Trust Implementation Guidelines. NSA's series of guides that set out steps to reach the department's Target Level zero trust capabilities, activities and outcomes. See: NSA ZT guidance
ZT: zero trust. A security model in which nothing is trusted because of where it connects from, and every request is checked against policy. See: SP 800-207, DoD ZT Strategy
ZTA: zero trust architecture. A plan that uses zero trust principles to lay out an organization's industrial and enterprise infrastructure and workflows. See: SP 800-207
ZTMM: Zero Trust Maturity Model. CISA's model for measuring a civilian agency's zero trust progress in five pillars and four stages. See: CISA ZTMM

About

Framework Maps Content version 1.2.14

Framework Maps is a wayfinder, not a crosswalk. It guides you, showing which framework answers which question and how the trails converge, so you know your bearing before you step into a control catalog or navigate the cyber assurance terrain.

Not affiliated with NIST (National Institute of Standards and Technology), CISA (Cybersecurity and Infrastructure Security Agency), NSA (National Security Agency), Department of War, OMB (Office of Management and Budget), or any framework publisher.

Department of War is a secondary name, authorized by executive order in September 2025, for the Department of Defense (DoD); the statutory title has not changed, and documents issued under the old name say DoD.

The statutory title remains Department of Defense pending Congress. On 9 September 2026, 10 U.S.C. (United States Code) 111 still read Department of Defense (text current through 8 September 2026); the FY2026 (fiscal year) National Defense Authorization Act, enacted 18 December 2025 as Public Law 119-60, did not change it; the FY2027 bill the House of Representatives passed on 22 July 2026 as H.R. 8800 carries a section deeming statutory references to the Department of Defense to be references to the department's current name, and the Senate bill (S. 4784) carries a section redesignating the department in titles 10, 32 and 37; neither is law.

No account. No data collected.

Most of the frameworks Lensatic describes are United States government publications. Works prepared by United States government officers and employees as part of their official duties are in the public domain in the United States. Lensatic's own code and text are copyright 2026 Ken Connell, all rights reserved; to ask about reusing them, open an issue on the source repository. IBM (International Business Machines) Corp. holds the copyright in the typefaces, IBM Plex Sans and IBM Plex Mono, which are licensed under the SIL Open Font License (OFL), version 1.1. Where a cited work is protected, its title, names and any short quotation remain its owner's, and the work itself is described, not reproduced.

Verification counts:

Verified 167Authored 91Unverified 13Conflict 1

What the status labels mean

Verified: the publisher's own copy was read on the date shown and matches.
Authored: this app's own synthesis of the cited sources, not a quotation. Trailhead steps, matrix cells and helper answers are all authored, even where no label is shown.
Unverified: the publisher's copy could not be reached; the note lists every address tried.
Conflict: the sources disagree; the note gives both and a date to check again.

Made by Ken Connell

Built with Claude and Claude Code, reviewed by a human who owns the mistakes.

Why 'Lensatic'

My lensatic compass, open, with the sighting wire raised.

A lensatic compass is the Army's field compass. You sight a landmark through its lens, read the bearing off the dial, and move out knowing which way you're headed. Lensatic does the same for the framework stack: find where you stand, see which framework applies, and take a bearing on what comes next.

I learned land navigation with one in the Army and have kept it for more than 20 years. This one is mine.