PQC for IoT Manufacturers

What PQC means for IoT manufacturers

Post-quantum cryptography (PQC) is cryptography based on mathematical problems that future large-scale, fault-tolerant quantum computers are not expected to solve efficiently. The principal migration objective is to reduce exposure created by today’s quantum-vulnerable public-key cryptography. For an IoT manufacturer, the scope includes more than the device’s communications stack: it can include firmware and software signing, device and user authentication, key establishment, certificates and PKI, network protocols, cryptographic libraries, hardware, cloud services, update systems, and manufacturing or provisioning processes. C113

The work applies to consumer IoT, enterprise IoT, industrial IoT, sensors, gateways, controllers, embedded components, and the services that manage them. The exact priority depends on the data and functions protected. A sensor’s data may not always require strong confidentiality, while the integrity of sensor readings or commands may be critical because faulty readings or commands can contribute to industrial-control-system failures. [C3]1

Why PQC matters in the IoT lifecycle

IoT products often remain deployed for many years, and their cryptographic dependencies can outlive the teams, suppliers, protocols, and hardware originally used to build them. Organizations are encouraged to prepare proactively for migration, including by engaging vendors and identifying current reliance on quantum-vulnerable cryptography. The inventory should support risk assessment and reveal data that could be collected now and decrypted later when a cryptographically relevant quantum computer becomes available. C123

For manufacturers, the exposure may exist at several trust boundaries: device-to-device communications, device-to-cloud connections, remote administration, gateway-to-control-system links, certificate issuance, secure boot, firmware updates, application updates, and code-signing infrastructure. NIST’s transition draft identifies digital signatures, key establishment, network protocols, cryptographic libraries, hardware, PKI, applications, and services as migration areas. [C2]3

Industrial and operational environments add consequences beyond confidentiality. Industrial IoT devices may be internet-connected to use cloud services; those devices can provide an entry point toward control networks and the enterprise IT zone through a demilitarized-zone firewall. Remote logins to industrial-control-system IT zones also need secure authentication, and wireless field devices and sensors require appropriate protection. [C3]1

Start with discovery, inventory, and risk prioritization

Create a cryptographic inventory before committing to a product-by-product migration schedule. CISA, NSA, and NIST recommend a project team and proactive cryptographic discovery to identify quantum-vulnerable systems and assets. For an IoT manufacturer, the inventory should be connected to product records, bills of materials, firmware versions, supported protocols, certificate profiles, signing keys, hardware security dependencies, cloud services, supplier components, and field-support processes. [C1]2

• Identify algorithms and cryptographic functions used for code signing, secure boot, firmware and software updates, device identity, user and machine authentication, key establishment, transport security, message integrity, and document or data signing.
• Map each use to the product, firmware release, hardware platform, library, protocol, certificate authority, service provider, supplier, and deployment environment.
• Record whether the component can be updated remotely, requires physical service, is embedded in a larger product, or cannot be replaced without replacing the product.
• Associate each dependency with the confidentiality, integrity, availability, safety, regulatory, and business impact of failure or compromise.
• Identify internet-connected devices, long-lived secrets, long-term confidentiality requirements, industrial-control systems, and high-impact assets for early treatment.

Prioritization should give particular attention to high-impact systems, industrial-control systems, and information requiring long-term confidentiality or secrecy. Custom-built products, especially older systems, may require substantial effort to make quantum-resistant. For commercial off-the-shelf products, the manufacturer’s migration roadmap and delivery dates are material inputs to the customer’s own roadmap. [C1]21

Design the product and platform for transition

PQC migration changes cryptographic implementations, key sizes, algorithm performance, protocols, libraries, and compatibility behavior. Applications and services may require code refactoring, extensive testing, and changes to user interfaces. In an IoT product, those effects should be assessed across constrained devices, gateways, provisioning systems, update servers, management consoles, and cloud APIs rather than in isolation. [C2]3

A practical architecture separates cryptographic policy and algorithm selection from product business logic wherever feasible. It should make supported algorithms, certificate profiles, protocol negotiation, key-management procedures, and update mechanisms replaceable under controlled change management. Hardware and firmware roadmaps should account for memory, processing, bandwidth, energy, boot-time, storage, and certificate-size effects; the cited evidence establishes that key sizes and algorithm performance must be considered, but it does not prescribe particular PQC parameter sets or device-resource thresholds. C234

Secure update and signing paths are especially important because software and firmware updates create and validate digital signatures. A manufacturer that updates transport encryption but leaves a quantum-vulnerable signing dependency may still retain a significant migration gap. Inventory and test the complete trust chain, including signing systems, certificate references, boot verification, update authorization, rollback controls, and field-deployment procedures. C123

Plan interoperability and transition patterns

Backward compatibility and interoperability are crucial during the transition. Products may need to communicate with legacy devices, gateways, enterprise systems, and services that do not yet support PQC. NIST’s transition material describes hybrid key-establishment mechanisms and dual signatures as possible approaches where an application can justify their implementation cost, performance reduction, and engineering complexity. [C2]3

Hybrid solutions are not automatically safer or simpler. They can add architectural and implementation complexity, increase security risks and costs, and are typically expected to be temporary steps toward tools using only PQC algorithms. Their suitability depends on the hybrid technique, application, vendor community, user community, and applicable requirements. Define entry and exit criteria before adopting one, and avoid allowing a temporary compatibility mode to become an unmanaged permanent dependency. [C2]3

For certificate-based ecosystems, a staged migration may require a new PQC root of trust and new certificates for entities on the network. A parallel PKI can operate alongside the traditional PKI for a period, although controlled environments may support a single transition. Some devices may require physical interaction, so certificate and trust-anchor migration must be tested against actual field-service capabilities. [C4]1

Test the deployed behavior, not only the implementation

Testing should cover cryptographic correctness, protocol negotiation, certificate issuance and validation, code signing, secure boot, updates, recovery, interoperability, performance, resource consumption, and failure handling. For constrained or difficult-to-service devices, test realistic network conditions, power interruptions, storage limits, firmware rollback, gateway translation, and long-duration operation. The evidence does not provide universal performance limits; manufacturers should establish product-specific acceptance criteria through engineering and security review. C23

A migration can appear successful while systems silently fall back to traditional cryptography. The NCSC recommends additional testing to confirm that standardized PQC cipher suites are actually being used rather than merely being available. Manufacturers and operators should therefore inspect negotiated protocols, certificates, algorithm identifiers, logs, and telemetry, and should test both intended and failure paths. [C5]1

Assurance should continue after release. Maintain independent security review where appropriate, document residual legacy dependencies, test upgrades on representative hardware, and use controlled rollout stages. Where products are deployed into OT environments, coordinate cryptographic changes with maintenance and infrastructure-improvement windows because physical infrastructure changes require significant planning. C31

Coordinate suppliers, customers, and cloud dependencies

Engagement with vendors is critical. A manufacturer’s roadmap should state when and how each relevant supplier plans to provide updates or upgrades, what versions will support PQC, what hardware or protocol prerequisites apply, and what migration costs or service constraints are expected. For cloud-hosted products and services, organizations should engage cloud providers about their quantum-readiness roadmaps and later clarify the configuration changes or application updates needed to enable PQC. [C1]2

Procurement should make cryptographic dependencies visible before a product is selected or refreshed. Ask suppliers whether components use quantum-vulnerable algorithms, whether firmware and signing infrastructure can be upgraded, whether protocols support staged transition, how fallback is controlled, how certificates and keys are replaced, and how long security support will continue. These questions should be tied to product acceptance, support commitments, vulnerability handling, and end-of-life planning rather than treated as informal roadmap discussions. C12

Treat PQC migration as an IT/OT modernization effort. Align cryptographic work with hardware refreshes, firmware redesigns, network modernization, platform replacement, and other maintenance windows. This can reduce duplicate engineering and service activity while making difficult-to-upgrade devices visible in capital and lifecycle planning. C121

Measure progress and execute in stages

A useful program measures actual migration progress and residual exposure. The NCSC gives the example of quantifying how many software clients use PQC and identifying those that do not. For IoT manufacturers, equivalent measures can cover product families, firmware versions, device cohorts, gateways, cloud endpoints, signing systems, certificate populations, suppliers, and protocol sessions. Metrics should show how far migration has progressed, where remediation is required, and when support for traditional algorithms can be turned off. [C5]1

1. Assign accountable owners across product security, engineering, IT, OT, procurement, cloud operations, support, and risk management.
2. Build and maintain the cryptographic inventory, including device, firmware, protocol, certificate, signing, supplier, and service relationships.
3. Rank products and dependencies by impact, deployment life, confidentiality horizon, integrity or safety consequence, internet exposure, and upgrade difficulty.
4. Define the target architecture and transition policy, including interoperability requirements, fallback controls, hybrid-use criteria, and retirement conditions.
5. Prototype on representative constrained devices and services; measure performance, memory, bandwidth, energy, update time, certificate handling, and failure recovery.
6. Pilot staged deployment with telemetry and rollback controls, then verify negotiated cryptography and signing behavior in production-like environments.
7. Publish supplier and customer migration commitments, support boundaries, documentation, and end-of-life decisions.
8. Review metrics regularly and remove traditional support only after evidence shows that remaining dependencies are understood and risk-accepted.

Conclusion

For IoT manufacturers, PQC is a lifecycle transformation covering products, firmware, hardware, protocols, PKI, signing, cloud services, suppliers, and field operations. Begin with discovery and prioritization; focus early on high-impact, industrial, internet-connected, long-lived, and difficult-to-upgrade devices. Build cryptographic agility into product and platform architecture, use transition mechanisms deliberately, test real negotiated behavior, and measure deployment rather than feature availability. The evidence supports preparation now, while preserving the distinction between current guidance, draft transition material, and product-specific engineering decisions. C1C3[C6]142