Post-Quantum Cryptography Setup: 12 Steps, 70 Min [2026] - tech-insider.org

Marcus Chen July 18, 2026 22 min read Every TLS handshake and every SSH login on the internet today relies on math that a large enough quantum computer could eventually break. That is not a hypothetical for security teams anymore. The National Institute of Standards and Technology finalized its first three post-quantum cryptography standards on August 13, 2024, and the tooling needed to actually deploy them, OpenSSL 3’s provider architecture, the Open Quantum Safe project’s liboqs library, and hybrid key exchange in OpenSSH, has matured enough for production use in 2026. This tutorial walks through a full PQC migration on a real Ubuntu 24.04 server: building the software, generating quantum-safe keys, standing up a hybrid TLS-terminating NGINX proxy, hardening OpenSSH, and verifying every handshake actually negotiates the new algorithms instead of quietly falling back to RSA. By the end you will have a working reverse-proxy stack that speaks both classical and post-quantum cryptography at once, plus the troubleshooting knowledge to fix the handshake failures and build errors that trip up almost everyone on their first attempt. Canadian IT teams have extra reason to move now: the Government of Canada introduced Level 1 of the Canadian Program for Cyber Security Certification in April 2026, and while it does not yet mandate post-quantum algorithms specifically, it signals the direction federal contractors are being pushed. Getting comfortable with PQC before it is contractually required beats scrambling after the fact. This is a hands-on companion to the broader cybersecurity coverage on this site. If you have already hardened your perimeter with an IDS, a SIEM, or a secrets manager, post-quantum cryptography is the next layer down the stack: it protects the actual key exchange and signatures underneath everything else you have built. · Google · Preferred Sources Don't miss new tech stories on Google Add Tech Insider once in the Google app and our stories appear in your news suggestions. Add Now Why Post-Quantum Cryptography Can’t Wait Until 2030 The threat driving this migration has a name: harvest now, decrypt later. An adversary with the patience and storage budget can record encrypted traffic today and simply wait for a cryptographically relevant quantum computer to decrypt it years down the road. That threat model matters most for data with a long confidentiality shelf life, things like health records, legal filings, trade secrets, and government communications. It does not matter how strong RSA-4096 feels today if the ciphertext gets unlocked in 2035. NIST answered that threat with three finalized standards on August 13, 2024: FIPS 203 (ML-KEM, a key encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, a digital signature scheme derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, a conservative hash-based signature scheme derived from SPHINCS+). These are not draft proposals anymore. They are approved federal standards that vendors, auditors, and eventually procurement officers will expect to see supported. The regulatory pressure is real and dated. The NSA’s CNSA 2.0 suite requires U.S. National Security Systems to support ML-KEM-1024 and ML-DSA-87, with RSA and ECC disallowed for new systems after 2030 and full retirement by 2033. Canada has not published an equivalent hard deadline as of this writing, but the Canadian Centre for Cyber Security has been urging organizations to inventory their cryptographic assets now rather than wait for a mandate to force the issue. That inventory step, quietly, is the same first move every migration guide recommends: know what uses RSA and ECC before you touch anything. Framework Requirement Key Date Notes NIST FIPS 203, 204, 205 finalized August 13, 2024 ML-KEM, ML-DSA, and SLH-DSA approved as U.S. federal standards NSA CNSA 2.0 ML-KEM-1024 and ML-DSA-87 required 2030 (new systems), 2033 (full transition) Applies to U.S. National Security Systems (RSA/ECC barred after 2035) Canadian Centre for Cyber Security Quantum-readiness guidance published Ongoing Recommends cryptographic asset inventory now, with no fixed enforcement date published yet Canadian Program for Cyber Security Certification Level 1 required for select defence contracts Summer 2026 Announced April 2026, does not yet mandate PQC specifically None of this means RSA and ECDSA stop working tomorrow. It means the migration window is now open, the tools are ready, and post-quantum cryptography has moved from research curiosity to something you can, and arguably should, deploy alongside your existing TLS and SSH infrastructure today, a shift the Cloud Security Alliance has called an important step toward a quantum-safe future. Prerequisites: Tools, Versions, and System Requirements This tutorial assumes a fresh or lightly used Ubuntu 24.04 LTS server with root or sudo access, at least 2GB of RAM, and outbound internet access to clone two git repositories. Everything here also works on Debian 12 with minor package-name adjustments. You do not need specialized hardware. Post-quantum algorithms run fine on commodity CPUs, though key and signature sizes are larger than what RSA and ECDSA produce, which matters more than raw CPU cycles in most deployments. Component Version Used Here Purpose Ubuntu Server 24.04 LTS Base operating system OpenSSL 3.0 or later (provider architecture required) TLS engine that loads the post-quantum provider liboqs latest main branch, Open Quantum Safe project Core implementations of ML-KEM, ML-DSA, and SLH-DSA oqs-provider latest release, Open Quantum Safe project Bridges liboqs into OpenSSL 3’s provider API CMake 3.5 or later Build system for liboqs and oqs-provider Ninja latest available in apt Fast build backend (optional, recommended) NGINX 1.25 or later, linked against the OQS-enabled OpenSSL TLS termination and reverse proxy OpenSSH recent 9.x release Remote administration with hybrid key exchange Do not assume your specific OpenSSH point release supports a given key exchange name. Algorithm naming in this space has shifted as NIST finalized its standards, so the safest first move on any box is checking what your installed version actually offers, which Step 8 covers in detail. Run openssl version and ssh -V now and write down what you get, since you will compare against it later. A disposable cloud VPS or local virtual machine works better than a production box for your first pass through this tutorial. You are compiling software from source into a custom prefix, editing a system-wide OpenSSL config, and restarting SSH, three things you want room to get wrong at least once. Snapshot the VM before you start if your provider supports it, so a broken openssl.cnf edit costs you a rollback instead of an afternoon of debugging on hardware other people depend on. Understanding ML-KEM, ML-DSA, and SLH-DSA Three new algorithm families are worth knowing before you type a single command. Confusing them is the single most common mistake in early PQC deployments, because a key exchange algorithm and a signature algorithm solve completely different problems and are not interchangeable. ML-KEM: The New Key Exchange Standard ML-KEM (FIPS 203) is a key encapsulation mechanism, the post-quantum replacement for the Diffie-Hellman and ECDH key exchanges that establish a shared secret at the start of a TLS or SSH session. It comes in three parameter sets, ML-KEM-512, ML-KEM-768, and ML-KEM-1024, offering increasing security margins at the cost of larger public keys. ML-KEM-768 is the practical default for most deployments and is the parameter set referenced throughout this tutorial. Public keys run a little over one kilobyte, noticeably larger than a 32-byte X25519 public key but small enough to fit comfortably in a single network packet. ML-DSA and SLH-DSA: The New Signature Standards ML-DSA (FIPS 204) is the primary post-quantum digital signature scheme, used for signing certificates and verifying identity, not for exchanging session keys. It has three parameter sets as well, ML-DSA-44, ML-DSA-65, and ML-DSA-87, with ML-DSA-65 offering a comparable security margin to ML-KEM-768. SLH-DSA (FIPS 205) is a deliberately conservative backup, built on hash functions rather than lattice math. Its public keys are tiny, often under 100 bytes, but its signatures run into the tens of kilobytes, which makes it a poor fit for high-volume TLS handshakes and a good fit for long-lived firmware or code-signing scenarios where signature size matters less than an extremely well-understood security foundation. FIPS Standard Algorithm Type Based On Typical Use FIPS 203 ML-KEM Key encapsulation mechanism CRYSTALS-Kyber TLS and SSH key exchange FIPS 204 ML-DSA Digital signature CRYSTALS-Dilithium Certificate and code signing FIPS 205 SLH-DSA Digital signature (hash-based) SPHINCS+ Long-lived firmware and archival signing Keep those two use cases separate as you work through the rest of this tutorial. You will use ML-KEM for the TLS and SSH key exchange steps, and ML-DSA for the certificate signing steps. Step 1-2: Install Build Dependencies and Compile liboqs Start with a clean dependency install. liboqs and oqs-provider are both C projects built with CMake, and Ubuntu 24.04 ships everything you need in its default repositories. sudo apt update sudo apt install -y build-essential cmake ninja-build git \ libssl-dev pkg-config python3-pip python3-pytest \ python3-yaml doxygen graphviz unzip With dependencies in place, clone the Open Quantum Safe project’s liboqs repository and build it as a shared library. Installing it under /opt/oqs instead of the system prefix keeps it cleanly separated from your distribution’s own OpenSSL packages, which matters later when you are troubleshooting which library actually loaded. git clone --depth 1 https://github.com/open-quantum-safe/liboqs.git cd liboqs mkdir build && cd build cmake -GNinja -DCMAKE_INSTALL_PREFIX=/opt/oqs \ -DBUILD_SHARED_LIBS=ON \ -DOQS_BUILD_ONLY_LIB=ON .. ninja sudo ninja install cd ../.. The build takes a few minutes on a modest VPS since liboqs compiles reference implementations for every NIST candidate algorithm it supports, not just the three finalized ones. That is expected. Once ninja install finishes, confirm the shared library landed where you expect. ls /opt/oqs/lib/liboqs.so* ls /opt/oqs/include/oqs If either command comes back empty, stop here and re-run the CMake step with -DCMAKE_VERBOSE_MAKEFILE=ON to see exactly which install target failed. Chasing a broken NGINX config later because liboqs silently failed to install wastes far more time than catching it now. Step 3-4: Build the OQS Provider and Verify It Loads in OpenSSL liboqs on its own does not talk to OpenSSL. That bridge is oqs-provider, a separate project that implements OpenSSL 3’s provider interface and exposes ML-KEM, ML-DSA, and hybrid combinations as ordinary OpenSSL algorithm names. Clone and build it against the liboqs install from the previous step. git clone --depth 1 https://github.com/open-quantum-safe/oqs-provider.git cd oqs-provider liboqs_DIR=/opt/oqs cmake -S . -B build \ -DOPENSSL_ROOT_DIR=/usr \ -DCMAKE_BUILD_TYPE=Release cmake --build build sudo cmake --install build cd .. The install step places oqsprovider.so into your OpenSSL modules directory. Find out exactly where that is, since it varies between distributions. openssl version -a | grep MODULESDIR find / -name "oqsprovider.so" 2>/dev/null Now tell OpenSSL to actually load the provider by editing /etc/ssl/openssl.cnf. Add the provider section near the top of the file, right after the existing [openssl_init] block, and make sure it points at that section. [openssl_init] providers = provider_sect [provider_sect] default = default_sect oqsprovider = oqsprovider_sect [default_sect] activate = 1 [oqsprovider_sect] activate = 1 Save the file and confirm OpenSSL sees the new provider alongside the default one. openssl list -providers openssl list -kem-algorithms -provider oqsprovider openssl list -signature-algorithms -provider oqsprovider A correctly loaded provider prints dozens of algorithm names, including mlkem768, mldsa65, and hybrid combinations like X25519MLKEM768. If the command returns nothing or errors with “unknown option -provider,” OpenSSL is not finding your openssl.cnf edits, usually because a second copy of the config file exists elsewhere on the system. Check with openssl version -d to see which directory OpenSSL is actually reading from. Step 5-6: Generate Post-Quantum Keys and a Hybrid Certificate Chain With the provider loaded, generating a post-quantum key pair looks almost identical to any other OpenSSL key generation command. Start with an ML-DSA signing key for a private root CA. This stays offline in a real deployment, but for this tutorial you will use it to sign your test server certificate. mkdir -p ~/pqc-lab && cd ~/pqc-lab openssl req -x509 -new \ -newkey mldsa65 \ -keyout pqc-ca.key \ -out pqc-ca.crt \ -nodes -days 365 \ -subj "/CN=Internal PQC Root CA/O=Example Corp" No public certificate authority issues publicly trusted ML-DSA certificates yet, so a private root CA is the only realistic way to test a fully post-quantum signature chain today. That is a genuine limitation of where the ecosystem stands in 2026, not a mistake in this tutorial. Now generate a server key and certificate signing request, and sign it with your new root. openssl req -new \ -newkey mldsa65 \ -keyout server.key \ -out server.csr \ -nodes \ -subj "/CN=pqc.example.com" openssl x509 -req \ -in server.csr \ -CA pqc-ca.crt -CAkey pqc-ca.key \ -CAcreateserial \ -out server.crt \ -days 365 Confirm the certificate actually carries a post-quantum signature algorithm before moving on. openssl x509 -in server.crt -noout -text | grep -A1 "Signature Algorithm" You should see mldsa65 listed as the signature algorithm rather than sha256WithRSAEncryption or ecdsa-with-SHA256. If OpenSSL instead throws an “unsupported” error at the -newkey mldsa65 step, the provider is not active in the current shell session, usually because you edited openssl.cnf after opening the terminal. Start a fresh shell and try again. Step 7: Configure NGINX for Hybrid Post-Quantum TLS The key exchange side of TLS is where most production deployments actually start, because unlike certificate signatures, hybrid key exchange groups combine a post-quantum algorithm with a classical one, so a client that does not yet understand ML-KEM falls back gracefully to X25519 instead of failing the connection outright. That backward compatibility is exactly why hybrid mode, not pure post-quantum mode, is the recommended default for internet-facing services in 2026. Your NGINX binary needs to be linked against the OpenSSL build that has the OQS provider active, which the system NGINX package usually is, since it dynamically links against libssl.so at runtime rather than embedding its own copy. Edit your server block’s TLS settings. server { listen 443 ssl; server_name pqc.example.com; ssl_certificate /etc/nginx/pqc/server.crt; ssl_certificate_key /etc/nginx/pqc/server.key; ssl_protocols TLSv1.3; ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1; location / { proxy_pass http://127.0.0.1:8080; } } The ssl_ecdh_curve directive is doing the real work here. Listing X25519MLKEM768 first tells NGINX to prefer the hybrid post-quantum group, while the fallback entries keep older clients working. Copy your certificate files into place, test the config, and reload. sudo mkdir -p /etc/nginx/pqc sudo cp ~/pqc-lab/server.crt ~/pqc-lab/server.key /etc/nginx/pqc/ sudo nginx -t sudo systemctl reload nginx If nginx -t fails with “invalid parameter” on the ssl_ecdh_curve line, your NGINX is linked against a system OpenSSL that never picked up the provider, which happens if the provider was installed after NGINX started and the running worker processes cached the old configuration. A full restart, not just a reload, usually fixes it: sudo systemctl restart nginx. Step 8: Enable Post-Quantum Key Exchange in OpenSSH OpenSSH’s recent 9.x releases add growing support for hybrid post-quantum key exchange, but exactly which algorithm names your installed build supports depends on the point release and how it was compiled. Do not assume. Ask your own binary. ssh -Q kex Look through the output for entries containing mlkem or sntrup761x25519. The sntrup761x25519-sha512@openssh.com hybrid construction has been available for longer and shows up in more deployed versions, while mlkem768x25519-sha256 follows the finalized FIPS 203 naming and appears in newer builds. Whichever your version supports, add it to the top of your KexAlgorithms preference list on both the client and server, keeping classical algorithms as fallback entries. # /etc/ssh/sshd_config on the server KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256 # ~/.ssh/config on the client Host pqc-server HostName pqc.example.com KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256 Restart the SSH daemon after editing the server side, and always keep an existing session open while you test. Locking yourself out of a remote box over a typo in KexAlgorithms is one of the oldest mistakes in server administration, and post-quantum key exchange does not make you immune to it. sudo sshd -t sudo systemctl restart ssh Step 9-10: Verify and Benchmark the Post-Quantum Handshake Configuring PQC and confirming it is actually being used are two different tasks, and skipping the second one is how “migrated” systems quietly keep negotiating classical algorithms indefinitely. Check the TLS side first with openssl s_client, forcing the hybrid group explicitly. openssl s_client -connect pqc.example.com:443 \ -groups X25519MLKEM768 -tls1_3 < /dev/null 2>&1 | grep -i "server temp key\|negotiated" The output should confirm the negotiated group is X25519MLKEM768. If OpenSSL falls back silently to X25519 alone, double-check the ssl_ecdh_curve line in your NGINX config and confirm you reloaded rather than assumed the reload worked. For SSH, connect with verbose logging and grep the negotiated key exchange algorithm out of the noise. ssh -vv pqc-server 2>&1 | grep -i "kex algorithm" You are looking for a line reporting mlkem768x25519-sha256 or sntrup761x25519-sha512@openssh.com as the agreed algorithm. Once both sides confirm post-quantum negotiation, benchmark the performance cost so you know what to expect at scale. OpenSSL’s built-in speed testing works against the new algorithms exactly like it does against RSA. openssl speed mlkem768 openssl speed mldsa65 Expect ML-KEM operations to run comparably fast to X25519, since lattice-based key encapsulation is computationally cheap. ML-DSA signing and verification carry a heavier cost than ECDSA, though rarely enough to matter outside of extremely high-throughput certificate issuance systems. The bigger practical cost is bandwidth, not CPU, since larger public keys and signatures mean bigger TLS handshake packets. Test against more than one client before declaring success. A recent build of curl compiled against your OQS-enabled OpenSSL will negotiate the hybrid group by default once the server offers it, but a system curl linked against the distribution’s stock OpenSSL will not see oqsprovider at all and will silently negotiate classical X25519 instead, which looks identical to success unless you specifically check the negotiated group on both ends. The same gap shows up between browsers: some recent Chromium-based builds negotiate hybrid post-quantum groups by default, while most other browsers still fall back to classical key exchange until their own rollout catches up. None of this is a bug in your server configuration. It is simply the current, uneven state of client support in 2026, and it is exactly why hybrid mode matters: every one of those fallback connections still works. Step 11-12: Automate Key Rotation and Monitor Adoption A one-off migration is only half the job. Post-quantum keys need the same rotation discipline as any other cryptographic material, and you want visibility into whether clients hitting your server are actually negotiating the new algorithms or falling back. Start with a simple rotation script that regenerates the server key and certificate, then reloads NGINX. #!/usr/bin/env bash set -euo pipefail CERT_DIR=/etc/nginx/pqc LAB_DIR=/root/pqc-lab openssl req -new -newkey mldsa65 \ -keyout "$LAB_DIR/server.key" \ -out "$LAB_DIR/server.csr" -nodes \ -subj "/CN=pqc.example.com" openssl x509 -req \ -in "$LAB_DIR/server.csr" \ -CA "$LAB_DIR/pqc-ca.crt" -CAkey "$LAB_DIR/pqc-ca.key" \ -CAcreateserial \ -out "$LAB_DIR/server.crt" -days 90 cp "$LAB_DIR/server.crt" "$LAB_DIR/server.key" "$CERT_DIR/" nginx -t && systemctl reload nginx echo "$(date -Iseconds) rotated PQC server certificate" >> /var/log/pqc-rotation.log Save that as /usr/local/bin/pqc-rotate.sh, make it executable, and schedule it with a systemd timer rather than cron, since a timer gives you structured logs through journalctl for free. # /etc/systemd/system/pqc-rotate.timer [Unit] Description=Rotate PQC server certificate every 90 days [Timer] OnCalendar=weekly Persistent=true [Install] WantedBy=timers.target For monitoring, a lightweight approach beats a heavyweight one here: add a log format to NGINX that records the negotiated cipher and curve, then grep it periodically to track what share of real traffic is actually landing on the hybrid post-quantum group versus falling back. log_format pqc '$remote_addr - $ssl_protocol/$ssl_cipher - $ssl_curve'; access_log /var/log/nginx/pqc-access.log pqc; Run grep -c MLKEM /var/log/nginx/pqc-access.log against your total request count on a schedule and you have a rough adoption metric without standing up a full observability stack for what is, at this stage, a single migrating service. Putting It All Together: A Complete Post-Quantum Reverse Proxy Project Every piece from the steps above fits into one coherent project directory. Here is the complete layout once you have followed this tutorial end to end, useful as a checklist to confirm nothing got skipped. /opt/oqs/ liboqs shared library and headers /root/pqc-lab/ pqc-ca.key ML-DSA root CA private key (keep offline in production) pqc-ca.crt ML-DSA root CA certificate server.key ML-DSA server private key server.crt ML-DSA server certificate, signed by pqc-ca /etc/nginx/pqc/ server.crt copy of the live server certificate server.key copy of the live server key /etc/ssl/openssl.cnf edited with the oqsprovider provider block /etc/ssh/sshd_config KexAlgorithms updated with hybrid PQC entries /usr/local/bin/pqc-rotate.sh automated key rotation script /etc/systemd/system/pqc-rotate.timer weekly rotation schedule /var/log/nginx/pqc-access.log custom log format tracking negotiated groups Run through this quick end-to-end check on a fresh terminal to confirm the whole stack agrees with itself: openssl list -providers shows oqsprovider active, openssl x509 -in /etc/nginx/pqc/server.crt -noout -text shows an ML-DSA signature, openssl s_client -groups X25519MLKEM768 against your domain reports the hybrid group negotiated, and ssh -vv against your hardened host reports a post-quantum key exchange algorithm. If all four check out, you have a genuinely working, verifiable post-quantum cryptography deployment, not just a pile of configuration you hope is correct. Common Pitfalls When Migrating to Post-Quantum Cryptography Most of the problems teams hit during a first post-quantum migration are not cryptography problems. They are configuration and assumption problems that happen to show up in cryptography code. Deploying pure post-quantum mode instead of hybrid mode. Turning off classical key exchange entirely locks out every client and library that has not yet added ML-KEM support, which in 2026 is still most of them. Hybrid groups like X25519MLKEM768 exist specifically so you never have to make that tradeoff. Confusing ML-KEM with ML-DSA. One exchanges keys, the other signs certificates. Trying to use a KEM parameter set where a signature algorithm belongs produces confusing OpenSSL errors that look unrelated to the actual mistake. Forgetting that larger keys break assumptions baked into old code. Anything that hardcoded a buffer size around a 256-byte RSA key or a 32-byte X25519 key can silently truncate an ML-KEM public key or an ML-DSA signature. This shows up most often in custom TLS session caching code and older load balancer appliances. Rotating post-quantum keys but never rotating the classical half of a hybrid pair. A hybrid deployment is only as strong as its weakest half. If you diligently rotate ML-KEM keys every 90 days but leave the same X25519 key in place for two years, you have not meaningfully reduced your exposure window for the classical algorithm. Assuming “post-quantum” means “done forever.” Cryptographic agility, the ability to swap algorithms again without a ground-up rebuild, matters more than picking the perfect algorithm today. NIST is still evaluating additional candidates, and the parameter sets you deploy in 2026 are not guaranteed to be the last word. Ignoring the performance profile on constrained devices. A cloud server barely notices the CPU cost of ML-DSA signing. An embedded IoT device with a low-power microcontroller might notice quite a bit, especially if it is doing frequent TLS handshakes rather than reusing sessions. Troubleshooting Post-Quantum Cryptography Deployments These are the specific errors and symptoms that come up repeatedly when standing up PQC for the first time, along with what actually fixes them. “Provider oqsprovider not found” when running any OpenSSL command. The provider’s shared library did not land in a directory OpenSSL searches. Run openssl version -a | grep MODULESDIR and confirm oqsprovider.so actually sits in that directory, copying it manually if the install step placed it elsewhere. “unsupported” error on -newkey mldsa65 or similar. The provider is installed but not activated for the current session. Confirm your openssl.cnf edits saved correctly and that you are not accidentally editing a copy of the file that OpenSSL does not read, then open a fresh shell. NGINX fails to start with “invalid parameter” on ssl_ecdh_curve. The running NGINX binary is linked against a different OpenSSL than the one with the provider active. A full systemctl restart nginx, not a reload, is usually required after installing the provider. TLS handshake succeeds but negotiates plain X25519 instead of the hybrid group. Check that X25519MLKEM768 is listed first, not last, in your ssl_ecdh_curve directive, and confirm the client actually supports it. Older curl and browser builds silently fall back without any error. SSH connection refused after editing KexAlgorithms. A typo in the algorithm name string is the most common cause. Run sudo sshd -t before restarting the service, and always keep a second terminal session open while testing so a bad config does not lock you out entirely. liboqs build fails with missing CMake version errors. Ubuntu 24.04 ships a recent enough CMake by default, but older LTS releases might not. Check cmake --version against the 3.5 minimum before troubleshooting anything else. Certificate chain validation fails with “unable to get local issuer certificate.” Since no public CA issues ML-DSA certificates yet, any client validating against the public trust store will reject your private root by design. Import pqc-ca.crt into the client’s trust store explicitly for internal testing. Let’s Encrypt or another ACME client refuses to issue a certificate using an ML-DSA key. Public certificate authorities do not support post-quantum signature algorithms yet as of mid-2026. Use ML-DSA for internal, privately-trusted certificates and keep a classical ECDSA or RSA certificate from your public CA for anything that needs public trust, terminating the hybrid ML-KEM key exchange in front of both. Handshake latency increases noticeably under high concurrent load. This usually points to ML-DSA signature verification cost on the server rather than the key exchange itself. Enabling TLS session resumption reduces how often the server needs to perform a full signature verification per client. Advanced Tips for Production-Grade PQC Deployments Once the lab setup above is working, a handful of decisions separate a proof of concept from something you would actually trust in production. Treat hybrid mode as the long-term default, not a temporary stepping stone. Even after post-quantum algorithms see wide client support, keeping a classical algorithm in the mix costs almost nothing and protects against the unlikely but non-zero chance that a flaw surfaces in a lattice-based scheme before it has had RSA’s multi-decade review. Cryptographers generally treat hybrid constructions as strictly safer than either component alone, not as a compromise. Build crypto-agility into your architecture rather than your habits. Store algorithm choices in configuration, not hardcoded into deployment scripts, so that when NIST finalizes additional parameter sets or a future standard supersedes ML-KEM-768, you are editing a config value instead of re-architecting a service. This matters more for post-quantum cryptography than it did for the RSA-to-ECDSA transition, since the field is younger and more likely to see meaningful updates over the next five to ten years. Keep root CA keys, whether classical or post-quantum, on hardware or in an offline environment separate from the servers issuing day-to-day certificates. An ML-DSA private key sitting unencrypted next to your NGINX config defeats the entire point of building a stronger signature scheme. If your organization already uses an HSM or a secrets manager like HashiCorp Vault for classical key material, extend that same practice to post-quantum keys rather than treating them as a special case that lives outside your existing controls. Watch the public certificate authority ecosystem closely rather than assuming today’s limitations are permanent. Once a widely trusted CA begins issuing ML-DSA or hybrid certificates through the ACME protocol, the private-root-CA workaround in this tutorial becomes unnecessary for public-facing services. Until then, the realistic production pattern is a publicly trusted classical certificate handling identity, layered behind a hybrid ML-KEM key exchange handling confidentiality, which is exactly the split most large TLS terminators are quietly running today. Finally, budget real time for the inventory step before you touch a single production system. Every migration guide, including this one, describes how to convert one server. The actual hard part of an organizational post-quantum migration is finding every place RSA and ECDSA are quietly in use, from internal APIs to old firmware to third-party vendor integrations you do not control. Start that inventory now, even if you do not touch a single line of configuration for another year. Frequently Asked Questions What is post-quantum cryptography and why does it matter now? Post-quantum cryptography refers to algorithms designed to resist attacks from both classical and quantum computers, unlike RSA and elliptic-curve cryptography, which a sufficiently powerful quantum computer could eventually break. It matters now because of harvest-now-decrypt-later attacks: encrypted data captured today can be stored and decrypted later once quantum computing catches up, which makes long-lived sensitive data a priority for migration well before any quantum computer is actually capable of the attack. Do I need to migrate to post-quantum cryptography today? For most organizations, the honest answer is that you need to start planning today without necessarily flipping every production system today. Begin with the cryptographic asset inventory, pilot hybrid TLS on a low-risk internal service using the steps in this tutorial, and prioritize any system handling data that needs to stay confidential for a decade or more. What’s the difference between ML-KEM and ML-DSA? ML-KEM (FIPS 203) establishes a shared secret between two parties, the post-quantum equivalent of a Diffie-Hellman key exchange. ML-DSA (FIPS 204) signs data to prove authenticity and integrity, the post-quantum equivalent of ECDSA or RSA signatures. A TLS handshake typically uses both: ML-KEM for the key exchange and either ML-DSA or a classical algorithm to sign the certificate. Will post-quantum cryptography slow down my servers? ML-KEM operations run at roughly comparable speed to X25519 in most benchmarks, so key exchange overhead is minor. ML-DSA signing and verification cost more than ECDSA, though the difference matters mainly at very high transaction volumes. The bigger practical impact is larger handshake payloads, a few kilobytes instead of a few hundred bytes, which affects bandwidth and can matter on constrained or high-latency networks more than it affects CPU usage. Can I get a publicly trusted, CA-signed post-quantum certificate today? Not yet, as of mid-2026. Public certificate authorities issue certificates using classical algorithms only. The practical workaround this tutorial demonstrates is running a private root CA for internal ML-DSA certificates while relying on hybrid ML-KEM key exchange, which several public CAs and CDNs already support, in front of a conventionally-signed public certificate. Is hybrid key exchange less secure than pure post-quantum key exchange? No. A hybrid construction combining ML-KEM and X25519 is generally considered at least as secure as either algorithm alone, since an attacker needs to break both components to compromise the session. That is precisely why hybrid mode, not pure post-quantum mode, is the recommended approach for production deployments in 2026. What happens to RSA and ECDSA? Are they broken now? RSA and ECDSA remain secure against any classical computer available today and are not broken. The concern is forward-looking: a future quantum computer large enough to run Shor’s algorithm at scale could break both, which is why standards bodies and agencies like the NSA are setting migration deadlines years in advance rather than waiting for that capability to exist. How do I know if my browser or client already supports post-quantum TLS? Connect to a test server configured as shown in this tutorial and inspect the negotiated group. On the command line, openssl s_client -connect host:443 -groups X25519MLKEM768 reports whether the hybrid group was actually used. Several major browsers have added support for hybrid post-quantum key exchange in recent releases, but the safest way to confirm is testing the specific client and version you care about rather than assuming based on vendor announcements. Related Coverage DMARC, SPF & DKIM Setup: Stop Spoofing in 12 Steps [2026] Suricata IDS/IPS Setup in 12 Steps, 40 Min [2026] Wazuh SIEM Setup: Free SOC in 12 Steps, 45 Min [2026] HashiCorp Vault Setup: Secrets in 14 Steps, 45 Min [2026] pfSense Firewall Setup: 13 Steps, 60 Min [2026] Marcus Chen GAMING & CONSUMER TECH EDITOR Marcus Chen is a senior editor at Tech Insider, where he leads coverage of the US online gaming market, including sweepstakes and social casinos, alongside consumer technology. He evaluates operators on their published terms, licensing and RNG certifications, stated redemption policies, and corroborating independent reporting, and writes plainly about what the evidence supports. Tech Insider does not run first-party money tests and does not gamble with reader funds. Marcus has reported on the technology and online-gaming industries for more than a decade. View all articles