PQC for Manufacturing

What PQC means for manufacturing

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 motivation is that such computers could efficiently solve the hard mathematical problems on which today’s asymmetric public-key cryptography relies. PQC is therefore the primary mitigation described in the cited guidance for this future threat. The evidence does not establish when a cryptographically relevant quantum computer will exist; it establishes why organizations should prepare now.1

For a manufacturer, the scope is broader than a plant firewall or a single TLS configuration. It includes network protocols and security technology standards, software cryptographic libraries, cryptographic hardware, PKI and other infrastructure components, and IT applications and services. Applications may need changes for encryption, digital signatures, and key exchange, including code refactoring, testing, protocol and library compatibility work, performance assessment, and possible interface redesign.2

The manufacturing boundary also includes operational technology and industrial control systems, whether custom-built or commercial off-the-shelf. It reaches machine and user authentication, code signing, software and firmware updates, remote administration, enterprise services, industrial IoT, sensors, wireless field devices, cloud-connected systems, and the certificates that establish identity. A useful definition of PQC for manufacturing is therefore: a risk-prioritized, operationally safe transition of cryptographic dependencies across the complete IT/OT production ecosystem.23

Why manufacturing should act early

Manufacturing environments often combine long-lived equipment, difficult-to-service locations, proprietary protocols, safety or quality consequences, and dependencies on vendors that control update schedules. The cited guidance recommends giving priority to high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs. Older custom-built products are likely to require the most effort to make quantum-resistant, which makes inventory and lifecycle planning especially important.3

The risk is not only future decryption of stored information. Digital signatures support identity, certificates, code signing, software and firmware updates, and trust decisions. In an ICS, the integrity of sensor data and commands may be critical even when the confidentiality of the underlying data is not: faulty readings or commands can contribute to ICS failures. This makes authentication and integrity a central manufacturing concern, not merely a data-privacy concern.1

Remote logins over the internet are now common in industrial environments, and OT/IT convergence is continuing. A typical ICS network may use OT and IT zones separated by a DMZ firewall. Remote-access channels into ICS IT zones therefore need quantum-secure treatment, while internet-connected field devices can create an entry point toward control networks and then the ICS enterprise IT zone through the DMZ.1

Manufacturers should also consider “harvest now, decrypt later” exposure for information whose confidentiality must persist. The NIST initial public draft says migration guidance is expected to prioritize quantum-resistant key-establishment schemes, particularly in interactive protocols such as TLS and IKE, to address that risk. This is guidance in an initial public draft, not a claim that every plant should immediately replace every cryptographic mechanism without testing.2

A practical manufacturing migration workflow

A sound program begins with governance. Establish a quantum-readiness project team that can scope the migration across IT and OT, security, engineering, plant operations, procurement, architecture, safety, legal, and key suppliers. The joint CISA, NSA, and NIST fact sheet recommends creating a roadmap while standards are in development and beginning with a project management team. In manufacturing, the team should have authority to sequence changes around maintenance windows and production constraints.3

1. Discover cryptographic use across IT, OT, ICS, industrial IoT, applications, servers, endpoints, network protocols, libraries, hardware, firmware, PKI, cloud services, remote access, and update mechanisms.
2. Record the asset owner, business or safety function, cryptographic purpose, algorithm or protocol where known, certificate and key dependencies, data lifetime, upgrade path, vendor, and plant or network location.
3. Assess impact and prioritize high-impact systems, ICS, long-term secrets, remote-access paths, code-signing and update chains, and internet-connected or difficult-to-replace devices.
4. Define target states and transition patterns, including PQC-capable products, protocols, certificate hierarchies, key establishment, signatures, and rollback or recovery procedures.
5. Pilot in representative but controlled environments; test interoperability, resource consumption, latency, availability, certificate handling, update behavior, and safe failure modes.
6. Deploy in stages coordinated with maintenance and infrastructure improvements, then verify actual protocol behavior and measure adoption, exceptions, residual risk, and readiness to retire traditional algorithms.

Discovery should use cryptographic discovery tools where possible. The cited fact sheet describes an inventory as a way to identify quantum-vulnerable algorithms in network protocols and on end-user systems and servers, including applications and associated libraries. The inventory also helps correlate outside access to datasets and identify information that may be targeted now and decrypted when a quantum computer is available. It should be treated as a living operational record rather than a one-time spreadsheet.3

Prioritization should combine cryptographic exposure with manufacturing consequence. A public-facing service containing ordinary, short-lived information may not outrank a plant certificate authority, remote engineering channel, firmware-signing process, safety-relevant control path, or design archive with a long confidentiality requirement. The evidence supports prioritizing by impact, ICS involvement, and secrecy duration; it does not provide a universal scoring formula, so each organization should document its assumptions and risk appetite.312

Architecture considerations for plants and industrial devices

Remote access deserves an end-to-end view. Review user and machine authentication, VPN or other network security protocols, certificates, jump hosts, privileged access, vendor support channels, and the boundary between enterprise IT and OT. A DMZ can separate zones, but it does not remove the need to migrate the cryptographic mechanisms used across the permitted paths. Test both normal operation and denied, expired, or unavailable-certificate conditions so that a cryptographic change does not create an unsafe operational surprise.1

Industrial IoT and field devices require special attention because they may be resource-constrained, non-upgradeable, difficult to service, embedded in larger products, unsuitable for replacement, dependent on proprietary communications, or based on protocols that are not yet PQC-compatible. Internet connectivity may also expose a route into control networks. These limitations mean that “upgrade the device” cannot be assumed to be the default remediation; compensating controls, isolation, replacement planning, or a supplier-led update may be necessary, with the decision recorded as residual risk.1

Physical infrastructure changes require significant planning and should, as far as possible, coincide with other maintenance and improvement work. In a manufacturing program, this favors a multi-year asset and shutdown plan: align certificate, gateway, controller, sensor, server, and network changes with approved maintenance windows, validate spares and recovery images, and avoid introducing an untested cryptographic dependency immediately before a production-critical period.1

Enterprise PKI migration is a distinct workstream. A large enterprise may need a new PQC root of trust and new PQC certificates for network entities. Possible models include a parallel PQC PKI operating alongside the traditional PKI, a controlled one-step transition, or—more likely—a staged period in which both operate. Protocols such as TLS and IKE must support selecting the intended certificates during the transition. Some devices may require physical interaction even when most certificate issuance can occur through network management.1

Standards, crypto agility, and hybrid migration

Standards maturity matters because algorithm standards are building blocks for protocols, products, and services. The NIST material cited for this article is an initial public draft dated November 2024, while the joint CISA, NSA, and NIST fact sheet is final and dated August 17, 2023. The UK NCSC material is current and dated March 20, 2025. Teams should preserve these statuses and continue checking applicable authoritative guidance before committing a plant-wide design.41

Crypto agility is the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. For manufacturing, agility means separating cryptographic policy from hard-coded plant logic where safely possible, supporting controlled algorithm and certificate changes, maintaining tested interfaces, and making dependencies visible. It is an architectural capability, not permission to change algorithms casually in production.4

Hybrid key-establishment techniques or dual signatures may help organizations transition where legacy algorithms remain necessary. NIST’s draft says existing standards and guidelines can accommodate their use when at least one component digital-signature algorithm is NIST-approved, and that NIST will accommodate hybrid key establishment and dual signatures in FIPS 140 validation when suitably combined with a NIST-approved scheme. However, the same material says hybrid solutions add implementation and architectural complexity, which can increase security risks and costs, and are typically expected to be temporary.3

Vendor management, testing, and useful measures

Manufacturing depends heavily on COTS equipment, embedded components, cloud services, and specialist suppliers. Procurement and security teams should ask each vendor when and how it plans to deliver PQC-enabling updates or upgrades, what those changes will cost, which products and versions are covered, and what configuration or application work the customer must perform. For cloud-hosted products, engage the cloud provider on its quantum-readiness roadmap. The cited guidance frames migration as an IT/OT modernization effort.1

Vendor statements are not a substitute for verification. After standardized PQC cipher suites become available, test that systems actually use them and do not silently fall back to traditional cryptography. Test application behavior, protocol negotiation, certificates, signatures, key establishment, firmware and code-signing validation, logging, monitoring, recovery, and performance under realistic plant conditions. Maintain an assurance process that checks whether migration and the broader cybersecurity uplift meet their goals.1

Measures should show both progress and residual exposure. Useful examples supported by the evidence include the number and proportion of software clients using PQC, the identity of clients that are not, the number of high-impact or ICS assets inventoried, the number of remote-access paths tested, the number of vendor roadmaps received, the number of devices with no upgrade path, and the number of exceptions with owners and treatment dates. Metrics should help determine whether remedial action is required and when support for traditional algorithms can be turned off.1

Risks, limitations, and practical next steps

PQC migration has technical and operational tradeoffs. Applications may face changed key sizes, algorithm performance, protocol compatibility, library updates, code changes, and extensive testing. Hybrid approaches may increase complexity, cost, and security risk. Industrial devices may not be upgradeable or may use proprietary protocols. A migration plan that ignores these constraints can create availability or safety problems even while reducing theoretical quantum exposure.21

The evidence does not provide a single manufacturing deadline, universal algorithm choice, complete product list, or assurance that every vendor has finalized implementation details. The joint fact sheet specifically notes that final implementation specifics for draft algorithms were incomplete in its stated context. Accordingly, organizations should distinguish approved standards and supplier commitments from experiments, document uncertainty, and revisit the roadmap as standards, products, and sector guidance evolve.41

• Name an accountable IT/OT quantum-readiness team and obtain plant-operations, engineering, procurement, and supplier participation.
• Launch cryptographic discovery and create an inventory linked to asset criticality, data lifetime, safety or production function, and upgradeability.
• Prioritize ICS, high-impact assets, long-lived secrets, remote access, code signing, firmware updates, PKI, and internet-connected field devices.
• Request dated PQC roadmaps, supported versions, configuration requirements, testing responsibilities, costs, and end-of-support implications from COTS and cloud vendors.
• Select controlled pilots that represent enterprise IT, remote access, PKI, a plant network, and a constrained or difficult-to-replace device.
• Define test, rollback, exception, and evidence requirements before production changes; measure real protocol use and fallback behavior.
• Review the roadmap periodically against authoritative standards and guidance, preserving document status, version, dates, and unresolved limitations.

Conclusion

PQC for manufacturing is a coordinated resilience and modernization program across cryptography, IT, OT, ICS, industrial IoT, PKI, suppliers, and plant operations. The most defensible starting point is discovery: identify vulnerable cryptography, connect it to operational and data criticality, and expose dependencies that ordinary asset inventories miss. From there, prioritize integrity-sensitive and high-impact paths, engage vendors, design for crypto agility, test staged or hybrid patterns carefully, and measure actual adoption and fallback. Preparation can begin now while standards and implementation guidance continue to mature.234