PQC for Semiconductor Companies

What PQC means for semiconductor companies

Post-quantum cryptography means cryptography based on mathematical problems that quantum computers are not expected to solve efficiently. The threat addressed is primarily the future impact of large-scale, fault-tolerant quantum computers on public-key cryptography used to protect networks and other systems. PQC is therefore a migration of cryptographic mechanisms and their surrounding protocols, products, software, hardware, firmware, certificates, and operating processes—not simply the installation of a new algorithm. [c1]1

The semiconductor context broadens the scope. A company may rely on cryptography in chip-design and engineering environments, product firmware, secure-boot chains, software and firmware update signing, manufacturing systems, test equipment, enterprise applications, databases, communications, cloud services, remote administration, customer support, and supplier technology. The cited guidance specifically identifies digital-signature creation and validation, including software and firmware updates, as part of the inventory of quantum-vulnerable systems and assets. [c2]2

Why the transition should begin now

The immediate planning driver is the harvest-now-decrypt-later threat: adversaries can collect encrypted information now and seek to decrypt it when quantum technology matures. Sensitive information may retain value for many years, so delaying all preparation until a cryptographically relevant quantum computer exists could leave data exposed to a future decryption event. NIST’s initial public draft describes the transition as pressing for this reason. [c1]3

Migration also takes time. NIST’s November 2024 initial public draft notes that the historical journey from algorithm standardization to full integration into information systems can take 10 to 20 years. The duration reflects algorithm integration, product and service procurement, and integration into technology infrastructures. For a semiconductor company with long product lifecycles, distributed suppliers, embedded devices, and specialized manufacturing environments, this is a reason to establish discovery and planning capabilities before every implementation detail is settled. [c1]3

The standards landscape is also material to planning. The cited NIST draft states that NIST released three PQC standards: the Module-Lattice-Based Key-Encapsulation Mechanism in FIPS 203, the Module-Lattice-Based Digital Signature Algorithm in FIPS 204, and the Stateless Hash-Based Signature Algorithm in FIPS 205. The same draft is explicitly an initial public draft dated November 2024, so organizations should preserve that status and avoid treating every statement in it as a final implementation specification. [c1]3

How to prioritize semiconductor assets

A useful program begins with business consequences rather than an undifferentiated list of algorithms. CISA, NSA, and NIST advise prioritizing high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs. In semiconductor environments, that prioritization can include assets whose compromise could affect manufacturing continuity, product integrity, intellectual property, update trust, customer data, or safety-relevant operations. The precise ranking remains company-specific and must be established through risk assessment. [c4]2

Integrity deserves explicit treatment. In industrial control contexts, confidentiality of sensor data may not always require strong cryptographic protection, while integrity can be critical because faulty sensor readings or commands can cause failures. This distinction matters to semiconductor manufacturing and facilities environments: a migration plan should assess not only whether information can be decrypted in the future, but also whether forged commands, identities, certificates, firmware, or measurements could disrupt operations or undermine product trust. [c7]1

• Classify information and functions by confidentiality lifetime, integrity requirements, availability impact, and dependency on public-key cryptography.
• Give early attention to signing and validation paths for software, firmware, updates, certificates, and machine identities.
• Identify systems that cross IT, OT, manufacturing, laboratory, cloud, supplier, and customer boundaries.
• Record whether an affected device or product can be updated, requires physical service, is embedded in a larger product, or uses a proprietary or not-yet-compatible protocol.
• Separate confirmed facts from vendor projections, draft-standard dependencies, and assumptions requiring testing.

Build a cryptographic inventory and governance model

A cryptographic inventory is the foundation for a defensible migration plan. The joint CISA, NSA, and NIST guidance says an inventory of quantum-vulnerable technology and associated data criticality supports risk assessment and migration prioritization. It should provide visibility into how cryptography is used across IT and OT systems, including network protocols, end-user systems and servers, applications, and associated libraries. [c2]2

For semiconductor companies, inventory records should be connected to ownership and change processes. At minimum, the organization should be able to relate a cryptographic use to the product or service, hardware or software component, protocol, certificate or key purpose, data or function protected, lifecycle stage, supplier, deployment location, upgrade route, and validation evidence. The source set does not prescribe a particular inventory tool or schema; these fields are practical governance choices, not claims that a specific product capability exists.2

Governance should have a named project management team and should involve IT and OT procurement experts. The joint fact sheet recommends establishing a quantum-readiness project team and conducting proactive cryptographic discovery. Procurement participation is especially important because commercial off-the-shelf products and cloud services may determine when migration is technically available and what it will cost. [c2]2

A practical migration workflow

A semiconductor PQC program can be organized as a repeating sequence: govern, discover, assess, prioritize, engage, design, test, deploy, measure, and retire legacy support when justified. The sequence is not a claim that every company must use one formal methodology; it is a practical way to turn the cited recommendations into controlled work packages.3

1. Establish ownership and scope. Form a cross-functional team covering security, engineering, product, manufacturing, OT, infrastructure, procurement, legal or compliance stakeholders, and relevant business owners.
2. Discover cryptography. Identify quantum-vulnerable algorithms and dependencies in protocols, applications, libraries, servers, endpoints, products, firmware, certificates, signing systems, cloud services, and supplier technology.
3. Assess consequence and feasibility. Rank confidentiality lifetime, integrity, availability, exposure, product impact, upgradeability, performance constraints, and dependency on external providers.
4. Define migration patterns. Decide where a direct PQC transition, staged replacement, parallel PKI, or a temporary hybrid approach is appropriate, subject to applicable standards and independent security review.
5. Engage vendors and standards communities. Obtain product roadmaps, planned updates, configuration requirements, expected costs, supported protocols, and test materials; do not infer readiness from marketing language alone.
6. Test before broad deployment. Verify interoperability, key and signature handling, performance, resource consumption, certificate behavior, fallback behavior, recovery, monitoring, and operational procedures.
7. Deploy in controlled stages. Coordinate changes with maintenance windows and product or infrastructure refreshes, particularly where physical infrastructure or difficult-to-service devices are involved.
8. Measure use and close gaps. Confirm which clients, products, and channels actually use PQC, identify non-adopters, remediate exceptions, and decide when legacy algorithms can be disabled.

The workflow should be integrated with modernization rather than treated as an isolated cryptography project. The NCSC states that PQC migration is a global-scale change to IT and that it can be most effective as part of a broader cybersecurity uplift as systems are replaced. For semiconductor companies, normal product refreshes, manufacturing upgrades, infrastructure maintenance, and platform redesigns can provide controlled opportunities to remove dependencies and improve resilience. [c3]3

Crypto agility, PKI, and hybrid transition choices

Crypto agility is the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. That definition makes agility directly relevant to semiconductor products and their supporting lifecycle systems: it concerns the ability to change cryptographic mechanisms without redesigning every dependent component or interrupting essential service. [c9]4

Enterprise PKI migration illustrates the architectural scope. The NCSC describes a migration requiring a new PQC root of trust and new PQC certificates for network entities. A parallel enterprise PKI may operate alongside the traditional PKI for a period; in controlled environments, a single transition may be possible, but staged migration is more likely and requires protocols such as TLS and IKE to negotiate the certificates used. [c10]1

Hybrid key-establishment or dual-signature approaches may help preserve interoperability during transition. NIST’s draft says existing standards and guidelines accommodate such use when at least one component digital-signature algorithm is NIST-approved, and that NIST intends to accommodate hybrid key-establishment modes and dual signatures in FIPS 140 validation when suitably combined with a NIST-approved scheme. However, the same material emphasizes that hybrid solutions add implementation and architectural complexity, which can increase security risks and costs; they are typically expected to be temporary measures leading to PQC-only tools. [c11]3

Product, manufacturing, OT, and supplier considerations

Industrial and connected equipment create constraints that are particularly relevant to semiconductor operations and products. The NCSC identifies industrial IoT devices that may be resource-constrained, not upgradeable, difficult to service, embedded in larger products, not designed for replacement, dependent on proprietary communications, or based on protocols not yet compatible with PQC. Internet-connected devices can also provide an entry point into control networks and onward into enterprise IT zones through a DMZ. [c7]1

These limitations should change the planning question from “Which algorithm should we install?” to “What migration path is safe and serviceable for this asset?” Options may include a firmware or software update, replacement during a planned maintenance window, compensating controls for continued use, protocol gateway changes, redesign in the next product generation, or supplier escalation. The cited evidence does not establish that any one option is sufficient in every environment, so each choice requires system-specific risk assessment and testing.1

Vendor engagement is critical for commercial products and cloud-hosted services. CISA, NSA, and NIST recommend asking each COTS vendor when and how updates or upgrades will enable PQC and what costs are expected. For cloud-hosted products, organizations should ask providers about their quantum-readiness roadmaps and, once standards are available, how PQC will be enabled through configuration changes or application updates. [c4]2

Procurement requirements should therefore request roadmap dates, supported algorithms and protocols, update mechanisms, certificate and key-management behavior, fallback controls, performance information, lifecycle support, and evidence of testing. These are recommended questions for due diligence, not evidence that every vendor currently provides the requested capability. Supplier answers should be tracked as dated assumptions and revisited as standards and product implementations mature.23

Testing, assurance, and useful measures

Migration testing must verify more than service availability. The NCSC recommends additional tests to confirm that cryptography is performing as expected, including checking that systems use standardized PQC cipher suites rather than falling back to traditional cryptography. A rigorous assurance process should determine whether the migration and the broader cybersecurity uplift meet their goals. [c12]1

• Coverage: proportion of inventoried assets with an owner, criticality rating, migration disposition, and documented evidence.
• Adoption: number or percentage of software clients, products, services, or channels actually using PQC, with non-adopters identified.
• Exposure: count of high-impact or long-confidentiality assets still dependent on quantum-vulnerable cryptography.
• Supplier readiness: percentage of material COTS and cloud dependencies with a dated roadmap, tested update path, and cost estimate.
• Operational assurance: results of interoperability, performance, fallback, recovery, certificate, and update tests.
• Legacy reduction: approved exceptions and the conditions under which support for traditional algorithms may be disabled.

The strongest measures distinguish capability from use. A library installed on a server, a product roadmap, or a successful configuration change does not demonstrate that deployed clients negotiated PQC or that signing systems used the intended algorithm. Measurement should therefore combine inventory status, configuration evidence, observed protocol behavior, test results, and exception management. [c12]1

Limitations and immediate next steps

PQC migration is not a one-time algorithm swap. It involves dependencies among standards, protocols, applications, hardware, firmware, certificates, libraries, suppliers, cloud services, maintenance practices, and business priorities. The evidence also shows that standards and implementation guidance evolve: the NIST IR 8547 material cited here is an initial public draft, while the NCSC describes further guidance as technical standards mature. Plans should preserve version, status, date, and uncertainty rather than presenting a fixed universal timetable. c131

Start with actions that improve visibility and decision quality: appoint a cross-functional team; run cryptographic discovery; classify data and functions by impact and confidentiality lifetime; identify signing and PKI dependencies; prioritize high-impact, OT, and long-secrecy systems; contact COTS and cloud suppliers; and select representative systems for controlled testing. In parallel, build crypto-agility requirements into new products, infrastructure replacements, procurement, and architecture reviews. c2 [c9]24

Conclusion

For semiconductor companies, PQC is an enterprise, product, and operational-technology transition. The most defensible starting point is not a promise that every system can be changed immediately, but a governed inventory that reveals where quantum-vulnerable cryptography supports confidentiality, integrity, identity, signing, updates, and control. Prioritize long-lived and high-impact assets, engage suppliers early, design for crypto agility, test real use and fallback behavior, and measure progress through evidence. This approach acknowledges standards maturity and device constraints while creating a practical path toward reduced quantum risk. c1 c4124