PQC for Automotive

What PQC for Automotive means

Post-quantum cryptography (PQC) uses cryptographic constructions intended to resist attacks from future large-scale, fault-tolerant quantum computers. The underlying concern is that such computers could efficiently solve the mathematical problems on which today’s asymmetric public-key cryptography relies. PQC is therefore the primary mitigation described in the cited evidence: migrate to cryptography based on problems that quantum computers cannot solve efficiently. The practical objective is not merely confidentiality. Automotive organizations must also protect identity, authentication, digital signatures, code signing, certificates, secure updates, network sessions, and the integrity of commands and sensor data.1

For an automotive enterprise, scope extends across vehicle programs and embedded components, manufacturing and industrial control systems, enterprise IT, operational technology, product-development environments, supplier and cloud services, network protocols, cryptographic libraries, hardware, firmware, PKI, and applications. NIST’s transition material explicitly identifies network protocols and security technology standards, software libraries, cryptographic hardware, PKI and infrastructure components, and IT applications and services as migration areas. Applications may need changes to encryption, digital signatures, and key exchange, including code refactoring, testing, protocol and library compatibility work, and accommodation of changed key sizes and performance.2

Why the automotive sector should act now

The quantum threat is future-facing, but migration is a global-scale change to IT and requires preparation before every affected asset can be replaced. The UK National Cyber Security Centre states that organizations should be beginning or continuing preparation now, most effectively as part of broader cybersecurity uplift when systems are replaced. The cited NIST transition material also identifies protection against “harvest now, decrypt later” attacks as a reason to prioritize quantum-resistant key-establishment schemes, particularly in interactive protocols such as TLS and IKE. Automotive data, design information, credentials, certificates, and operational information may have confidentiality periods that extend beyond a system’s immediate deployment horizon.12

Automotive risk is also an integrity and safety concern. In industrial control contexts, sensor data may not need strong confidentiality protection in every case, but its integrity can be critical because faulty readings or commands can lead to control-system failures. Remote logins into ICS IT zones therefore need quantum-secure channels, and wireless field OT devices and sensors need explicit consideration. The same reasoning applies to vehicle and manufacturing trust chains: an organization should identify where forged software, firmware, machine identities, commands, or certificates could affect safety, availability, production, or customer trust.1

• Long-lived confidential information that could be collected now and decrypted later.
• Software and firmware signing, certificate validation, and update mechanisms.
• Remote access into enterprise, vehicle-support, plant, and ICS environments.
• Network protocols and key establishment used by connected services and OT.
• High-impact systems whose compromise could affect safety, production, availability, or essential operations.
• Legacy, embedded, proprietary, or supplier-controlled components with limited upgrade paths.

A practical automotive PQC operating workflow

A defensible program begins with a cross-functional quantum-readiness team. The cited CISA, NSA, and NIST guidance recommends establishing a project management team to plan and scope migration, then performing proactive cryptographic discovery. For automotive organizations, that team should connect product security, enterprise security, OT and plant engineering, software and firmware engineering, procurement, legal or compliance stakeholders, safety and reliability functions, architecture, and supplier management. Its roadmap should identify what will change, when it will change, dependencies, expected costs, evidence requirements, and accountable owners.3

Discovery should produce more than a list of algorithms. Record where cryptography is used, the protocol or application, the asset and owner, whether it is custom-built or commercial off-the-shelf, the data or function protected, the certificate and key lifecycle, supplier and cloud dependencies, upgrade method, physical-access requirements, operational constraints, and the consequence of failure. The cited fact sheet specifically calls for visibility across IT and OT systems and recommends discovery tools for network protocols, end-user assets, servers, applications, and associated libraries. Correlate each finding with data criticality and outside access so that prioritization reflects exposure as well as technical presence.3

Prioritization should be risk-based. Give precedence to high-impact systems, ICSs, and systems with long-term confidentiality or secrecy needs. Custom-built products, especially older systems, may require the greatest effort. For COTS products, the organization should obtain each vendor’s quantum-readiness roadmap, delivery timing, upgrade path, and expected cost. Cloud-hosted products require the same engagement with cloud service providers. Treat this as IT/OT modernization: replacement, maintenance, segmentation, lifecycle planning, and security uplift can be coordinated rather than managed as isolated cryptographic projects.3

The implementation sequence should then move from controlled pilots to staged production adoption. Select representative applications, protocols, PKI paths, plant zones, and device classes. Establish acceptance criteria for security, interoperability, latency, memory, bandwidth, certificate size, update duration, availability, rollback, and operational safety. Keep a documented exception process for assets that cannot yet migrate, with compensating controls, a responsible owner, a target decision date, and a reassessment trigger. This makes uncertainty visible instead of allowing legacy cryptography to become permanent by default. [claim-053

Where migration affects automotive architecture

Vehicle and product architectures can contain cryptographic functions in embedded software, firmware, gateways, diagnostic channels, update systems, component identities, supplier interfaces, and connected services. The cited evidence does not prescribe a vehicle-specific algorithm profile, so organizations should avoid treating a generic algorithm substitution as an approved automotive design. Instead, map trust relationships and cryptographic dependencies, then test the complete chain: signing authority, certificate issuance, boot or update verification, transport protection, device authentication, service authorization, and recovery.2

Manufacturing introduces a parallel IT/OT architecture. Industrial control networks commonly separate OT and IT zones with a DMZ firewall. Remote logins over the internet must be secured, while wireless field devices and sensors need protection appropriate to their integrity and control role. Industrial IoT devices create additional migration challenges when they are resource-constrained, not upgradeable, difficult to service, embedded in larger products, designed not to be replaced, or dependent on proprietary or not-yet-compatible protocols. Internet-connected devices can also provide an entry point into control networks and then into the ICS enterprise IT zone through the DMZ.1

Enterprise PKI migration is a foundational dependency. A large enterprise may need a new PQC root of trust and new certificates for machines and sometimes users. A parallel PKI can operate alongside the traditional PKI during a staged migration; a one-step change may be possible only in tightly controlled environments. During coexistence, protocols such as TLS and IKE must negotiate the intended certificates and cryptographic options. Plan certificate issuance, trust-store updates, revocation and recovery, device enrollment, offline or physically serviced assets, and retirement of legacy trust paths.1

Crypto agility should be an architecture requirement. NIST CSWP 39 Update 1 defines crypto agility as the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. In automotive terms, this means separating cryptographic policy and implementation from business or control logic where feasible, maintaining controlled configuration and inventory, supporting tested algorithm and certificate changes, and designing update and rollback procedures that do not create unsafe or unavailable states.4

Hybrid cryptography, compatibility, and transition risk

Backward compatibility and interoperability are crucial during transition. NIST’s cited draft material allows for hybrid key-establishment modes and dual signatures when suitably combined with an approved scheme, while leaving each application to weigh implementation cost, performance reduction, and engineering complexity. Hybrid approaches can help accommodate sector requirements or legacy dependencies, but they add complexity to architectures and implementations, which can increase security risk and cost. They are generally expected to be temporary measures leading to tools that use only PQC algorithms.2

Automotive teams should therefore document the purpose and exit condition of every hybrid deployment. Test negotiation behavior, certificate chains, message and packet sizes, memory use, timing, failure handling, logging, downgrade resistance, and interoperability with suppliers and service providers. Do not assume that a nominally available cipher suite is actually being used. The NCSC evidence recommends checking that systems use standardized PQC cipher suites rather than falling back to traditional cryptography, followed by a rigorous assurance process.1

Supplier, cloud, and lifecycle governance

Supplier management is central because automotive organizations depend on component manufacturers, software vendors, COTS products, cloud services, protocol providers, and maintenance partners. Ask each supplier which cryptography is used, where it is embedded, how it is inventoried, which products are affected, when updates or upgrades will be available, how upgrades will be installed, what testing evidence will be cited, and what costs or licensing changes are expected. The joint CISA, NSA, and NIST guidance specifically calls vendor engagement critical and asks roadmaps to state when and how COTS vendors will enable PQC.3

Contractual and lifecycle controls should preserve the ability to update cryptography over the product’s support period. Include inventory and disclosure obligations, vulnerability and incident notification, maintenance windows, certificate and key management responsibilities, interoperability testing, end-of-support treatment, and evidence of fallback behavior. Procurement should distinguish between “vendor intends to support PQC” and a tested, deployable, supportable capability. For cloud-hosted products, record the provider’s roadmap and the configuration or application changes required to enable PQC.3

Coordinate cryptographic replacement with vehicle, plant, and infrastructure maintenance wherever possible. The NCSC evidence notes that changes to physical infrastructure require significant planning and should, as far as possible, coincide with other maintenance and improvements. This is particularly important for devices that require physical interaction, are installed in difficult locations, or cannot be replaced without production or service disruption.1

Testing, assurance, and useful measures

Testing should cover both cryptographic correctness and system behavior. Validate algorithm and protocol implementation, certificate paths, key establishment, signatures, update and recovery workflows, access control, interoperability, performance, resource consumption, availability, and the effect of failure on safety and operations. For OT and embedded devices, test under realistic bandwidth, memory, processor, latency, maintenance, and physical-access constraints. Use staged pilots and independent security review where the design’s complexity or risk warrants it.2

Assurance must verify actual behavior rather than relying on configuration intent. Inspect negotiated protocols and certificates, confirm that systems do not silently fall back to traditional cryptography, test rollback and exception paths, and retain evidence tied to asset, software version, supplier, environment, and test result. The cited NCSC guidance recommends metrics that quantify how many software clients use PQC and identify those that do not; such measures show migration progress, reveal remedial work, and support a decision about when traditional algorithms can be disabled.1

• Percentage of discovered cryptographic dependencies with an owner, criticality rating, and migration disposition.
• Percentage of high-impact systems, ICS assets, and long-term-confidentiality data flows with an approved migration plan.
• Percentage of clients, services, devices, and certificate paths actually using the intended PQC or approved transition configuration.
• Number and age of exceptions, including assets that cannot be upgraded and their compensating controls.
• Supplier coverage: vendors with a documented roadmap, tested update, support commitment, and cost estimate.
• Number of failed interoperability, performance, fallback, rollback, or recovery tests and the time to remediate them.
• Readiness of PKI roots, certificates, trust stores, enrollment, revocation, and physical-service procedures.

Practical next steps for an automotive security team

1. Assign an accountable quantum-readiness program team spanning product security, enterprise IT, OT, engineering, procurement, suppliers, cloud, and relevant safety or reliability functions.
2. Define scope across vehicles and embedded products, plants and ICS, enterprise applications, network protocols, PKI, software and firmware signing, suppliers, and cloud services.
3. Run cryptographic discovery across IT and OT, then attach each finding to an asset, owner, data or function, criticality, lifecycle, supplier, upgrade path, and dependency.
4. Prioritize high-impact systems, long-term secrets, remote access, signing and update chains, ICS, and difficult-to-replace or internet-connected devices.
5. Request dated PQC roadmaps and deployment evidence from COTS, component, software, and cloud suppliers; include the results in procurement and lifecycle decisions.
6. Select representative pilots and establish interoperability, performance, security, integrity, safety, availability, rollback, and fallback acceptance criteria.
7. Design or improve crypto-agile interfaces, configuration, PKI migration, certificate lifecycle, update, monitoring, and exception processes.
8. Measure real adoption and fallback behavior, remediate gaps, and periodically refresh the plan as standards, implementations, product support, and sector guidance mature.

Conclusion

PQC for Automotive is a staged trust and resilience program spanning products, vehicles, factories, IT, OT, suppliers, and cloud services. The most defensible starting point is an owned cryptographic inventory linked to business, safety, integrity, confidentiality, and lifecycle risk. From there, prioritize high-impact and long-lived dependencies, engage vendors, build crypto agility, plan PKI and protocol coexistence, test actual behavior, and measure adoption. Hybrid mechanisms may help during transition but add complexity and need explicit exit criteria. Because the cited evidence includes evolving and draft material, preserve source status and version assumptions and revalidate the roadmap as standards and implementations mature.3421