PQC in Manufacturing: 11 Must-Ask Questions Before You Upgrade

Still think post-quantum cryptography (PQC) isn’t important in manufacturing? Go ahead. Ask your SCADA vendor if your PLC bootloader and root of trust can be updated to ML-DSA or LMS … Or, if you are forced to buy new hardware. Take a look at their reaction …You will begin to care about PQC right after.

Per usual, the OT point of view is completely different from an IT one — and it gets far less attention.  ‘Harvest now, decrypt later’ is not the central issue: process telemetry loses its value quickly. Instead, it has an impact on authenticity: firmware signatures, secure boot, and certificates. That’s where PQC hits.

A PLC installed today has an ECDSA public key in its bootloader and is designed to stay in the field until around 2050. That key can be extracted from the vendor’s public firmware.

With quantum capabilities, adversaries could obtain the key to sign malicious firmware payloads that any device would validate as authentic. Today this may sound like science fiction, but experts say that state-sponsored threat actors could achieve this capability by 2030.

How long does your company take to assess the risk and mitigations in place?

Knowing how the industrial sector works, you’d better start thinking about this now.

I know SCADA vendors have to wait for the relevant standards to evolve before rolling out interoperable PQC support in protocols, such as DNP3 or OPC UA. I also know that IEC 62443 certification and safety approvals limit what can change and when. But none of that is a good reason to ignore the problem.

The useful starting point is to understand what would actually have to change in your plant. These 11 questions connect the quantum risk to the equipment you own, the suppliers you depend on, and the production constraints you have to work around.

The Most Important Questions to Answer About PQC in Manufacturing

1. Why should manufacturers prepare for PQC now?

Because the equipment you buy today may still be running when its cryptography needs to be updated. Waiting for a reliable prediction of when quantum computers will break current algorithms leaves an uncomfortable amount of work dependent on someone else’s plan. A migration can involve several suppliers, product revisions, testing cycles, and maintenance windows. Discovering that a controller needs replacement is manageable when you have time to budget for it. Finding out after you’ve committed to keeping it in service for another ten years makes the decision much harder.

Start preparing while you still have choices. Identify dependencies, ask suppliers about supported upgrades, and bring cryptographic requirements into investment decisions already being made. That preparation is useful even as algorithms, products, and timelines evolve.

See NCSC migration guidance.

2. How does ‘harvest now, decrypt later’ affect industrial IP?

An attacker can collect encrypted information today and keep it until the cryptography protecting it becomes breakable. A sufficiently capable quantum computer could make that possible for communications relying on vulnerable public-key mechanisms. An attacker can collect encrypted information today and save it for later, hoping that quantum computing will eventually make it readable. Communications protected by vulnerable public-key cryptography are exposed to this “harvest now, decrypt later” risk.

Designs, recipes, and engineering files can remain commercially sensitive for years. A temperature reading that’s irrelevant tomorrow is a very different risk from a process expected to generate revenue for a decade.

Trace valuable information through supplier portals, remote engineering sessions, backups and cloud services, and protect each path according to how long that information stays valuable.

Confidentiality is only part of the problem. A controller accepting malicious firmware or trusting an impersonated device could have consequences for production and safety that outweigh the disclosure of routine telemetry. Protect industrial IP wherever it travels, while giving particular attention to the cryptography that determines which devices, commands, and software the plant trusts. The value of the data is important; so is the consequence of accepting something false as genuine.

See NIST’s explanation of the threat.

3. What are the NIST post-quantum cryptography standards, and what do they mean for manufacturers?

NIST finalized three standards in August 2024. ML-KEM, specified in FIPS 203, establishes shared secrets used to protect communications. ML-DSA, in FIPS 204, and SLH-DSA, in FIPS 205, provide digital signatures. These address different jobs: protecting a connection and verifying who signed a firmware image require different mechanisms.

For asset owners, the standards provide a concrete basis for product development and supplier discussions. They do not, by themselves, establish that an industrial product is ready to deploy.

See NIST’s standards announcement.

4. What does crypto-agility actually mean for a manufacturing plant?

It means being able to change cryptographic mechanisms while keeping the system secure and operational. That ability spans software, firmware, hardware, protocols, and the infrastructure managing them.

For a controller that will outlast several generations of security requirements, ask whether its verification software can be updated, whether it can accept new trust anchors, whether engineering tools will still recognize it afterward, and who will supply and support those changes. A device that supports PQC today may be rigid at the next transition, while an existing product may have a credible upgrade path that just needs testing and scheduling. Crypto-agility makes that path part of the product’s design, maintenance and purchasing decisions.

See NIST’s crypto-agility guidance.

 

5. Where is vulnerable cryptography used in OT?

Look wherever systems establish trust or protect information: remote-access connections, device certificates, engineering applications, firmware updates, and secure boot.

The distribution varies across a plant. An older field device may communicate without encryption while still checking a digital signature before accepting firmware. A supervisory application may use certificates to authenticate its peers. A gateway may establish encrypted connections to enterprise or cloud services. OPC UA provides one example of how certificates, signing, and encryption work together, subject to the deployed configuration.

While the Purdue model helps structure the search, the cryptographic dependencies cross its layers: a controller may rely on the manufacturer’s external signing infrastructure, and a local application on a centrally managed certificate service. Both belong in the migration picture.

6. Can legacy PLCs, SCADA systems, and industrial gateways support PQC?

Some can support an upgrade; others will require replacement or additional protection around them. Age alone does not settle the question. Processor capacity, memory, firmware architecture, protocol support, and the supplier’s maintenance commitment all affect the answer.

PQC implementations already exist for constrained processors. That demonstrates feasibility on particular platforms, without proving that an installed PLC can accommodate the same change or meet its timing requirements.

Where direct upgrades aren’t possible, a compatible gateway can carry a PQC-protected tunnel across an exposed network path, helping keep legacy equipment in service. Its protection ends at the tunnel endpoints, though: it doesn’t fix a controller’s firmware verification or secure connections inside the equipment zone. Those dependencies still need an upgrade, a replacement, or an explicitly managed risk decision.

See NIST’s embedded implementation validation.

7. How will PQC affect industrial device certificates, PKI, and machine identities?

A machine identity depends on more than the certificate stored on a device. It also depends on the certificate issuer, the algorithms involved, and the software that checks whether the identity can be trusted.

Moving that identity to PQC can therefore affect certificate authorities, enrollment services, device libraries, engineering tools, and every application that validates the certificate. Changing the certificate at one end achieves little if the other end cannot process it. NIST’s migration work includes these certificate and digital-trust dependencies.

Firmware signing raises a related problem: a manufacturer can adopt a new signature format that installed controllers can’t verify. Migration must cover the full chain, including renewal, revocation, recovery, and the period when old and new equipment run side by side.

See NCCoE’s migration project.

8. Where does hybrid cryptography help, and what does it leave unresolved?

Hybrid key establishment combines classical and post-quantum mechanisms within a defined construction. It can support a transition in which organizations retain established cryptography while introducing protection against quantum attacks.

In a factory, hybrid key exchange can run between supported gateways while the equipment behind them keeps using its existing interfaces. Both endpoints must support the scheme, and hybrid mode doesn’t guarantee compatibility with older software or cover firmware signatures and device certificates.

Assess it per connection and threat: check what is combined, how authentication works, what happens when negotiation fails, and whether fallback could silently remove the protection.

See ETSI’s hybrid key-establishment specification.

9. How should manufacturers inventory cryptography and assess suppliers?

Begin with a production process you understand and follow the systems it depends on. Existing asset records provide the equipment list. Configuration reviews, approved discovery methods, and supplier documentation add the cryptographic detail.

The useful result connects each cryptographic function to an owner and a change path. Knowing that a device uses RSA is a start. Knowing that its firmware verification is fixed in an immutable component tells you much more about the migration decision.

A cryptographic bill of materials can help organize this evidence, but it needs to be reconciled with the installed versions and configurations. NIST’s discovery work connects inventories to risk assessment and migration priorities. Supplier conversations should be equally specific. Ask about the model you operate, the function that will change, the release that delivers it, and the support period afterward. Record the difference between a deployable capability and a roadmap commitment.

See NCCoE’s cryptographic discovery.

10. How can migration be tested around production requirements?

Start from the operational behavior that must stay acceptable: benchmarks measure algorithms; production testing must measure the whole system. On representative equipment, test connection setup, certificate validation, firmware verification, memory use and recovery, including under load and during failures. A working connection in normal conditions doesn’t prove a redundant system will reconnect fast enough after a gateway restart. Separate startup work from time-critical control: a slower signature check during a planned update may be fine; resource contention affecting a control task may not.

Use the results to define a bounded production pilot, with agreed stop criteria and recovery procedures. This applies NIST’s emphasis on OT performance, reliability, and safety to the migration itself.

See NIST’s OT security guidance.

11. Which PQC deadlines and requirements actually apply to manufacturers?

There is no single date that applies to every factory. The answer depends on what you manufacture, where you sell it, which systems you operate, and the obligations attached to your customers.

For products within its scope, the EU Cyber Resilience Act has reporting obligations apply from September 11, 2026, with general application from  December 11, 2027. It does not establish a blanket 2027 PQC deadline.

The EU PQC roadmap recommends migration of high-risk use cases by 2030 and medium-risk use cases by 2035. A factory’s systems need assessment against those use cases; manufacturing is not automatically a lower-risk category

The UK NCSC provides indicative milestones of 2028 for discovery and initial planning, 2031 for the highest-priority migrations, and 2035 for completion. These are guidance milestones.

Government programmes have their own scope. US policy sets 2030 for key establishment and 2031 for digital signatures in specified high-value and high-impact federal systems. Canada’s government roadmap targets priority systems by 2031 and remaining systems by 2035. Neither is a universal private-sector manufacturing deadline.

Use the applicable dates to work backward through supplier delivery, validation, and maintenance windows. A deadline only becomes a useful plan when those dependencies have dates and owners.

PQC: Where Should We Start?

Begin with an assessment of the cryptography you use today with the Forescout PQC Exposure Assessment

Forescout can help identify quantum-vulnerable configurations and prioritize what needs attention. Use those findings to review your posture against relevant NIST guidance and other applicable frameworks, and build a migration plan around the systems you actually run.

A Practical PQC Migration Plan

Use this six-phase plan to connect product decisions with plant upgrades. The dates are suggested internal targets; bring them forward where your risks or applicable requirements demand it.