For the past decade, the development of network cryptography has progressed in an evolutionary manner. We updated OpenSSL libraries, replaced SHA-1 with SHA-256, increased RSA key lengths, but all of this remained within a familiar security model. In 2025, for the first time in more than 20 years, we are facing a change that is not evolutionary. It is a reset of the TLS architecture.

The introduction of NIST post-quantum algorithms such as CRYSTALS-Kyber and Dilithium marks a shift at the foundational level. It is no longer about choosing a curve, key length or signature format. It is about the fact that the existing system of key exchange and digital signatures will no longer be sufficiently secure once quantum computers reach adequate computational scale. And much of the data intercepted today will remain relevant even a decade from now. This is why the security community is beginning to treat the “harvest now, decrypt later” model as a real threat rather than speculation.

Hybrid TLS: not an experiment, but a transitional standard.

The main challenge is that migration cannot happen “immediately”. Browsers, operating systems, IoT devices, embedded infrastructures and cryptographic libraries are not capable of adopting pure PQC in 2025. Therefore, a hybrid model has been introduced, in which the TLS handshake contains two parallel key exchange mechanisms: classical (ECDHE) and post-quantum (Kyber). The client and server negotiate both parameter sets and then combine them to form a session key that is resistant to both classical and quantum attacks.

This is the moment when many organizations discover that their network, although functioning without issues, is not ready to handle larger handshake records, new OIDs and dual key structures. In the hybrid model, packet sizes increase, CPU load profiles change, and some edge devices have difficulties parsing new TLS extensions. This requires testing, compatibility mapping and deliberate planning.

OpenSSL 3.x: a mandatory requirement, not a recommendation.

One of the most common mistakes in corporate infrastructures is assuming that updating OpenSSL is a matter of convenience rather than security. Meanwhile, OpenSSL 1.1.1, the de facto standard for years, is incompatible with new PQC mechanisms. It cannot handle cryptographic providers, lacks loadable module architecture and does not understand new key formats.

OpenSSL 3.x introduces the provider architecture, dynamic loading of algorithms, support for new signature types and the flexibility required for hybrid handshakes. For this reason, migration of cryptographic libraries is not a “future option”. It is a prerequisite for any PQC testing, even experimental.

Changes in X.509 certificate formats: a new chapter in PKI.

The certificate ecosystem is facing the largest redesign in two decades. In the post-quantum model, a single public key in a certificate is no longer sufficient. The X.509 certificate will need to store two sets of parameters: classical ECDSA and a post-quantum component.

This means rebuilding the entire toolchain: from CSR generators, through CAs, to browsers and CT logs. A CSR, instead of being a lightweight document with one key, will become a structure more similar to a container that holds multiple algorithms. Browsers must know how to interpret signatures, CAs must verify both sets, and CT monitoring systems must store certificates that are significantly larger than before.

Consequences for server infrastructure: what is really changing?

This is not a change “in the certificate layer”. This is a change that affects all infrastructure components:

• TLS servers and reverse proxies,
• WAF devices and load balancers,
• cryptographic libraries in application backends,
• mobile and desktop clients,
• IoT environments (MTU and handshake record size will be especially problematic),
• HSMs responsible for key generation and protection.

In many companies, the HSM will become the biggest limitation. A significant part of today’s hardware modules does not support Kyber or Dilithium, and upgrading them requires replacing the entire device rather than updating firmware. Future certificates will be larger, and their generation will be more computationally intensive. The certification process will also be longer because CAs must validate dual structures.

Migration model: how to practically transition to PQC-Ready TLS?

Transitioning to quantum-resistant TLS cannot be done “with one click”. In practice, it requires three parallel work streams:

1. Cryptography modernization (libraries, servers, HSM).

The organization must verify whether all components can load PQC providers and generate keys in new formats. This is the moment when seemingly minor issues begin to surface, such as a backend running on an old LibTLS version or an IoT server unable to accept a larger handshake frame.

2. Interoperability testing.

PQC requires testing not only with browsers, but also with proxies used by internal services. Hybrid handshake testing must be conducted for both public traffic and internal environments, including APIs, microservices and even database communication.

3. Preparing a new DevOps pipeline.

The pipeline must generate two keys, handle hybrid CSRs, send them to the CA and verify dual signatures. Many CI/CD tools are not ready for this. This is a step organizations often underestimate, and only during mass certificate renewals do they discover that the entire process breaks.

Why all this must be done now, not in 2027?

Because between 2026 and 2028 pressure will come from:

• browsers (the Chrome Root Program will prefer hybrid certificates),
• the CA or B Forum (dual algorithm requirements for OV and EV),
• industry regulators (especially financial and governmental sectors),
• business partners (PQC compatibility required in integration protocols).

Companies that are not prepared will find themselves in the same position as during the SHA-1 to SHA-256 transition, with incompatible infrastructure, hundreds of handshake errors and time pressure.

Summary: migration to PQC is a three-year project, not a weekend change.

Preparing infrastructure for PQC means:

• replacing cryptographic libraries,
• updating servers and reverse proxies,
• verifying hardware (especially HSMs),
• preparing pipelines to support dual keys,
• testing compatibility with browsers and devices,
• being ready for new X.509 certificate formats,
• controlling the impact on performance and handshake size.

This is a process that, if started now, can be carried out gradually and safely, avoiding costly mistakes. But if started too late, PQC will become an infrastructure problem rather than a cryptographic one.

Case studies: how real environments react to the first wave of PQC changes?

Although full post-quantum cryptography adoption is only beginning, in practice issues are already emerging due to attempts to deploy PQC or due to collisions between modern libraries and classical infrastructures. The following case studies come from audits and migration projects carried out in Europe and the USA between 2023 and 2025. All of them show one thing: PQC is not abstract, but a real factor influencing infrastructure today.

Case Study 1: A banking load balancer that “did not see” parts of TLS Hybrid packets.

A large bank introducing a test PQC deployment observed that some connections from the mobile application ended with a reset or handshake renegotiation. Initially, an application issue or certificate problem was suspected. Only deep PCAP analysis revealed that:

• the L4 or L7 appliance used as a load balancer had a hard limit on TLS record size,
• hybrid handshake records were approximately 35 to 45 percent larger,
• the device began treating some traffic as fragmented suspicious sessions and dropped packets.

The bank initially assumed that a firmware update would fix the problem. The vendor, however, informed them that PQC support would be available only in 2027.

Effect: the entire cluster had to be replaced, even though the devices were considered “new” two years earlier.

Case Study 2: A medical IoT ecosystem built on TLS 1.2 that could not handle Kyber key sizes.

A telemetry device manufacturer implemented TLS 1.2 with ECDHE or ECDSA, which met medical standards in 2021. Today, during PQC testing:

• 18 percent of embedded devices did not accept the hybrid ClientHello,
• some ESP32 plus microcontrollers had strict buffer limits,
• the TLS stack could not be extended without rewriting the firmware.

Preparing PQC-compatible firmware required:

• changing the TLS stack,
• replacing some communication modules,
• recertifying medical devices (a seven-figure cost).

This shows the greatest PQC risk for regulated industries: recertification time and cost.

Case Study 3: An enterprise CDN that solved the issue by enabling PQC only on next generation edge nodes.

A CDN operator serving several hundred large websites carried out PQC tests for HTTPS traffic. The findings were interesting:

• some older edge nodes could not run OpenSSL 3.2,
• newer regions worked without problems,
• the larger handshake caused occasional timeouts in regions with weaker connectivity.

The final solution was operationally hybrid: PQC was enabled only in selected regions where the infrastructure was ready. The remaining regions continued to use classical algorithms.

This is the first real example of a “PQC per region capability” strategy, which will become common in 2025 to 2030.

Case Study 4: An internal PKI in a technology company that discovered it could not generate a hybrid CSR.

A large software house operating its own SaaS platform maintained an internal CA based on old OpenSSL libraries. When attempting to generate the first CSR with a PQC component, it turned out that:

• their CA did not support PQC providers,
• certificate automation tools worked only with RSA or ECDSA,
• the CI or CD pipeline generated CSRs in a format from 2015.

To introduce PQC, they had to redesign:

• the entire issuing CA system,
• the certificate pipeline,
• CP or CPS policy rules,
• DevOps scripts,
• integration with certificate monitoring.

This case study shows the most important truth: PQC issues often emerge not in TLS, but in the internal CA or PKI organization.

The impact of PQC on ACME, certificate automation and DevOps pipelines.

In the pre-PQC world, certificate automation was relatively simple. ACME generated a single CSR, retrieved the certificate, handled renewals and DevOps only monitored the process. In the post-quantum model, ACME and the entire pipeline will need to support two parallel cryptographic structures, new OIDs, larger payloads and more complex validation procedures.

ACME in the world of hybrid certificates.

ACME was designed at a time when a certificate had one key and one signature structure. A hybrid PQC certificate means that the CSR will contain:

• a classical component (ECDSA),
• a PQC component (Kyber),
• additional X.509 extensions,
• larger SPKI fields and headers.

Modern ACME servers (for example Boulder from Let’s Encrypt) are not yet ready for full PQC support. Experimental models are being tested, but the migration of ACME to PQC means:

• generating two key pairs,
• combining them into a valid CSR,
• handling significantly larger payloads,
• modifying the CA side signature validation model.

This requires updates to ACME clients such as Certbot, acme.sh, Lego and Posh-ACME. All will need major modernization.

The impact of PQC on DevOps or CI or CD pipelines.

In practice, PQC will not affect the web server first. It will affect the DevOps pipeline.

The reason is simple. Until now, the pipeline generated one key and one CSR. In the PQC world, the pipeline will need to generate two key sets and handle their dependencies.

This means changes in:

• CSR generators (OpenSSL, step-ca, custom scripts),
• GitLab or GitHub Actions integration modules,
• containers used to build application images,
• policy enforcement layers,
• key rotation procedures.

Additionally, the pipeline will need to:

• validate the PQC part of the certificate,
• store two keys securely,
• handle larger artifacts,
• send hybrid CSRs to the CA.

This is a major challenge for companies that do not yet have an automated certificate lifecycle.

Automatic certificate renewals: the end of a simple process.

Automatic certificate rotation (for example every 60 or 90 days) has been trivial until now. In the PQC era, renewal means:

• regenerating both key pairs,
• recreating the hybrid CSR,
• performing an ACME flow compatible with PQC,
• verifying compatibility with clients.

During the first years of PQC, automation will be the biggest technical challenge, not the TLS handshake itself.