Post-quantum readiness can be blocked before an organization chooses an algorithm. RFC 9852, New Protocols Using TLS Must Require TLS 1.3, establishes an IETF Best Current Practice: new protocols using TLS must default to TLS 1.3. The RFC also makes the PQC connection explicit—current TLS working-group standardization is focused on TLS 1.3 or later, not TLS 1.2.
Published in July 2026, the RFC is older than this week’s news, but it remains operationally timely as organizations translate PQC goals into architecture requirements. It does not require every existing TLS 1.2 deployment to disappear immediately, and it does not apply the same prescription to DTLS. It does show that protocol modernization is part of the migration path.
Algorithm support sits inside a protocol version
A library may implement ML-KEM while an application is pinned to a protocol path that cannot use the emerging TLS mechanisms. A product may advertise PQC capability while an intermediary, client, origin, or policy restricts negotiation to TLS 1.2. Inventory records that contain only library versions or supported algorithms miss this dependency.
For each TLS relationship, teams should capture:
- client, server, intermediary, termination point, and owner;
- minimum, maximum, default, and actually negotiated TLS versions;
- library and application versions plus configuration source;
- key-exchange groups, authentication algorithms, and certificate chain;
- fallback and downgrade behavior;
- client or partner populations that require older versions; and
- evidence source, observation window, coverage, and exception date.
This relationship model distinguishes what the implementation supports from what the application permits and real connections select.
A secure TLS 1.2 configuration is not the same as an agile baseline
RFC 9852 acknowledges that TLS 1.2 can be configured securely, while explaining that doing so is more difficult and requires disabling or mitigating older choices. The migration issue is broader than current security. New protocol work and PQC mechanisms are moving on the TLS 1.3 track.
An organization may therefore have a TLS 1.2 service that meets today’s policy but carries future migration cost. That cost belongs in architecture and lifecycle decisions. Teams should identify whether the blocker is an application framework, embedded client, inspection device, partner integration, certificate workflow, or unsupported appliance.
“Compliant today” and “capable of the target state” are separate evaluations. Keeping them separate avoids overstating risk while making technical debt visible.
Default, allowed, and negotiated are three different facts
The RFC requires TLS 1.3 as the default for new protocols, while permitting TLS 1.2 as an additional non-default option when deployment needs justify it. That distinction illustrates why configuration evidence needs precision.
A service can allow TLS 1.3 but default clients to an older version. A client can advertise TLS 1.3 while a proxy terminates and re-establishes TLS 1.2 to the origin. A policy can require TLS 1.3 while an unobserved partner path still negotiates otherwise.
Teams should measure every segment and population. Completion criteria might require a sustained percentage of TLS 1.3 negotiation, no high-priority TLS 1.2 paths without owned exceptions, and verified origin-side coverage—not merely an enabled setting.
Key establishment and authentication remain separate
TLS 1.3 is an enabling baseline, not proof of full post-quantum protection. Hybrid post-quantum key establishment can address long-term confidentiality while server and client authentication still use RSA or elliptic-curve signatures. Certificate issuance, validation, revocation, roots of trust, and relying-party compatibility form another workstream.
Inventory and reporting should identify both properties. A single “PQC enabled” field can hide classical authentication or partial traffic coverage.
What organizations should do next
First, find TLS 1.2 dependencies by application and connection segment, not only by external endpoint. Include service-to-service, management, partner, and origin paths.
Second, classify each dependency: secure current exception, upgrade planned, vendor-blocked, replacement required, or unknown. Assign an owner and review date.
Third, make TLS 1.3 the baseline for new protocol and product requirements. Require suppliers to describe supported versions, PQC roadmap maturity, interoperability, and telemetry.
Fourth, observe negotiation after changes. Configuration review cannot prove what distributed clients and intermediaries actually use.
Finally, keep the authentication migration visible alongside key establishment so that confidentiality progress is not mistaken for end-to-end quantum-safe identity.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps teams relate protocol versions, negotiated cryptography, software, endpoints, owners, exceptions, and remediation evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and incomplete observation is not proof of absence.
Learn more about Vista’s post-quantum migration approach.
Where uncertainty remains
RFC 9852 addresses new TLS-based protocols and explicitly excludes DTLS from its prescription. Existing application requirements, sector rules, and partner constraints vary. TLS 1.3 also does not by itself prove PQC use. The durable point is that protocol-version baselines determine which cryptographic transitions remain technically available.
Source
- RFC 9852: New Protocols Using TLS Must Require TLS 1.3, RFC Editor / IETF, July 2026.