TL;DR: Post-quantum cryptography in manufacturing is less about “harvest now, decrypt later” and more about preserving authenticity in secure boot, firmware signatures, and machine certificates as PLCs and SCADA assets remain in service for decades, according to Forescout. That makes crypto-agility and supplier upgrade paths a governance issue, not a purely technical one.
At a glance
What this is: This is a manufacturing-focused analysis of post-quantum cryptography that says the real risk sits in firmware trust, secure boot, and certificates rather than only in encrypted communications.
Why it matters: It matters because identity and access teams supporting OT, PKI, and machine identity programmes need to plan for long-lived device trust chains that may outlast current algorithms and hardware assumptions.
Context
Post-quantum cryptography in industrial environments is mainly a trust and integrity problem. The article argues that manufacturing systems often depend on firmware signatures, secure boot, device certificates, and update paths that must remain trustworthy for decades, even when the underlying cryptography changes.
That creates a governance gap for OT, PKI, and machine identity programmes. If a PLC or gateway cannot accept new trust anchors, verify new signatures, or be upgraded within maintenance and safety constraints, the organisation may need replacement, compensating controls, or an explicit risk acceptance decision.
Key questions
Q: What breaks in manufacturing when firmware trust cannot move to post-quantum cryptography
A: The failure is not just weaker encryption. Firmware signatures, secure boot, and device certificates can become impossible to update while the asset remains in service. That leaves organisations with controllers that may keep running but cannot adapt their trust model, which forces replacement, compensating controls, or formal risk acceptance.
Q: Why do long-lived PLCs make post-quantum migration harder than normal crypto upgrades
A: Because the asset lifetime, safety approvals, and supplier support windows are all longer than the lifecycle of current cryptographic assumptions. A migration may involve new hardware, firmware changes, protocol updates, testing, and maintenance planning, so delay increases both cost and operational disruption.
Q: How do teams know whether crypto-agility is actually working?
A: Crypto-agility is working when algorithms can be changed without major re-engineering and the inventory shows which systems will be affected before the change is made. Signs of failure include unknown embedded libraries, orphaned certificates, and long manual remediation cycles. If the estate cannot absorb algorithm change predictably, the architecture is not agile enough.
Q: What is the difference between hybrid cryptography and full post-quantum readiness in OT
A: Hybrid cryptography helps protect selected connections during transition, but full readiness means the entire trust chain can handle new algorithms, certificates, and firmware verification. A hybrid tunnel can reduce exposure on one path while leaving bootloaders, libraries, and device identities unchanged.
Technical breakdown
Why firmware signatures are the real PQC pressure point
In OT, post-quantum change is not mainly about bulk data confidentiality. The article’s core technical point is that firmware authenticity, secure boot, and device certificates are what keep industrial equipment trustworthy. If a vendor’s public firmware exposes an elliptic curve public key today, an attacker with future quantum capability may be able to derive signing capability and produce malicious firmware that appears valid. That shifts PQC from an encryption discussion to a trust-anchor problem tied to bootloaders, signing infrastructure, and field-deployed controllers that may remain live for decades.
Practical implication: Map every firmware trust chain and identify which controllers cannot verify a new signature algorithm without replacement.
Crypto-agility in plants depends on hardware, firmware, and tools
Crypto-agility means changing cryptographic mechanisms without breaking operations. In manufacturing, that spans the device itself, the engineering tools that manage it, the protocols in use, and the certificate infrastructure behind them. The article shows why this is difficult: a device may need new trust anchors, updated verification software, or supplier-supported firmware revisions, and all of those changes must still pass safety, certification, and uptime constraints. PQC readiness is therefore a lifecycle property, not a one-time product feature.
Practical implication: Assess whether each plant asset can accept updated trust anchors and validation logic before you assume PQC migration is possible.
Machine identity migration is broader than certificate replacement
A machine identity is not only the certificate stored on the device. It also includes the issuer, the algorithm set, the renewal path, revocation handling, and the software that validates the identity at the other end. The article correctly notes that changing a certificate without changing the verifier achieves little. For industrial estates, this means the migration problem spans CA services, enrollment, engineering applications, gateways, and any controller that checks firmware or peer identity. Hybrid cryptography can help at the connection layer, but it does not fix immutable boot chains or unsupported verification libraries.
Practical implication: Inventory the full certificate and signature chain for each device, including verifiers, not just the certificate itself.
Threat narrative
Attacker objective: The attacker wants to bypass industrial trust controls by making malicious firmware or a fake device appear authentic to field equipment.
- Entry begins when an attacker obtains a vendor public firmware image or other externally accessible material that reveals the device's trust material and signing approach.
- Credential_harvested or trust material abuse follows if future quantum capability allows extraction of a signing key that was assumed to remain private.
- Escalation occurs when the attacker uses that signing capability to create malicious firmware or impersonated device software that validates as authentic on the controller.
- Impact is unauthorized firmware acceptance on industrial equipment, which can undermine safety, availability, and production integrity.
Breaches seen in the wild
- Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
PQC in manufacturing is fundamentally an identity and authenticity problem, not just an encryption problem. Industrial environments depend on signed firmware, secure boot, and device certificates to decide what is trusted. When those trust anchors cannot be updated, the organisation loses control over machine identity even if the transport layer is still encrypted. Practitioners should treat PQC migration as a machine identity governance programme.
Long-lived OT assets create a standing trust obligation that most enterprise crypto programmes underestimate. A PLC installed today may still be in service in 2050, which means the cryptographic assumptions baked into its boot chain can outlive several generations of standards. That makes crypto-agility, supplier commitments, and supportability part of lifecycle governance, not an optional enhancement. Practitioners should align procurement, maintenance, and security decisions around the asset’s real service life.
Certificate replacement alone will not solve industrial PQC risk. The article correctly shows that machine identity depends on issuers, algorithms, verifiers, enrollment services, and update paths. If any one of those remains fixed, migration can stall or create false confidence. Practitioners should review the entire trust chain, including the software that validates the device on the other end.
Hybrid cryptography is a transition tool, not a complete control strategy. It can help preserve compatibility while introducing quantum-resistant protection, but it does not solve immutable firmware verification or unsupported legacy libraries. That distinction matters for plant owners, because a transition layer can reduce exposure on some links while leaving core device trust unchanged. Practitioners should use hybrid approaches only where endpoint support and failure handling are clearly understood.
Crypto-agility is now a governance requirement for industrial security programmes. The field needs a named concept here: firmware trust debt, the accumulated inability of old controllers, tools, and trust anchors to adapt when cryptographic assumptions change. Once that debt is embedded in plant equipment, migration costs rise sharply and safety constraints narrow the available options. Practitioners should measure where that debt is building and make it visible in risk reporting.
What this signals
Firmware trust debt: industrial security programmes now need a way to measure how much embedded trust logic cannot be upgraded when cryptographic standards change. That debt is often hidden inside bootloaders, verification tools, and supplier dependencies, so it belongs in procurement, lifecycle planning, and risk reporting.
Manufacturing teams should expect PQC work to sit at the intersection of OT operations, PKI, and machine identity governance. The practical question is no longer whether quantum risk exists, but which controllers can actually absorb a change in trust anchors without forcing replacement or safety revalidation.
For practitioners
- Inventory firmware trust chains Document which controllers, gateways, and engineering tools rely on each signing key, certificate authority, and trust anchor.
- Test trust-anchor update paths Verify whether installed devices can accept new trust anchors, signature algorithms, and verifier software without replacement.
- Map supplier upgrade commitments Ask vendors for the exact release that supports PQC, the maintenance window required, and the support period after deployment.
- Separate tunnel protection from device trust Do not treat a PQC-protected gateway tunnel as proof that the controller behind it can verify secure boot or signed firmware.
- Embed PQC requirements in procurement Require new purchases to state how firmware verification, machine identity, and certificate renewal will be updated over the asset lifecycle.
Key takeaways
- Manufacturing PQC risk is dominated by the integrity of firmware signing, secure boot, and machine certificates, not only by encrypted traffic.
- Long-lived controllers and safety constraints make crypto-agility a lifecycle issue that spans suppliers, verification tools, and maintenance windows.
- The most useful near-term action is to inventory trust chains and prove which assets can accept new trust anchors before standards or timelines force a rushed decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-57 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Long-lived device trust and certificates can outlast current cryptographic assumptions. |
| NHI-02 — Secret Leakage | Exposed firmware keys or signing material create future forgery risk if cryptographic assumptions break. | |
| Recommendation — Inventory long-lived industrial credentials and plan rotation or replacement before cryptographic support expires. Scan firmware images and public release material for exposed trust material and revoke compromised signing paths. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article centers on key lifecycle planning across generation, distribution, migration, and retirement. |
| Recommendation — Define a key lifecycle plan that covers migration, renewal, and retirement for industrial trust anchors. | ||
| MITRE ATT&CK | TA0006;TA0011;TA0040 — Credential Access; Command and Control; Impact | The attack pattern involves obtaining trust material and using it to subvert industrial systems. |
| Recommendation — Map key-extraction and firmware-forgery scenarios to ATT&CK and hunt for trust-anchor abuse paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Industrial devices need controlled trust and authorization paths, not static assumptions. |
| Recommendation — Apply PR.AA-05 to industrial identity paths so only approved trust updates and signing actions are accepted. | ||
Key terms
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
- Trusted Firmware-A: Trusted Firmware-A is an open source reference implementation of secure firmware for Arm-based systems, covering the low-level code that starts a platform and hands off control to higher layers. Security teams review it for secure boot, privilege separation and attack surface in early boot code, where flaws can undermine device trust before the operating system loads.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Hybrid Cryptography: Hybrid cryptography uses a classical algorithm and a post-quantum algorithm together in one exchange. The goal is to preserve compatibility and confidence during migration while reducing dependence on any single cryptographic method that may later prove insufficient.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security and identity teams connect machine identity, secrets management, and lifecycle control to real-world programme decisions.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org