Your Car May Outlive Its Encryption: Why Automakers Must Prepare for the Quantum Era

Abstract

Key Points at a Glance

1. Your Car Is a Rolling Cryptographic System

Consider a vehicle rolling off the production line in 2026. It may remain on the road until 2041 — a period that overlaps with many planning horizons for quantum-risk migration. Unlike a web server that can be patched overnight, this vehicle's cryptographic infrastructure must remain secure for its entire operational life, across environments the manufacturer cannot fully control.

Automotive cryptography is far more pervasive than most engineers realise. It is not limited to the infotainment system's TLS connection. Every modern vehicle relies on cryptographic primitives across a wide range of subsystems. Public-key components based on RSA, Diffie-Hellman, or elliptic-curve cryptography are directly vulnerable to future large-scale quantum attacks, while symmetric primitives such as AES mainly require larger security margins.

A simple analogy is useful: vehicle cryptography is the lock-and-key system for the car's software. If the lock may become breakable in ten years but the car stays on the road for fifteen years, the manufacturer needs a way to replace the lock before it fails.

The scope of exposure is substantial. As we explored in our analysis of PQC on constrained IoT devices, embedded systems face unique challenges when transitioning to post-quantum algorithms — but automotive ECUs are generally better resourced than typical IoT sensors, making the transition technically feasible if planned early.

2. R155 & R156: The Compliance Reason This Matters

UNECE Regulation No. 155 requires every vehicle manufacturer to establish, implement, and maintain a Cyber Security Management System (CSMS) covering the entire vehicle lifecycle — from concept and development through production and post-production ^[1]. Regulation No. 156 complements this by mandating a Software Update Management System (SUMS) that ensures all updates — especially over-the-air (OTA) — are secure, authentic, and traceable ^[2].

Critically, R155 is risk-based, not prescriptive. It does not name specific algorithms like "RSA" or "ECDSA." Instead, it requires manufacturers to assess evolving threats and implement proportionate mitigations. The regulation's Annex 5 lists threat categories including "manipulation of server communications," "data extraction from vehicle systems," and "use of compromised code" — all of which are directly relevant to quantum-capable adversaries.

Since July 2024, the European Union has applied these requirements broadly to new vehicles, not only to newly approved vehicle types ^[1][2]. The consequence of non-compliance is straightforward: without acceptable cybersecurity and software-update management evidence, type approval and market access are at risk.

While R155/R156 set the legal framework, the engineering implementation is guided by ISO/SAE 21434 (cybersecurity engineering) ^[3] and ISO 24089 (software update engineering) ^[4]. These standards provide the process framework into which quantum-threat analysis should be inserted, especially during threat analysis and risk assessment (TARA) and software-update planning.

3. Where Quantum Risk Enters the Vehicle

The quantum threat to automotive systems is not a single, monolithic risk. It manifests differently across subsystems, each with distinct timing requirements, impact profiles, and mitigation strategies. We identify four primary attack scenarios:

The harvest-now, decrypt-later scenario is especially relevant for connected vehicles. Modern cars transmit telemetry to cloud backends: GPS traces, driving behaviour, voice commands, and diagnostic data. If this traffic is protected using quantum-vulnerable key establishment and retains long-term sensitivity, an adversary recording it today may be able to exploit it later — creating privacy and lifecycle-security concerns under GDPR and R155.

4. Which Post-Quantum Algorithms Fit Which Automotive Use Case?

NIST finalised its first post-quantum standards in August 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for lattice-based digital signatures, and SLH-DSA (FIPS 205) for stateless hash-based signatures ^[5][6][11]. The question for automotive engineers is where these algorithms fit, which use cases require hybrid transition strategies, and which parts of the vehicle stack must remain algorithm-agile. Different automotive subsystems have different constraints:

V2X is one of the hardest migration targets. Vehicle-to-everything communication has strict latency and bandwidth constraints for safety-critical messages. ML-DSA-44 signatures are 2,420 bytes, compared with 64 bytes for a raw ECDSA P-256 signature, before protocol and certificate overheads are counted ^[6]. On congested 5.9 GHz channels, this overhead matters. Production-scale PQC V2X profiles are therefore not mature enough to treat as a drop-in replacement today; they require dedicated certificate, message-format, and congestion-control work.

5. Crypto-Agility: The Ability to Replace the Lock

Crypto-agility — the ability to swap cryptographic algorithms without hardware replacement or full reflash — is the single most important architectural prerequisite for quantum readiness. Under R155's lifecycle risk management model, a manufacturer must be able to respond to evolving threats. If the cryptographic layer is hardcoded into silicon, that response capability does not exist.

In practice, crypto-agility requires algorithm-agnostic key stores, modular cryptographic libraries, certificate format flexibility, and OTA infrastructure capable of deploying algorithm updates. AUTOSAR's Crypto Service Manager provides a useful abstraction point for standardized access to cryptographic functions, but abstraction alone is not enough: the underlying crypto drivers, key storage, certificate formats, and hardware accelerators must also support the migration path ^[12]. Many deployed automotive security architectures were designed around fixed classical algorithms, which can limit PQC migration options.

Semiconductor vendors are beginning to publish PQC roadmaps and software or hardware enablement plans, but public information on production-qualified automotive PQC support remains uneven. This creates a transition gap: vehicles produced before PQC-capable security hardware is widely deployed will depend heavily on software-based crypto-agility, updateable middleware, and backend-side migration planning.

6. The Regulatory Timeline: When You Need to Act

The convergence of regulatory deadlines and quantum-threat timelines creates a narrow window for action. Here is how the key milestones align:

The message is clear: a vehicle entering production in 2027 may need to remain cryptographically maintainable until around 2040. That means the cryptographic decisions being made right now — in platform architecture, security-hardware selection, and supplier requirements — will determine whether a manufacturer can keep lifecycle risk within an acceptable R155 posture through the quantum transition. For more on BSI-aligned migration, see our BSI-compliant PQC analysis and SMB migration roadmap.

7. A Practical Migration Roadmap

Based on the regulatory timeline and technical constraints outlined above, we recommend a four-phase approach for OEMs and Tier 1 suppliers:

The cost of acting late is high. Certificate rotation, algorithm migration, and re-signing across a large vehicle fleet is a multi-month, multi-team operation — exactly the kind of exercise that R155 is designed to prevent from becoming an incident response scramble.

Further Reading

The convergence of UNECE R155/R156 lifecycle requirements and quantum-threat timelines means automotive PQC migration is moving from theoretical cryptography into practical risk management. It is not yet a direct legal mandate, but for long-lived connected vehicle platforms it is increasingly difficult to ignore. The window for proactive architecture decisions is 2026–2028; after that, hardware and platform lead times may narrow the available migration options.

For deeper dives into the technologies discussed here, explore our related articles:

• Code Signing Crisis: Improving Supply Chain Security Before 2030
• The Quantum Clock Is Ticking: What is Harvest-Now, Decrypt-Later?
• PQC on the Edge: Can IoT Handle Post-Quantum Keys?
• Hybrid TLS Key Exchange: X25519 + ML-KEM-768
• BSI-Compliant Post-Quantum Key Exchange
• TLS 1.3: Quantum Vulnerabilities and Hybrid Defences

How to Cite This Article

@misc{pqcryptography_pqc_unece,
  author       = {{PQCryptography.de}},
  title        = {Your Car May Outlive Its Encryption: Why Automakers Must Prepare for the Quantum Era},
  year         = {2026},
  month        = apr,
  day          = {25},
  url          = {https://www.postquantumcryptography.de/publications/pqc_unece.html} 
}

References

1. UNECE: UN Regulation No. 155 — Cyber security and cyber security management system. https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155
2. UNECE: UN Regulation No. 156 — Software update and software update management system. https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156
3. ISO/SAE 21434:2021: Road vehicles — Cybersecurity engineering. https://www.iso.org/standard/70918.html
4. ISO 24089:2023: Road vehicles — Software update engineering. https://www.iso.org/standard/77796.html
5. NIST FIPS 203 (Final): Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM). https://csrc.nist.gov/pubs/fips/203/final
6. NIST FIPS 204 (Final): Module-Lattice-Based Digital Signature Standard (ML-DSA). https://csrc.nist.gov/pubs/fips/204/final
7. NSA: Commercial National Security Algorithm Suite 2.0 and Quantum-Resistant Algorithms FAQ (software & firmware signing milestones for National Security Systems). https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
8. BSI (and 17 EU member states): Joint statement on transitioning to post-quantum cryptography (Nov 2024). https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/PQC-joint-statement.pdf
9. ETSI: Quantum-Safe Cryptography and Security guidance, including migration and hybrid deployment considerations. https://www.etsi.org/technologies/quantum-safe-cryptography
10. Google Quantum AI. (2026). Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities. See our independent analysis.
11. NIST FIPS 205 (Final): Stateless Hash-Based Digital Signature Standard (SLH-DSA). https://csrc.nist.gov/pubs/fips/205/final
12. AUTOSAR: Specification of Crypto Service Manager. https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SWS_CryptoServiceManager.pdf