Preparing for the Post-Quantum Era: Nexusguard’s Approach to PQC Readiness

The security of an encrypted connection depends on more than the strength of its encryption algorithm. It also depends on how communicating parties establish the keys that protect their exchange. As quantum computing advances, this distinction is moving from specialist cryptography discussions into mainstream cybersecurity planning. Organizations responsible for sensitive information, critical services and long-lived infrastructure increasingly need to understand which parts of their cryptographic environment may require modernization—and how to make that transition without disrupting operations.

‍

At Nexusguard, preparing for the post-quantum era is part of our ongoing infrastructure modernization strategy. We have introduced support for hybrid post-quantum key exchange under TLS 1.3, including X25519MLKEM768, which combines classical X25519 with NIST-standardized ML-KEM-768. Our engineering team has successfully validated this capability in a production environment, marking a practical step toward greater cryptographic agility. 

‍

Why post-quantum cryptography matters now

Much of today’s secure internet relies on public-key algorithms such as RSA and elliptic-curve cryptography to authenticate systems and establish shared secrets. These mechanisms remain widely used, but a sufficiently capable cryptographically relevant quantum computer could undermine the mathematical problems on which they depend. Nobody can reliably assign a date to that threat becoming practical. For information that must remain confidential for many years, however, waiting until such a computer exists may be too late.

‍

The concern is often described as “harvest now, decrypt later”: an adversary records encrypted traffic today in the hope of decrypting it in the future. The risk is not uniform. Its significance depends on the sensitivity and useful lifetime of the data, the protocol used, and whether the relevant key establishment could eventually be broken. Government agencies, financial institutions and critical infrastructure operators therefore have good reasons to inventory their cryptographic dependencies and prioritize systems whose security requirements extend well into the future.

‍

The US National Institute of Standards and Technology (NIST) published FIPS 203 in 2024, standardizing the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). ML-KEM gives implementers a standardized post-quantum building block for establishing shared secrets. Standards are a starting point, though: operational readiness also requires interoperable implementations, sound configuration, lifecycle management and evidence from real connections.

‍

What hybrid post-quantum TLS actually changes

Hybrid post-quantum key exchange combines a conventional key-establishment mechanism with a post-quantum mechanism in a single negotiated exchange. One example is X25519MLKEM768, which combines the widely deployed classical X25519 mechanism with ML-KEM-768. The resulting shared secret draws on both components, providing a transition path designed to retain security if at least one component remains secure under the assumptions of the construction. Hybrid deployment also allows organizations to gain practical experience with post-quantum cryptography before moving to more extensive cryptographic changes.

‍

Crucially, X25519MLKEM768 is a TLS named key exchange group, not a cipher suite. In TLS 1.3, the key exchange group establishes key material while a cipher suite such as TLS_AES_256_GCM_SHA384 specifies symmetric encryption and associated cryptographic functions. This distinction matters when assessing vendor claims: supporting TLS 1.3, or merely offering a strong AES cipher suite, does not by itself prove that a service negotiates hybrid post-quantum key exchange.

‍

Nor does hybrid key exchange make the entire TLS connection post-quantum secure. Server certificates and digital signatures may still rely on classical algorithms. The precise claim is narrower but important: a compatible client and server can use hybrid post-quantum key establishment for a particular TLS connection. That capability should be verified at the actual TLS termination point rather than inferred from the presence of a cryptographic library.

‍

Why deployment readiness is more than a software checkbox

A production security platform may contain multiple TLS termination points, management interfaces, APIs, proxies and internal connections. Enabling a hybrid group at one listener does not automatically extend that protection to every adjacent connection. Equally, a successful laboratory test is not proof of a production deployment. Sound validation establishes which hostname or endpoint was tested, which TLS version was negotiated, which key exchange group was selected, and whether certificate validation succeeded.

‍

Compatibility is another operational consideration. Not every client supports hybrid key exchange today, so a phased transition can permit compatible clients to negotiate X25519MLKEM768 while retaining approved classical groups for clients that have not yet upgraded. This is a practical interoperability policy, not a statement that every connection automatically uses PQC. Security teams should distinguish among an endpoint being capable of hybrid negotiation, a capable client selecting it by default, and a policy requiring it for every connection.

‍

Nexusguard’s approach: validate, deploy, verify

Nexusguard is introducing hybrid post-quantum key exchange as part of an ongoing modernization of its security infrastructure. Our engineering team has already validated a successful TLS 1.3 handshake negotiating X25519MLKEM768 in an upgraded production environment. That evidence is more meaningful than a feature listing: it demonstrates that a real deployed endpoint can complete the requested hybrid exchange with a compatible client.

Deployment Status

Nexusguard is progressively deploying hybrid post-quantum key exchange capabilities across applicable parts of its global infrastructure. The rollout is being implemented in phases to support operational stability, service continuity and compatibility with existing client environments. Completion is currently targeted over the next few weeks. Once an applicable endpoint is upgraded and configured, compatible TLS 1.3 clients can negotiate hybrid PQC without customers having to select a cryptographic policy in the Admin Portal. Availability and negotiated behavior should be verified at the specific endpoint.

‍

We are deliberately specific about what this milestone means. It concerns hybrid key exchange for supported TLS connections; it does not imply that all traffic paths, internal management links, digital signatures or DDoS mitigation functions have become post-quantum secure. That distinction helps customers make informed security assessments and gives our engineering teams a measurable basis for expanding coverage.

‍

Where PQC fits in a broader resilience strategy

DDoS protection and post-quantum cryptography address different risks. DDoS mitigation is designed to preserve service availability under malicious traffic, whereas hybrid post-quantum key exchange strengthens the establishment of secrets for certain encrypted connections. A DDoS protection service can be effective at mitigating attacks while its administrative interfaces still require cryptographic modernization. Conversely, a post-quantum-capable TLS endpoint does not become resistant to volumetric attacks simply because its handshake has changed.

These capabilities nevertheless belong in the same operational conversation because security infrastructure sits on critical communication paths and must remain both accessible and trustworthy. Organizations reviewing their architecture should examine the resilience of their management plane alongside network and application-layer defenses. For additional context, see Nexusguard’s articles “DDoS Protection for SASE / Zero-Trust Resilience” and “Integrating WAF and DDoS Mitigation: A Powerful Alliance Against Cyber Threats.”

‍

A practical PQC readiness checklist for security teams

Start with a cryptographic inventory: identify the services, applications, APIs, management interfaces and third-party dependencies that rely on public-key cryptography. Classify them by exposure, data sensitivity and confidentiality lifetime. Then examine where TLS terminates and whether the effective software build and policy can negotiate approved hybrid groups. A version number alone is not a substitute for a successful handshake test.

‍

Next, validate the experience of real clients, including browsers, API integrations and automated agents. Record the negotiated TLS version and key exchange group, verify certificate trust, and test fallback behavior where classical compatibility remains necessary. Finally, treat rollout as an operational change: establish deployment sequencing, monitoring, rollback procedures and a process for rechecking endpoints after upgrades. These measures turn a standards discussion into a manageable security program.

‍

The longer view: cryptographic agility

The post-quantum transition will not end with a single TLS upgrade. Cryptographic algorithms, implementation guidance, client support and certificate ecosystems will continue to evolve. 

‍

Organizations therefore need cryptographic agility: the ability to discover where cryptography is used, update policies and components, and verify outcomes without redesigning entire services. Hybrid key exchange is one useful milestone on that path, particularly when accompanied by disciplined testing and honest disclosure of its scope.

‍

Nexusguard’s work reflects that approach. By introducing and validating hybrid post-quantum key establishment in supported production environments, we are laying a practical foundation for future cryptographic modernization while continuing to prioritize the availability and stability of the services customers rely on today.

‍

Frequently asked questions

What is post-quantum cryptography (PQC)?

PQC refers to cryptographic algorithms designed to resist attacks using both conventional and quantum computers. It is especially relevant to public-key cryptography, where future quantum capabilities could threaten widely used key establishment and signature mechanisms. NIST’s ML-KEM standard is one building block for post-quantum key establishment.

‍

What is hybrid post-quantum key exchange?

Hybrid key exchange combines a classical mechanism and a post-quantum mechanism to establish a shared secret. It provides a practical migration route because compatible systems can introduce a post-quantum component while retaining a well-understood classical one. Its protection is limited to the exchange and construction being used, not every security function of the service.

‍

What is X25519MLKEM768?

X25519MLKEM768 is a hybrid TLS key exchange group combining classical X25519 with ML-KEM-768, an algorithm standardized in NIST FIPS 203. When a TLS 1.3 connection negotiates this group, it uses both mechanisms in key establishment. It is not itself a TLS cipher suite or a post-quantum certificate signature.

‍

Does TLS 1.3 automatically mean a website uses PQC?

No. TLS 1.3 can be deployed using classical key exchange alone. To verify hybrid PQC on a specific connection, inspect the negotiated key exchange group—for example, X25519MLKEM768—using a compatible browser or TLS diagnostic client. The server’s software capabilities and the actual negotiated handshake are distinct facts.

‍

Does Nexusguard support hybrid PQC?

Yes. Nexusguard supports hybrid post-quantum key exchange under TLS 1.3, including X25519MLKEM768. The capability has been successfully validated in a production environment and forms part of our ongoing commitment to cryptographic modernization. Actual negotiation depends on the capabilities and configurations of the connecting client and the applicable service endpoint.

‍

Will customers need to change their settings?

For applicable Nexusguard endpoints covered by the upgrade, hybrid key exchange is managed at the platform level. Customers do not need to select a new cryptographic policy in the Admin Portal, but their client must support the relevant hybrid group for it to be negotiated. Classical key exchange remains available for compatibility where permitted by platform policy.

‍

Does PQC make DDoS mitigation stronger?

Not directly. PQC protects aspects of cryptographic key establishment; DDoS mitigation protects service availability against attack traffic. Both matter to infrastructure resilience, but they solve different problems and should not be presented as interchangeable protections.