An online guest article by Robert Frank (DigiCert)

From the article (access might require registering for a newsletter):
“A robust plan won’t revolutionize cryptography overnight. A configuration that allows only quantum-secure methods would break compatibility with the vast majority of existing connections. The transition is therefore taking place in stages, starting with confidentiality—that is, TLS and key exchange.

The first step is to upgrade all endpoints to TLS 1.3 with hybrid, quantum-secure key exchange. This requires a complete inventory of all internal and external TLS connections. This is precisely where it becomes clear just how much of the migration effort lies in the preparatory work before the actual cryptographic changes, because migration is only possible for what is known. This also includes coordination with service providers who establish TLS connections on behalf of the organization.

In the second phase, the actual connections are migrated. Current browsers and libraries already support hybrid key exchange, and many negotiate it automatically. The challenge arises with older enterprise software, proprietary software development kits (SDKs), embedded systems, and long-lived platforms that cannot be updated on a quarterly basis. This stage is the most operationally demanding and accounts for the bulk of the coordination effort.

Only in the third step—once no legacy systems rely on classical methods anymore—can the non-quantum-secure key exchange be disabled. Until then, a vulnerability remains because a fallback to classical methods is still possible. Only once the classical options are disabled is confidentiality against “harvest-now-decrypt-later” attacks truly protected. This point is often underestimated in migration plans because the first two stages appear to be a completion, even though the actual protection is only achieved at the very end. […]”