| Capability-based TIC (OMB M-19-26) |
Rescinds the consolidation memoranda (M-08-05, M-08-16, M-08-27, M-09-32) and replaces mandatory routing through access points with capability-based use cases |
Ch 01, Ch 02, Ch 03 |
The agency’s TIC use-case mapping; architecture documentation for each branch pattern |
| TIC 3.0 Security Capabilities Catalog, v3.3 (CISA) |
Goals, not methods: 20 universal capabilities for every use case and PEP capabilities in 12 groups. Once a capability is needed, apply it at all access points to that network or data (policy enforcement parity). No telemetry duration or timeliness requirement, but law, OMB and CISA telemetry requirements still apply |
Ch 03, Ch 05, Ch 08 |
Capability-to-control mapping for each enforcement point; parity evidence across campus, branch and SASE paths |
| TIC 3.0 Branch Office Use Case, v3.0 (CISA) |
Three security patterns (branch to cloud, to web, to campus), each with options for where enforcement happens; greatest rigor on branch-to-web; where multiple conveyances such as redundant links or SD-WAN exist, security parity on every path; “agencies must preserve CISA visibility” |
Ch 03, Ch 05, Ch 08, Ch 10, Ch 11 |
Per-pattern data-flow diagrams; enforcement placement per path; path-priority and failover configuration showing parity |
| TIC 3.0 Cloud and Remote User use cases (CISA) |
Protections for agency use of cloud services and for users off the agency network; a SASE deployment at branches operates under Branch Office and Cloud, since there is no SASE use case |
Ch 03, Ch 05, Ch 12 |
Use-case mapping for each cloud service and remote access method |
| TIC telemetry continuity (TIC 3.0 Program Guidebook; CISA SASE guidance) |
TIC doesn’t replace or negate telemetry requirements. When branches leave MTIPS, the E1E telemetry from access-point sensors stops; agencies can send comparable telemetry to CISA’s Comprehensive Log Aggregation Warehouse (CLAW), which needs coordination among the agency, CISA and the provider |
Ch 03, Ch 09, Ch 11, Ch 13 |
CLAW onboarding record; CISA confirmation of equivalent visibility before MTIPS is decommissioned |
| Protective DNS for all egress (6 U.S.C. § 663 note; OMB M-22-09; CISA Encrypted DNS Implementation Guidance) |
Agencies must route all egress DNS to CISA’s Protective DNS, disable root hints on agency DNS infrastructure, and permit external third-party resolvers only from authorized internal DNS servers; agencies “are already required to have DNS requests routed through CISA-operated infrastructure” |
Ch 03, Ch 05, Ch 08 |
Forwarding chain from internal resolvers to Protective DNS; SD-WAN or SASE DNS configuration; tests showing no endpoint agent resolves through a vendor cloud |
| Encrypted DNS and HTTPS (OMB M-22-09) |
“Agencies must resolve DNS queries using encrypted DNS wherever it is technically supported”; enforce HTTPS for all web and API traffic in the environment; a zero trust architecture plan describing the approach to environmental isolation |
Ch 03, Ch 10 |
Resolver and endpoint encrypted DNS configuration; HTTPS enforcement; the isolation plan |
| Logging and network visibility (OMB M-26-14, which rescinds M-21-31) |
Prioritize continuous event monitoring and threat hunting, investigation, response and forensics; an Agency Logging Plan 90 days after CISA’s Logging Reference Architecture (published August 20, 2026); maturity Levels 1, 2 and 3 at 120, 180 and 320 days; minimum logs include “source and destination network address information, including protocols, ports, and session attributes” |
Ch 03, Ch 10, Ch 13 |
Agency Logging Plan; maturity self-assessment per system; flow and session logs from every branch enforcement point |
| Management interfaces (CISA BOD 23-02) |
Management interfaces of routers, switches, firewalls, VPN concentrators, proxies and load balancers that are reachable from the internet: within 14 days remove them from the internet or, preferably, enforce access “through a policy enforcement point separate from the interface itself” |
Ch 03, Ch 10 |
External scan results; management-plane access path; PEP policy |
| End-of-support edge devices (CISA BOD 26-02) |
Internet-accessible devices on the agency boundary that are end of support: inventory by May 5, 2026; decommission those ending support by February 5, 2027; all identified devices removed by August 5, 2027; continuous discovery by February 5, 2028 |
Ch 02, Ch 03, Ch 05, Ch 07, Ch 08, Ch 09, Ch 10 |
EOS inventory submissions to CISA; decommission reports; replacement specifications |
| Risk-based vulnerability remediation (CISA BOD 26-04, which revokes BOD 22-01 and BOD 19-02) |
Remediation timelines set by asset exposure, KEV status, exploit automation and technical impact; Phase II by August 9, 2026; Phase III, including continuous tagging of internet-reachable assets, by December 7, 2026 |
Ch 02, Ch 03, Ch 05, Ch 08, Ch 10 |
Vulnerability management policy; asset tags for branch edges and controllers; CDM reporting |
| Post-quantum key exchange (OMB M-26-15; EO 14412) |
All network infrastructure terminating TLS or IPsec, “including firewalls, Virtual Private Network concentrators, cloud gateways,” must support PQC-capable key exchange using NIST algorithms; migration plan within 120 days (October 22, 2026); mitigate quantum risk as far as feasible by December 31, 2030 |
Ch 03, Ch 10, Ch 11 |
Cryptographic inventory of branch devices; PQC capability in replacement specifications; the migration plan |
| TLS 1.3 (NIST SP 800-52 Rev. 2; EO 14306) |
SP 800-52 Rev. 2 requires TLS 1.3 support by January 1, 2024; EO 14306 separately sets “not later than January 2, 2030” for TLS 1.3 or a successor as a post-quantum readiness date |
Ch 03, Ch 10 |
TLS configuration of branch-facing services and enforcement points |
| Encryption in transit (EO 14028 §3(d); BOD 18-01) |
Adopt encryption in transit “to the maximum extent consistent with Federal records laws and other applicable laws,” naming no protocol or layer; HTTPS and HSTS on public websites and STARTTLS on internet-facing mail servers |
Ch 03 |
Encryption coverage by flow; public-facing HTTPS and mail scans |
| Cryptographic modules (FIPS 140; CMVP) |
All FIPS 140-2 certificates moved to the Historical List on September 22, 2026; CMVP supports their purchase and use for existing systems, and agencies set their own move to FIPS 140-3 |
Ch 03, Ch 09, Ch 10, Ch 11 |
Module certificates for every encrypting device; validation language in acquisition documents |
| Boundary protection (SP 800-53 SC-7, SC-7(4), SC-7(8)) |
Monitor and control communications at external managed interfaces; a managed interface and traffic flow policy for each external telecommunication service, with documented and reviewed exceptions; route defined traffic through authenticated proxies |
Ch 03, Ch 05, Ch 08, Ch 12, Appendix A |
Managed-interface inventory per branch; traffic flow policy; exception register and review records |
| Transmission protection (SP 800-53 SC-8, SC-8(1), SC-13) |
Protect transmitted information by physical or logical means; cryptographic mechanisms “include TLS and IPSec”; the agency selects cryptographic uses and types |
Ch 03, Ch 05, Ch 10 |
End-to-end TLS evidence; the cleartext-protocol exposure register with a disposition for each flow |
| Flow enforcement and nonsecure protocols (SP 800-53 AC-4, CM-7(1)) |
Enforce approved information flows; periodically review and disable nonsecure ports, protocols and services (FTP is named) |
Ch 03, Ch 10 |
Flow policy; protocol review records |
| Monitoring and remote access (SP 800-53 SI-4, CA-7, AC-17, AU-12) |
Detect attacks and indicators of attack; continuous monitoring strategy and metrics; control and monitor remote access; generate audit records |
Ch 03, Ch 05, Ch 07, Ch 13 |
Per-application and per-path telemetry; SIEM ingestion; continuous monitoring reports |
| Telecommunications diversity (SP 800-53 CP-8, CP-8(1), CP-8(2), CP-8(3)) |
Alternate telecommunications services; avoid sharing a single point of failure with the primary; CP-8(3), provider separation, is in the High baseline only |
Ch 02, Ch 03, Ch 05, Ch 09, Ch 11 |
Circuit diversity records; provider and physical-path documentation |
| Device and network access authentication (SP 800-53 IA-3; 802.1X) |
Identify and authenticate devices before establishing a connection |
Ch 07; Book 07 Chapter 06 |
NAC and RADIUS policy; certificate enrollment records |
| Zero trust architecture (CISA Zero Trust Maturity Model v2.0; NIST SP 800-207) |
ZTMM is “a general guide,” not “a strict set of requirements”; its cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance) apply to every pillar |
Ch 03, Ch 04, Ch 05 |
Network-pillar maturity self-assessment |
| Authentication assurance (NIST SP 800-63B-4) |
Authenticator and reauthentication requirements by assurance level; the operative source for session and reauthentication intervals, which M-22-09 doesn’t set |
Ch 06; Book 04 Chapter 03 |
Conditional Access and session policy |
| Cloud service certification (FedRAMP Consolidated Rules for 2026) |
FedRAMP certifies cloud services; “each agency still authorizes its own federal information systems,” and an agency “should never create a standalone authorization to operate for a cloud service offering.” It sets no requirement on the route to a service |
Ch 03, Ch 05, Ch 12 |
FedRAMP Marketplace listing for each SASE or SSE service; the agency’s own system authorization and boundary diagram |
| Telecommunications contract vehicle (GSA EIS) |
Networx and WITS 3 have expired; EIS option period 1 runs to July 31, 2027; MTIPS is an EIS service |
Ch 03, Ch 09, Ch 10 |
EIS task orders and service inventory |