What is the OMB M-26-15 TLS 1.3 2030 requirement?

The OMB M-26-15 TLS 1.3 2030 requirement is the instruction that U.S. federal agencies must support TLS version 1.3 no later than January 2, 2030. It sits inside a wider mandate that high value assets and high impact systems switch to quantum-resistant key establishment by December 31, 2030. For operators of OT and critical infrastructure, it is the clearest public signal yet of when classical-only encrypted connections stop being acceptable.

The memo was issued as Office of Management and Budget (OMB) Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography (June 24, 2026). It came two days after Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks (June 22, 2026). NIST then turned both documents into a technical roadmap in the final version of NIST IR 8547.

What does OMB M-26-15 require for TLS 1.3 support by January 2, 2030?

Agencies must be able to negotiate TLS 1.3 by January 2, 2030. The deadline is about protocol version support, and it is meant as the base for post-quantum key exchange, not as a goal in its own right.

NIST IR 8547 states that agencies are also required by Executive Order 14306 and OMB Memorandum M-26-15 to support TLS version 1.3 no later than January 2, 2030. NIST explains why: TLS 1.3 also provides a practical near-term path to quantum-resistant key establishment, including through hybrid key-exchange mechanisms that combine ML-KEM with classical algorithms.

This is a real change from current federal TLS guidance. Under NIST SP 800-52 Revision 2, the client shall be configured to use TLS 1.2 and should be configured to use TLS 1.3. M-26-15 turns TLS 1.3 from a “should” into a dated obligation. That matters because hybrid ML-KEM key exchange is defined for TLS 1.3 handshakes. A TLS 1.2-only server, appliance or HMI web interface has no standard way to offer it.

The memo also covers systems that cannot make the move. Systems that cannot support post-quantum cryptography should be identified and prioritized for replacement or decommissioning. In OT environments, that sentence may affect asset lifecycle budgets more than the TLS deadline itself.

How does Executive Order 14412 change post-quantum deadlines for key establishment?

EO 14412 moves the deadline for the most sensitive federal systems forward by five years: post-quantum key establishment is now due by the end of 2030 instead of the earlier 2035 target. The broader 2035 goal still applies to everything else.

NIST sums up the shift this way: National Security Memorandum 10 established the year 2035 as the primary target for completing the migration to PQC across federal systems. Executive Order 14412 accelerated this timeline, requiring federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures. In practice, high impact means systems for which at least one FIPS 199 security objective is assigned a potential impact value of “high”.

Key establishment comes first because of “harvest now, decrypt later”: today’s encrypted data is already at risk from the “harvest now, decrypt later” threat, where adversaries collect sensitive data now with the intention of decrypting it when quantum technology matures. Signatures only have to hold up while they are being checked. Key exchange protects confidentiality for as long as the data stays sensitive.

The 2030 to 2035 window does not loosen the earlier deadlines. NIST says plainly that this window does not alter the earlier deadlines that apply to high value assets, high impact systems, and other high-sensitivity federal systems under EO 14412 and OMB M-26-15. The memo also reaches beyond formal high value assets: it covers systems that protect data expected to remain mission-sensitive in 2030. Process designs, grid topology and network diagrams for OT often meet that test.

Will the next revision of NIST SP 800-52 require hybrid ML-KEM key exchange in TLS?

NIST has confirmed that the next revision of SP 800-52 will cover hybrid key exchange. It has not yet published whether hybrid ML-KEM will be mandatory or only one approved option.

The official wording in NIST IR 8547 is: Guidance on the use of quantum-resistant key establishment in TLS, including hybrid key-exchange mechanisms, will be reflected in the next revision of SP 800-52. Read it carefully. The text promises guidance on hybrid mechanisms. It does not promise a hybrid-only requirement, and pure ML-KEM key exchange could also end up being allowed.

For planning, the safe assumption is that federal TLS profiles will expect key establishment based on ML-KEM, the mechanism specified in FIPS 203. ML-KEM is one of the post-quantum standards that, according to CISA, On August 13, 2024, NIST approved three PQC standards (FIPS 203, FIPS 204, and FIPS 205). Hybrid pairing with a classical algorithm is the near-term route NIST names in IR 8547. Teams that test hybrid TLS 1.3 groups now will be ready for either version of the final rule.

Do the federal TLS requirements apply to critical infrastructure contractors and utilities?

OMB M-26-15 binds federal agencies, not private utilities. Even so, contractors and operators that connect to federal systems are likely to inherit its requirements through acquisition rules and interconnection agreements.

The contracting route is spelled out. The NIST NCCoE describes EO 14412 as establishing binding deadlines for high-value assets and directing the Federal Acquisition Regulatory Council to require contractor compliance with NIST PQC standards. Until that FAR rule exists, the exact contract clauses are unknown. Firms that run systems for agencies, or whose systems exchange encrypted traffic with them, should expect the requirement to apply to them.

Procurement creates a second pull. CISA advises that because PQC-capable products are widely available in the listed categories, organizations should acquire only PQC-capable products when planning acquisitions and procuring products in these categories. Product vendors are likely to follow that market signal. As a result, equipment and software bought for non-federal utilities will also start shipping with PQC support.

For operators with no federal contract, the guidance is advisory but specific. CISA works with Sector Risk Management Agencies (SRMA) to assist critical infrastructure owners and operators in developing PQC migration planning. NIST positions IR 8547 as a blueprint for critical infrastructure owners and operators and other organizations undergoing the same shift. CISA’s earlier analysis found that quantum computing poses new risks to critical infrastructure systems across the 55 NCFs (National Critical Functions, 2022).

Mona Harrington, then acting Assistant Director of CISA’s National Risk Management Center, put it this way: “Critical infrastructure and government leaders must be proactive and begin preparing for the transition to post-quantum cryptography now.”

What should operators do now with edge-to-data-centre TLS connections to meet the 2030 deadline?

Start with an inventory by connection, not by device. Then split the work into two tracks: endpoints that can be moved to TLS 1.3 with hybrid ML-KEM, and paths whose endpoints cannot. The second track needs network-layer protection and a plan to replace the equipment.

Inventory every encrypted path, including the ones that are not TLS

Edge-to-data-centre traffic in OT rarely runs over a single protocol. Historian replication, SCADA-to-control-centre links, remote engineering sessions and cloud telemetry each have their own handshake. For each path, record the TLS version, the negotiated key exchange group, who controls each endpoint, and how long the data must stay confidential. This matches what CISA asks of agencies: a current inventory of IT vulnerable to quantum decryption. Data with a long confidentiality life goes first, because NIST notes that systems that protect data with long-term confidentiality needs warrant the earliest transitions.

Separate the version problem from the key exchange problem

A gateway, broker or web server running TLS 1.2 needs a software or firmware upgrade before any post-quantum work is possible. A TLS 1.3 endpoint may only need a configuration change to offer a hybrid ML-KEM group, provided its cryptographic library supports one. Track the two as separate milestones with separate owners. Firmware upgrades in substations or plants follow outage windows, while configuration changes in a data centre do not.

Test inspection points and handshake size before production

TLS 1.3 already makes passive inspection harder, which is why NIST published SP 1800-37, Addressing Visibility Challenges with TLS 1.3 within the Enterprise. ML-KEM key shares make the ClientHello much larger than a classical one. Older middleboxes, proxies and some industrial firewalls may drop or fragment these handshakes. Run hybrid TLS 1.3 sessions through the actual path, including any inspection points and links with constrained MTU, before you set a cutover date.

Protect paths whose endpoints cannot be upgraded

Many PLCs, RTUs and vendor-managed appliances will not support TLS 1.3 before 2030. For those links, one interim measure is to encrypt the network path between sites with hybrid post-quantum key agreement. QPN from Quantum Network is one example: a gateway at each end encrypts at Layer 3, combines a classical and an ML-KEM (FIPS 203) handshake into one session key, and runs alongside existing firewalls without software on the devices behind it. Be clear about what this does and does not do. It protects data in transit between sites. It does not change the TLS version an endpoint supports, so the device still belongs on the replacement list in your inventory.

Build agility and supplier questions into contracts now

Because the SP 800-52 revision is still pending, choose components where the post-quantum algorithm can be swapped by update rather than by hardware replacement. Use CISA’s product category list in tenders, and ask suppliers for dated roadmaps for TLS 1.3 and ML-KEM support. NIST warns that past cryptographic migrations have taken over a decade, and this more complex migration will likely take at least that long. Dustin Moody of NIST pointed to IR 8547 as the reference: “The new report can help you understand the standards and requirements of the migration”. In OT, procurement cycles are often longer than the four years left before the deadline, so contract language written today decides which connections will be ready in 2030.

A realistic sequence for most operators: finish the connection inventory in the first planning cycle, upgrade data-centre and cloud TLS endpoints to hybrid TLS 1.3 next, and use network-layer protection for the remaining edge paths until the equipment is replaced.