How NIST IR 8547 Final Affects TLS 1.3 and PQC Migration
“We already use TLS 1.3.”
Where? On the public website, at the load balancer, or across the connections behind it?
And what does it actually negotiate?
NIST IR 8547 Final makes those questions harder to leave unanswered. Published on 27 October 2026, the report sets out the transition away from quantum-vulnerable public-key cryptography. Its implications for Transport Layer Security extend beyond enabling a protocol version.
The distinction is evidence. Supporting TLS 1.3 does not prove it is deployed across an organisation. Deploying TLS 1.3 does not prove its connections use post-quantum cryptography.
What does NIST IR 8547 Final mean for TLS?
NIST IR 8547 does not replace TLS or define a new version of the protocol. It sets out how quantum-vulnerable cryptographic algorithms will be transitioned out of NIST standards and guidelines.
For TLS, this affects the public-key mechanisms used to establish session secrets and authenticate communicating parties. TLS 1.3 provides a platform for deploying post-quantum key establishment, but its version number alone says nothing about whether that protection was negotiated.
The practical consequence is straightforward: organisations need to identify their TLS deployments, understand the algorithms operating within them, and plan the migration of confidentiality and authentication separately.
Our NIST IR 8547 comparison briefing explains what changed between the November 2024 draft and the final report.
TLS has different cryptographic functions
A statement such as “our TLS is encrypted” conceals several distinct functions.
Function | Purpose | PQC migration consideration |
Key establishment | Establishes shared secret material from which session keys are derived | Classical elliptic-curve and finite-field mechanisms are quantum-vulnerable |
Authentication | Establishes identity through certificates, signatures and trust relationships | RSA, ECDSA and other quantum-vulnerable signature schemes need a separate transition |
Symmetric protection | Encrypts and authenticates application traffic using established keys | PQC migration does not mean replacing all existing symmetric cryptography |
These functions are connected, but replacing one does not automatically replace the others. NIST recognises that network-protocol key establishment and authentication can transition at different times.
That separation matters when a supplier describes a product as “PQC-ready”. The claim may cover key establishment without covering certificates, certificate-chain validation or authentication signatures.
An effective cryptographic transformation programme needs to distinguish those functions before assigning migration milestones.
Why TLS 1.3 is not automatically quantum-resistant
TLS 1.3 can negotiate classical key establishment. A connection using X25519 alone remains dependent on quantum-vulnerable elliptic-curve cryptography.
TLS 1.3 can also negotiate a post-quantum/traditional hybrid mechanism such as X25519MLKEM768. This combines an ephemeral elliptic-curve exchange with ML-KEM, the post-quantum key-encapsulation mechanism standardised by NIST.
The protocol version is unchanged. The key-establishment mechanism is different.
RFC 10024 standardises three hybrid mechanisms for TLS 1.3:
X25519MLKEM768.
SecP256r1MLKEM768.
SecP384r1MLKEM1024.
This is why a protocol-version inventory is insufficient. It can establish where TLS 1.3 is available without establishing whether connections actually use post-quantum key establishment.
Cipher-suite names do not answer the whole question
TLS 1.3 separates cipher-suite selection from key-establishment and signature-algorithm choices.
A cipher suite such as TLS_AES_128_GCM_SHA256 identifies the symmetric encryption and hash functions. It does not identify whether the connection negotiated X25519 or X25519MLKEM768.
The NCSC’s TLS guidance illustrates this directly: its classical and post-quantum profiles can use the same symmetric cipher suite while specifying different key-establishment mechanisms.
An assurance report that records only the TLS version and cipher suite can therefore miss the information needed to assess quantum exposure.
This is one reason cryptographic discovery should precede migration planning. The inventory must describe the cryptographic dependency, not merely the product name.
What if the organisation still uses TLS 1.2?
TLS 1.2 should not be described as automatically insecure against conventional attacks. Correctly configured TLS 1.2 can still provide strong classical protection.
However, the NCSC states that TLS 1.2 will not receive new features apart from critical security updates. Organisations using it should plan a transition to TLS 1.3 as part of their PQC migration.
This creates two related tasks:
Move remaining TLS 1.2 dependencies onto a supported TLS 1.3 implementation.
Enable, prefer and verify suitable post-quantum key-establishment mechanisms.
Where implementations and compatibility permit, these activities can be combined. Where they cannot, the dependencies and interim exposure need documenting.
A website supporting TLS 1.3 does not establish that internal APIs, database clients, integration platforms or older appliances have made the same transition.
Why key establishment is an early priority
The confidentiality risk is not limited to an attacker breaking a connection while it is live.
Under the harvest-now, decrypt-later threat model, an adversary records encrypted communications and associated handshake information, then attempts decryption when a sufficiently capable quantum computer becomes available.
NIST identifies this exposure as a reason to prioritise migration, particularly where information must remain confidential for years.
That changes the prioritisation question. A short-lived session can carry information with a long confidentiality lifetime.
The connection may close in seconds. The exposure may persist for decades.
Classical forward secrecy does not settle the quantum question
Ephemeral key establishment provides forward secrecy: later compromise of a long-term authentication key does not, by itself, reveal previous session secrets.
That is valuable protection. It does not make a quantum-vulnerable ephemeral exchange post-quantum.
NIST separates these considerations. Its network-protocol discussion recognises forward secrecy while still requiring harvest-now, decrypt-later exposure to inform the migration timeline for key establishment.
The question is therefore not merely whether a session used ephemeral keys. It is whether the key-establishment mechanism remains secure against the threat being planned for.
Post-quantum key establishment is not post-quantum authentication
A TLS connection can combine ML-KEM-based key establishment with conventional RSA or ECDSA authentication.
That is a transitional configuration, not a contradiction.
The NCSC’s October 2026 guidance recommends post-quantum key-establishment profiles while retaining classical authentication. It also explains that post-quantum authentication standards and the wider Web PKI transition remain under development.
The distinction should appear in migration reporting:
Confidentiality migration concerns how session secrets are established.
Authentication migration concerns certificates, signatures, trust anchors and validation.
Overall assurance concerns whether both functions meet the requirements of the application.
Private PKI and public Web PKI have different dependencies
An organisation controlling a private public key infrastructure may have greater freedom to coordinate changes across certificate issuance, clients, servers and trust stores.
A public-facing service depends on a wider ecosystem, including certification authorities, browsers and other client implementations. Private PKIs may therefore be able to adopt post-quantum authentication sooner than services relying on the public Web PKI.
Certificate migration is not just a purchasing decision. Issuing a different certificate is insufficient if the systems receiving it cannot validate its algorithms and chain.
This is a dependency-management problem spanning software, devices, suppliers and trust relationships.
What are the NIST and federal TLS deadlines?
Several dates appear in the policy framework. They should not be collapsed into a single “TLS PQC deadline”.
Date | Meaning | Scope |
2 January 2030 | Support TLS 1.3 or a successor version | Federal agency requirement referenced in OMB M-26-15 |
31 December 2030 | Adopt PQC for key establishment on specified priority systems | High-value assets, high-impact systems and other specified sensitive federal systems |
31 December 2031 | Adopt PQC for digital signatures on those priority systems | Corresponding accelerated federal signature migration |
After 2030 | Deprecate quantum-vulnerable public-key cryptography | NIST standards and guidelines |
After 2035 | Disallow quantum-vulnerable public-key cryptography | NIST standards and guidelines |
The accelerated federal requirements and the broader NIST transition schedule serve different purposes. OMB M-26-15 does not apply to National Security Systems.
Deprecated does not mean immediately prohibited. It means use continues with recognised risk during the transition. Disallowed means no longer approved under the relevant NIST framework.
Our draft-to-final analysis of NIST IR 8547 examines the transition language and the distinction between the broader schedule and accelerated federal requirements.
Does this apply to private organisations outside the United States?
NIST IR 8547 is not a universal legal mandate.
An organisation must establish which obligations reach it through regulation, contracts, procurement requirements, internal policy or commitments to use NIST-approved cryptography.
My assessment is that the wider commercial effect will run through those dependencies. Suppliers should establish their exposure rather than assume that being outside the US federal government makes the timetable irrelevant.
The useful question is not “Does NIST regulate us directly?”
It is “Which customers, contracts, policies and assurance requirements make this transition relevant to us?”
A quantum-resistant edge does not prove a quantum-resistant application
Consider an illustrative service path:
Browser → CDN → load balancer → application → database
These are not necessarily one continuous TLS connection.
A CDN can terminate the browser’s connection and establish a separate connection to the origin. A load balancer may terminate another connection. Application and database traffic may use different implementations and policies.
Third-party infrastructure can also place TLS configuration outside the data owner’s direct control.
The governance consequence is to assess connection segments, not just the public hostname.
For each relevant segment, establish:
Where encryption begins and ends.
Which party controls the TLS configuration.
Which protocol and key-establishment mechanism are negotiated.
Which identity and certificate chain are validated.
Which data crosses that segment.
What happens when the preferred mechanism is unavailable.
This does not mean all segments carry identical risk. It means the risk assessment needs the boundaries before it can justify different treatment.
A PQC Discovery Sprint provides a structured starting point for identifying cryptographic exposure and the dependencies that control migration.
Hybrid TLS needs an operating policy
NIST accommodates hybrid techniques, but does not prescribe them as a universal answer. Its report identifies implementation cost, performance, complexity and independent security review as application-specific considerations.
The NCSC recommends hybrid schemes as an interim measure for TLS migration.
These are compatible positions. One describes broader standards accommodation; the other provides a deployment recommendation for its stated context.
Capability, preference and enforcement are different states
A product can support a PQC mechanism without selecting it for a given connection.
A deployment can prefer PQC while retaining classical options for compatibility.
A tightly controlled service can require an approved mechanism and reject connections that cannot negotiate it.
Those states should not be reported as equivalent.
A connection negotiating classical cryptography during a transition is not automatically evidence of an attack. It may reflect a legitimate compatibility decision.
However, the decision should have an owner, defined scope, monitoring and an exit condition. Otherwise, a transitional exception can become an undocumented permanent dependency.
What evidence should a TLS migration programme collect?
The following is a proposed assurance baseline, not a checklist quoted from NIST.
Evidence category | What to record |
Service ownership | Application, business owner, technical owner and supplier |
Connection boundary | Client, server, termination point and onward connection |
Implementation | Product, library, version, platform and relevant module |
Protocol policy | Permitted TLS versions and configuration |
Key establishment | Supported, preferred and observed negotiated mechanisms |
Authentication | Certificate keys, handshake signatures, chain and trust dependencies |
Data exposure | Sensitivity and required confidentiality lifetime |
Exceptions | Classical compatibility, justification, owner and review date |
Testing | Interoperability, performance, failure handling and rollback results |
Applicable assurance | Required validation, evaluated configuration and supporting evidence |
The distinction between advertised capability and observed operation is central.
A supplier roadmap is planning evidence. A configuration export is deployment evidence. A representative handshake observation is operational evidence.
None replaces the others.
Where a cryptographic module must meet FIPS 140-3 requirements, that becomes a separate assurance workstream. A product supporting a NIST-standardised algorithm does not, by itself, establish module validation. Our FIPS 140-3 Gap Analysis addresses the design and documentation considerations associated with that route.
A practical TLS and PQC migration sequence
1. Discover the connection estate
Identify public-facing and internal TLS dependencies, including managed infrastructure and software libraries.
Record where inspection cannot establish the configuration and obtain evidence from the responsible supplier. Do not fill gaps with assumptions based on a product brochure.
Our article on the first defensible step in PQC migration explains why discovery must establish a usable evidence base.
2. Prioritise by exposure and migration difficulty
Start with long-lived confidential information, critical services and dependencies with lengthy replacement or approval cycles.
NIST’s framework links prioritisation to data sensitivity, system impact and transition lead time.
A difficult migration should not be left until last merely because a simpler deployment produces a faster progress metric.
3. Separate protocol, key-establishment and authentication work
Give each workstream defined acceptance criteria.
Avoid closing a PQC task because TLS 1.3 became available, or closing authentication migration because hybrid key establishment was enabled.
Progress reporting should show which function has changed and which exposure remains.
4. Test the actual implementation
Assess representative clients, intermediaries and server configurations.
Include handshake success, latency, resource consumption, compatibility, observability and recovery.
Larger cryptographic messages and implementation changes make interoperability and performance testing part of migration, not an optional final check.
5. Move into continuous assurance
Monitor negotiated mechanisms, investigate unexpected classical connections and review exceptions.
Reassess after product updates, infrastructure changes or supplier configuration changes.
Our Cryptographic Transformation and Modernisation framework treats cryptographic change as a lifecycle programme, rather than a one-off algorithm replacement.
Frequently asked questions
Is TLS 1.3 quantum-resistant?
Not automatically. TLS 1.3 can use classical or post-quantum key-establishment mechanisms. Its version number alone does not establish quantum resistance.
Does ML-KEM encrypt application traffic?
ML-KEM establishes shared secret material. TLS derives keys from the handshake secrets and uses symmetric authenticated encryption to protect application traffic.
Must RSA certificates be replaced before hybrid TLS can be deployed?
Not necessarily. Hybrid post-quantum key establishment can operate alongside classical RSA or ECDSA authentication. Authentication migration remains a separate task.
Does NIST IR 8547 require all organisations to enable hybrid TLS?
No. NIST leaves hybrid decisions to the application, considering security, cost, performance and complexity. Applicable sector or government guidance may provide more specific requirements or recommendations.
Does enabling TLS 1.3 satisfy the federal PQC requirements?
No. The TLS 1.3 support requirement and the PQC migration requirements are separate. Enabling a protocol does not prove that an appropriate PQC mechanism is negotiated.
Where should an organisation start?
Establish its cryptographic estate, connection boundaries, data exposure and supplier dependencies. That evidence supports prioritisation, procurement decisions and migration acceptance criteria.
SITG-Consulting assessment
The consequence of NIST IR 8547 for TLS is not another version-number target.
It is a demand for a defensible account of the cryptography protecting communications, the dependencies controlling its replacement and the evidence supporting migration decisions.
“We support TLS 1.3” is a capability statement.
It is not proof that the right mechanism is negotiated, that the internal connection is covered or that authentication has migrated.
The board question is not whether a product has a PQC feature. It is which exposures remain, who owns them and whether the migration plan can be demonstrated.
Start with cryptographic discovery. Build the findings into a governed cryptographic transformation programme.
Source material
Technical and policy sources
NIST, Transition to Post-Quantum Cryptography Standards, NIST IR 8547 Final, October 2026. Basis for the transition schedule, algorithm migration, prioritisation and hybrid considerations.nvlpubs.nist
UK National Cyber Security Centre, Using Transport Layer Security to Protect Data, October 2026. Basis for the TLS profiles, TLS 1.2 transition discussion, distinction between key establishment and authentication, and certificate considerations. ncsc.gov.uk
IETF, RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3. Basis for the named ECDHE-ML-KEM hybrid mechanisms.datatracker.ietf
US Office of Management and Budget, Memorandum M-26-15, Execution of the Migration to Post-Quantum Cryptography, 24 June 2026. Basis for the federal requirements and their distinction from the wider NIST transition schedule.
Comments