In the future, quantum computers are expected to break all the common forms of asymmetric cryptography used online today, like RSA and ECC. When this day will approach, commonly referred to as Q-Day, is subject to much debate. The good news is that symmetric encryption algorithms, such as AES, are thought to be secure against quantum computing threats.
While Q-Day may be many years off, the "Harvest Now, Decrypt Later" threat exists today. Bad actors collect encrypted data now. They plan to decrypt it later when they have a more powerful technology, like quantum computers.
This threat is worrying because even if data is encrypted now, it can still be valuable and sensitive later when decrypted. For instance, financial records, healthcare information, and personal data might be in danger. To protect against this, it is important to use strong, future-proof post-quantum cryptography (PQC). Interested to know more? see Post-Quantum Cryptography For Dummies
The industry is actively transitioning to post-quantum cryptography (PQC). This transition/change aims to guard against future threats from quantum computers. The National Institute of Standards and Technology (NIST) began replacing old asymmetric algorithms in 2017.
In 2024, new PQC standardsNIST announced the following new PQC standards:
FIPS-203 ML-KEM: Key encapsulation for secure communications.
FIPS-204 ML-DSA: Module-Lattice-based Digital Signature Algorithm.
FIPS-205 SLH-DSA: Stateless Hash-based Digital Signature Algorithm.
NIST set the deprecation dates for old asymmetric algorithms. This aims to push the industry to adopt the new PQC standards.
Digital signature algorithm family | Parameters | Transition |
---|---|---|
ECDSA [FIPS186] | 112 bits of security strength | Deprecated after 2030 Disallowed after 2035 |
≥ 128 bits of security strength | Disallowed after 2035 | |
EdDSA [FIPS186] | ≥ 128 bits of security strength | Disallowed after 2035 |
RSA [FIPS186] | 112 bits of security strength | Deprecated after 2030 Disallowed after 2035 |
≥ 128 bits of security strength | Disallowed after 2035 |
Following NIST’s example, the NSA updated its Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requirements for National Security Systems (NSS).
The NSA recommended guidance for:
Department of Defense (DoD)
Defense Industrial Base (DIB)
The update requires PQC algorithms. It will also phase out current crypto algorithms. By January 1, 2027, all new acquisitions for NSS will be required to be CNSA 2.0 compliant unless otherwise noted. By December 31, 2030, all equipment and services that cannot support CNSA 2.0 must be phased out.
The push for PQC adoption in the US was further bolstered by the Executive Order 14144, signed by President Joe Biden on January 16, 2025, mandating US government adopt PQC. It is worth noting that this Executive Order was not overturned by President Trump when he took office.
Standards bodies, such as the IETF and CA/B Forum, are now working on adding support for these new algorithms to TLS 1.3 and the public trust ecosystem (browsers, public CAs, etc.). If you do not control both ends of the TLS session, like the web browser and web server, you will need two certificates; one is a pure PQC certificate, such as ML-DSA, and the other is a traditional certificate, like RSA. Having two certificates on each client and server complicates matters. Hence, industry groups are exploring hybrid x.509 certificates. These certificates combine existing methods with PQC. For example, they may use MLDSA-44, RSA 2048, and SHA256 together.
While symmetric ciphers used in TLS are safe from quantum computing threats, TLS sessions also rely on key agreement methods to establish a shared key. Currently, most TLS traffic uses X25519 for secure key exchange, a Diffie–Hellman-style key agreement. However, Shor's algorithm on a quantum computer can fully break its security. Therefore, the priority is to upgrade key agreement mechanisms to ML-KEM.
Key agreement allows secure key exchange, but it does not verify the identity of the parties involved. An attacker can intercept messages without authentication. They can also create separate key agreements with the browser and server, then re-encrypt those messages. Authentication is achieved using signatures. A website like https://digicert.com shows a certificate from a certification authority (CA). This confirms that the public key is owned by DigiCert. The server then signs the handshake and shared key with its private key, ensuring the client has agreed with the correct server.
Traditional signature schemes such as RSA and ECDSA are vulnerable to quantum attacks using Shor's algorithm. This means attackers can forge signatures and can also carry out man-in-the-middle (MitM) attacks. Upgrading to post-quantum signatures is important, but it is not urgent as it only needs to happen before quantum computers pose a threat. However, migrating to post-quantum signatures is complex and time-consuming.
NIST’s assignment of FIPS status to the new PQC algorithms affects IoT devices and connected products in several ways including but not limited to:
PQC use becomes mandatory by all US federal agencies (civilian & military)
PQC becomes a de facto standard due to NIST's rigorous vetting
It drives international adoption and standards. Expect IoT security standards, such as EU Cyber Resilience Act, US Cyber Trust Mark, FDA pre-market guidance for medical devices, CSA Matter, and other standards to begin requiring PQC
Compliance impact:
Mandatory implementation for federal agencies and contractors
Updated certification programs. For example, FIPS 140-3
Regulations such as HIPAA, FISMA, that reference NIST standards will need to be revised
Compliance audits will check for PQC readiness
PQC-capable systems mandated in government procurement (RFP requirement)
Consequently, your connected product solution will be impacted, including your device hardware, device software, TLS libraries, backend services, cloud, and PKI infrastructure.
Broadly speaking, the impacts to your connected product can be categorized into:
Devices
Backend services
PKI
TLS

Use the following checklists to discover how the various components of your connected production solution are impacted:
- ×
Have your device SDKs been updated to meet advanced cryptographic standards?
Does your device crypto SDK support ML-DSA and ML-KEM?
Do you need FIPS 140-3 certified device crypto?
Does your device have a TLS 1.3 stack installed?
Have you included the above libraries in your device’s SBOM?
Do you have a reliable OTA update system to deploy SDK updates reliably across your fleet of devices?
- ×
Do your TPMs and secure elements support enhanced cryptographic functions and secure key storage?
Does your device have a TPM or secure element?
Does it support ML-DSA?
Nota
If using TPM 2, currently the TCG Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.83 – March 2024 has no support for ML-DSA.
Can your TPM or secure element firmware be updated to support ML-DSA?
Is your device using Physical Unclonable Function (PUF) technology to secure device private keys?
Can your PUF implementation be updated to support ML-DSA?
- ×
Are you running a current OpenSSL implementation optimized for PQC support?
Nota
You need to leverage OpenSSL providers such as OQS to add PQC support.
Are you running a current version of OpenSSL on your device?
Is OQS installed on your devices?
Have you included OQS in your device’s SBOM?
- ×
Is your device ready to generate new ML-DSA keypairs and manage larger certificate sizes?
Nota
After the crypto SDK is updated on the device, new ML-DSA keypair needs to be generated, CSR sent to PKI, and a new pure PQC or composite x.509 certificate received.
Can your device handle the large certificate sizes? New PQC x.509 certificates are larger. This can be problematic on constrained devices. Certificates will be substantially larger (roughly 10x) which causes problems for some protocols.
Can your device handle multiple certificates? Devices may require both existing RSA/ECC and new PQC certificate for backwards compatibility. This can be problematic on constrained devices.
Can you update the device’s root certificate store? New PQC root CA certificates need to be added to device root store. This can be problematic on constrained devices.
Do you have a reliable OTA update system to deploy root store updates reliably across your fleet of devices?
- ×
Is your network and backend services TLS 1.3-ready?
Can your network can the handle larger ClientHello messages?
Can your WAFs, firewalls, proxies and anything else in between your devices and your backend handles TLS 1.3 with PQC?
- ×
Is your certificate lifecycle management (CLM) agile?
Are all your TLS endpoints under CLM for zero-touch certificate management?
Can you automate the issuance of PQC certificates to your TLS endpoints?
Can you automate the renewal of PQC certificates?
- ×
Is your over-the-air (OTA) update service ready to scale?
Do you have a reliable device (OTA) update process to push new crypto libs and TLS stack updates to devices.
Does your OTA service support TLS 1.3 and PQC?
How will you update air-gapped or disconnected devices?
- ×
Does your PKI support the new PQC certificate types?
Pure PQC certificates: ML-DSA Root, ML-DSA Intermediate CA, ML-DSA End Entity.
Dual certificates: Pure PQC certificate + existing RSA/ECC certificate.
Hybrid certificates : Composite, such as MLDSA-44 + RSA 2048 + SHA256.
- ×
Does your PKI’s Hardware security module (HSM) support PQC?
Are you HSMs capable of PQC and are they FIPS certified?
Can your HSM be firmware updated?
Is your HSM vendor obtaining FIPS 140-3 certification?
- ×
Is your connected production solution enabled for TLS 1.3, including 3rd party services?
Nota
Only TLS 1.3 will support PQC! TLS 1.2 is in feature freeze. See https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/03/
Do your HTTP, MQTT, client and server software support TLS 1.3?
If TLS 1.3 is supported, is it actually enabled and configured? For example, in Paho, Mosquitto and other MQTT clients, you can specify the TLS version to use; if you have hard coded them to use TLS v1.2, that code will need to be updated.
- ×
Do the endpoints your devices connect to support TLS 1.3?
Azure IoT Hub does NOT support TLS 1.3
Azure IoT Central does NOT support TLS 1.3
Azure IoT DPS does NOT support TLS 1.3
Azure Event Grid MQTT broker supports TLS 1.3
AWS IoT Core supports TLS 1.3
- ×
Can your IoT network handle the increased network traffic and latency due to increased TLS handshake size?
Can you handle the increased handshake size? With ML-DSA, you are adding 14.7kB to the TLS handshake (two 1312-byte public keys plus five 2420-byte signatures). See https://blog.cloudflare.com/another-look-at-pq-signatures/.
Do your routers, proxies, firewalls, gateways support the new TLS 1.3 + ML-KEM + ML-DSA ClientHello message? This message is greater than the standard MTU on the Internet and must span multiple packets. See https://dadrian.io/blog/posts/pqc-signatures-2024/.
To prepare for the PQC, the industry has embraced a term from the US Department of Homeland Security - Cryptographic agility. This design feature allows updates to future cryptographic algorithms and standards. It does this without needing to change or replace the surrounding infrastructure - The US Department of Homeland Security.
Being “crypto agile” means being ready for new cryptographic threats; these threats come from quantum computers and other emerging technologies.
You do not have to wait until 2030 to start preparing
Phased approach to cryptographic agility

Discover
Perform a discovery across your connected product solution using the Discovery Checklist above.
Utilize Software Bill of Materials (SBOMs), Crypto Bill of Materials (CBOM) and Hardware Bill of Materials (HBOM) to identify the crypto and TLS libraries in use across your devices and whether they are PQC ready.
Engage with the standards bodies to drive clarity.
IETF, CA/B Forum, NIST, and so on.
Engage with your vendors to understand their PQC roadmap.
Utilize partners with PQC security expertise.
Test
Update your device’s cryptographic library to a PQC-ready, cross-platform, performant and FIPS-140-3 certified solution such as DigiCert’s TrustCore SDK.
Update your device’s TLS library to a PQC-ready TLS 1.3 stack that is cross-platform, performant and FIPS-140-3 certified solution such as DigiCert’s TrustCore SDK.
Integrate your device’s crypto library with a PQC-ready TPM, secure element or PUF solution such as DigiCert’s TrustCore SDK.
Ensure your readiness to issue pure PQC and composite certificates to devices using solutions such as DigiCert’s Device Trust Manager.
Update and test your TPMs for PQC readiness using DigiCert partner solutions such as Thales HSMs.
Deploy
Automate your device fleet software updates and issuance of PQC certificates utilizing an integrated device management, OTA update service and certificate lifecycle management solution such as DigiCert’s Device Trust Manager.
Manage
Automate software updates and certificate lifecycle across devices with scalable and automated management tools such as DigiCert’s Device Trust Manager.
All DigiCert Device Trust solutions built atop the DigiCert ONE platform are PQC-ready
DigiCert Device Trust Manager is PQC ready and supports:
Pure PQC (ML-DSA) certificate issuance and renewal over EST, SCEP, ACME, CMPv2 and REST API.
Composite certificate issuance and renewal over EST, SCEP, ACME, CMPv2 and REST API.
Batch issuance support for pure PQC and composite certificates.
Client-side and server-side keypair generation.
Automated certificate lifecycle management of ML-DSA and composite certificates so you are never faced with expired PQC device certificates.
DigiCert TrustEdge - our free security CLI for Linux devices - is PQC ready with support for generating ML-DSA keypairs, creating a CSR and sending a CSR to a PKI over EST or SCEP, all through a simple, free-to-download CLI.
DigiCert TrustCore SDK - our C-SDK embedded security toolkit - is PQC ready with support for ML-KEM, ML-DSA, TLS 1.3 and FIPS 140-3 certified crypto. Labs.digicert.com - our free PQC playground allowing you to quickly create PQC certificates for testing purposes.
No, it will only be supported in TLS 1.3. TLS 1.2 is in feature freeze and the IETF has stated “Put bluntly, post-quantum cryptography for TLS 1.2 WILL NOT be supported”. See https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/03/
CA/Browser Forum is discussing proposals for allowing the new NIST algorithms into certificates. Standards are coming to allocate the appropriate identifiers and agree on interoperable formats for public and private keys. These will probably become RFCs in the later half of 2025 or early 2026.
Yes. In August of 2024, NIST also announced changes to the CMVP program to allow the new PQC algorithms to be incorporated into FIPS 140-3. Cryptographic vendors, such as DigiCert, will be required to obtain FIPS 140-3 re-certification.
PKI Consortium PQC Conference - excellent video presentations on all things PQC.
NIST IR 8547 Transition to Post Quantum Cryptographic Standards - transition to Post-Quantum Cryptography Standards.
IETF State of Protocols and PQC - comprehensive list of PQC RFCs and drafts.
TLS Parameters - contains TLS values for existing and PQC algorithms.