Post-Quantum Cryptography for Connected Devices

Connected products can remain in service for 10, 15, or even 20 years, while the cryptography inside them may have been chosen long before deployment. That makes post quantum cryptography more than an IT upgrade: you need to know which algorithms, libraries, certificates, keys, and protocols are buried in firmware and whether you can replace them safely. This blog explains the quantum risk, NIST standards, the new US federal 2030–2031 milestones, and the practical steps for making embedded products crypto-agile.

What Is Post-Quantum Cryptography (PQC)?

Post-quantum cryptography, or PQC, is cryptography designed to resist attacks from both classical and sufficiently capable quantum computers. The main concern is public-key cryptography because a cryptographically relevant quantum computer could undermine widely used schemes such as RSA and elliptic-curve systems. PQC replaces vulnerable mathematical methods with algorithms built around problems believed to remain hard for quantum computers. NIST now tells organizations to begin moving to finalized quantum-resistant standards rather than waiting for that computer to arrive.

For embedded products, quantum resistant cryptography must work within limits such as memory, processing power, bandwidth, secure boot design, and update mechanisms. One firmware image may contain TLS libraries, SSH components, code-signing checks, device certificates, secure update logic, and third-party cryptographic dependencies. A migration plan that only examines corporate servers can miss cryptography that remains in field devices for years. Quantum safe cryptography therefore requires you to ask whether a product can remain secure and updateable throughout its supported life as quantum computing advances.

Why It Matters Now: Harvest Now, Decrypt Later

The quantum threat is uncertain in timing, but some exposure exists today. In a harvest now decrypt later attack, an adversary collects encrypted traffic or stored ciphertext and keeps it until a future quantum computer can break the public-key protections used to secure the keys. Product data may include proprietary designs, service credentials, medical information, industrial telemetry, or communications that remain sensitive for years. The White House explicitly cited this collection-now risk in its June 2026 executive order on advanced cryptographic attacks.

The problem also affects trust and authenticity because future quantum attacks could undermine digital signatures used for software updates, device identity, certificates, and authenticated communications. A device that cannot accept a new signature scheme may become difficult to maintain even when the rest of its software still works. Your planning question should be broader than “When will quantum computers break RSA?” Ask how long products and data remain exposed, and how long discovery, testing, supplier coordination, and migration will take.

NIST Standards: ML-KEM, ML-DSA, SLH-DSA & the 2030–2031 Mandates

NIST finalized its first three principal PQC standards in August 2024: FIPS 203, FIPS 204, and FIPS 205. They cover key establishment and digital signatures, and NIST says organizations should begin applying them now. This move to quantum resistant cryptography is already a current migration task, not only a future research issue.

What the Three NIST Standards Do

The three standards are not interchangeable. ML-KEM establishes shared secrets, while ML-DSA and SLH-DSA provide digital signatures. Their performance and output sizes mean you need to test them on actual hardware, protocols, firmware, and update paths.

ML-KEM comes in three parameter sets and is NIST’s principal standardized key-encapsulation mechanism. ML-DSA is lattice-based, while SLH-DSA is a stateless hash-based signature standard derived from SPHINCS+. NIST is also standardizing additional algorithms, which is one reason crypto agility remains important after the first migration.

What the 2030–2031 Deadlines Mean for Product Teams

The 2030 and 2031 dates are concrete US federal milestones, but they are not a single legal deadline for every commercial connected device. Executive Order 14412 requires US federal high-value assets and high-impact systems to use PQC for key establishment by December 31, 2030, and digital signatures by December 31, 2031. It also directs work on procurement rules and critical infrastructure migration. These requirements can influence suppliers that sell into government and regulated supply chains.

OMB Memorandum M-26-15 sets out a phased federal plan: discovery and planning in 2026–2027, pilots in 2027–2028, prioritized key-establishment migration through 2030, signature migration in 2031, and broader completion by 2035. It also says agencies should use automation for cryptographic inventory and maintain a central CBOM where possible. Customer requirements may move faster than general legislation, so you need to understand whether new products can support quantum safe cryptography before it becomes a contract condition. Treat 2030 as a planning horizon, not a reason to wait until 2029.

The IoT/OT & Embedded Problem: Long Lifecycles, Hard-to-Patch Crypto

PQC migration is harder in connected products because cryptography is tied to physical devices. You may have limited RAM, flash, CPU capacity, bandwidth, or battery power, while bootloaders and secure elements can be difficult to change. Legacy toolchains, vendor SDKs, precompiled libraries, and supplier components can also hide cryptographic dependencies. A cloud service can often update a library centrally, while an embedded fleet may contain many firmware branches and hardware revisions.

PQC algorithms can place different demands on keys, signatures, memory, and bandwidth, so you need to test boot verification, update packages, handshakes, certificates, storage, and interoperability on real hardware. You also need to analyze the shipped binary because source repositories can miss statically linked or inherited code, automated vulnerability management can keep firmware findings tied to real product versions. A device launched in 2027 with a 12-year support period may still operate beyond the 2030–2031 federal milestones and NIST’s broader 2035 transition horizon. Building an update path now is easier than discovering later that a deployed product cannot accept new algorithms.

Crypto-Agility & the Cryptographic Bill of Materials (CBOM)

Crypto agility is the ability to replace or reconfigure cryptographic algorithms, protocols, keys, certificates, and implementations without redesigning the whole product. It helps you respond when standards change, an algorithm weakens, a library reaches end of life, or a customer requires a new profile. PQC makes this urgent because migration will happen in stages, not through one universal cutover.

Why Crypto-Agility Matters in Firmware

A crypto-agile design separates cryptographic choices from the rest of the product where practical. Abstraction layers, configurable algorithm suites, updateable trust stores, and replaceable libraries make controlled change easier. Hardware can still create fixed points, so map decisions that live in secure boot, bootloaders, operating systems, applications, cloud services, and supplier components. If a secure boot ROM understands only one signature scheme, software changes above it may not be enough.

OMB’s 2026 guidance also calls for cryptographically agile architectures and agile key-management infrastructure in federal systems. It recommends algorithm negotiation while guarding against downgrade attacks. For connected-product teams, the lesson is to design migration paths before old cryptography becomes unacceptable.

Build a CBOM Before You Plan the Migration

You cannot migrate cryptography you cannot see. A cryptographic bill of materials/CBOM records cryptographic assets and their use, such as algorithms, libraries, protocols, key types, certificates, implementations, and the products or components that depend on them. OMB describes a continuously updated cryptographic inventory as the foundation of migration planning and says the data should populate a central CBOM.

A useful CBOM should help you answer questions such as:

• Which products and firmware versions use RSA, ECC, Diffie-Hellman, or other quantum-vulnerable methods, including code inherited from older releases?
• Which libraries implement those algorithms, which versions are deployed, and who owns the update path for each dependency?
• Where are they used for secure boot, updates, TLS, VPNs, SSH, certificates, device identity, manufacturing, or service access?
• Which implementations are supplier-controlled, and what evidence has each supplier provided about PQC support and future maintenance?
• Which products can accept cryptographic updates without hardware replacement, and which require a bootloader, secure element, or platform change?
• Which data flows have long confidentiality needs and high harvest now decrypt later risk, and how long must that information remain protected?

An SBOM management tool provides a software inventory, but an SBOM and CBOM answer different questions. The SBOM tells you which software components are present, while the CBOM focuses on the cryptographic capabilities and dependencies that create migration work. You need both views because a library name alone may not reveal which algorithm is active in a specific firmware image.

PQC Readiness Assessment: How ONEKEY Discovers Crypto in Firmware Binaries

A post-quantum cryptography readiness assessment should start with evidence from the products you actually ship. ONEKEY automatically analyzes binary firmware without source code and can identify cryptographic algorithms, libraries, and specific implementations, while its Query Language can search larger datasets for products using methods such as RSA. Binary analysis matters because supplier packages, statically linked libraries, and precompiled modules can introduce cryptography that source-level searches miss. This turns post quantum cryptography from a broad future concern into a product-level worklist.

ONEKEY does not claim that the industry has solved fully automated Crypto-SBOM creation. You can combine crypto discovery with an SBOM audit to compare firmware evidence with software inventory and supplier information. This gives PSIRT, engineering, product, and compliance teams a shared basis for prioritization, while ONEKEY’s PQC readiness assessment webinar provides an on-demand look at how firmware analysis can uncover cryptographic libraries and support early migration planning.

PQC Migration Checklist for Product Teams

Discovery, architecture, testing, and lifecycle planning need to move together. You do not need to replace every algorithm at once, but you need an inventory showing where risk exists and which products are hardest to change. NIST recommends starting migration now, while US federal policy emphasizes inventory, phased execution, and cryptographic agility.

• ‍Define product scope and ownership. List product families, firmware branches, hardware revisions, dependencies, markets, and support periods. Assign owners across security, engineering, compliance, and supplier management so each migration decision has a clear accountable team.‍
• Discover cryptography in shipped firmware. Scan actual binaries and map algorithms, libraries, protocols, certificates, keys, and signing functions. Do not assume source repositories form a complete deployed inventory, especially when suppliers deliver precompiled components.‍
• Create and maintain a cryptographic bill of materials/CBOM. Link findings to product versions and update the inventory as firmware changes. Use it to identify quantum-vulnerable dependencies, owners, remediation status, and products that need deeper review.‍
• Prioritize by data and product lifetime. Long-lived sensitive data needs early attention because of harvest now decrypt later exposure. Devices with limited update paths also need early decisions, especially when customers expect support beyond the current hardware generation.‍
• Classify each cryptographic use. Separate key establishment, encryption, signatures, secure boot, update verification, authentication, device identity, and certificate functions. The replacement and test plan depends on what the cryptography does and what failure would mean for the product.‍
• Assess crypto agility before choosing algorithms. Check whether firmware, bootloaders, secure elements, protocols, key management, and backend services can support new schemes. Record anything fixed, supplier-controlled, or hardware-constrained, then estimate whether the remedy needs software, hardware, or both.
• ‍Plan around standardized algorithms. Evaluate ML-KEM for key establishment and ML-DSA or SLH-DSA for relevant signature uses, based on NIST standards and protocol-specific guidance. Avoid proprietary “quantum-safe” designs when standardized approaches are available, and document why each algorithm fits the device use case.‍
• Prototype on representative hardware. Measure boot time, latency, RAM, flash, bandwidth, signature size, power use, and update behavior. Test the whole chain, not only the cryptographic library.‍
• Test interoperability and downgrade resistance. Verify gateways, cloud services, certificates, management tools, and peer devices across realistic network conditions. If you use hybrid or negotiated approaches, make sure an attacker cannot force an unacceptable older algorithm.‍
• Coordinate suppliers and procurement. Ask what cryptography suppliers provide, how they will support PQC, and whether their libraries or hardware can be updated. Add crypto agility requirements to future evaluations, contracts, security questionnaires, and component selection criteria.‍
• Integrate PQC with product security operations. Track migration tasks alongside firmware risk, SBOM changes, PSIRT work, and vulnerability management. A repeatable post-quantum cryptography readiness assessment should feed this work rather than sit in a one-time spreadsheet. Keep evidence so future releases and audits can show why a product was prioritized or deferred.‍
• Set milestones before external deadlines force them. Use 2030, 2031, and 2035 as US federal and NIST reference points, with earlier dates where data lifetime or product lifecycle requires them. Review the roadmap as standards, supplier support, protocol profiles, and quantum computing research change.