Automotive crypto agility is becoming a practical requirement for software-defined vehicles, whose electronic control units (ECUs) may remain in service for up to 15 years while cryptographic standards continue to change. In this Elektor TV clip from Elektor Academy Pro’s Post-Quantum Cryptography conference, Dr. Claude-Pascal Stöber-Schmidt of IAV explains why security software must be as updatable as the vehicle functions it protects. The timing problem echoes an earlier Elektor clip on migration planning: Long-lived embedded systems have to prepare before the quantum threat becomes practical.

Automotive Crypto Agility on Existing ECUs

Current and near-term automotive microcontrollers often accelerate established cryptographic algorithms in fixed hardware. That is fast, but the accelerator cannot acquire support for an entirely different algorithm after the chip has been manufactured. IAV’s approach, documented in its open-source code repository, is a portable software layer designed for constrained microcontrollers and integration with AUTOSAR Classic, allowing cryptographic drivers to be replaced or extended without replacing the complete ECU.

The point is not to calculate everything in software forever. It is to prevent the chip’s original hardware design from becoming the sole authority over which cryptography the vehicle can use. That distinction affects secure boot, signed firmware updates, key establishment, vehicle-to-cloud links, and other paths that must remain trustworthy long after the car has left the factory.

What the NIST Portfolio Actually Contains

Stöber-Schmidt discusses five schemes evaluated in IAV’s work: ML-KEM and HQC for key encapsulation, plus ML-DSA, FN-DSA, and SLH-DSA for digital signatures. Their standardization status is not identical. NIST’s current project page lists finalized standards for ML-KEM, ML-DSA, and SLH-DSA. Falcon has been selected and is being standardized as FN-DSA, while HQC was selected for standardization in March 2025. The practical portfolio therefore contains three finalized FIPS standards and two selected algorithms still moving through standardization, rather than five equally finished standards.

That distinction reinforces the case for automotive crypto agility. Algorithms, parameter sets, implementation guidance, and certification targets do not necessarily change at the same pace. A system designed around one permanently fixed cryptographic block can be fast on day one and awkwardly obsolete years later.

Automotive Crypto Agility Is an Architecture Problem

IAV’s extensible design separates platform-independent algorithm code from the wrapper used by a particular software architecture. The implementation covers the post-quantum schemes discussed in the clip and provides example code for integration. The harder work goes beyond making the code compile: Automotive deployments need bounded memory use, acceptable execution time, high code quality, predictable behavior, and resistance to implementation-level attacks.

The useful takeaway is blunt. A connected vehicle cannot depend entirely on a cryptographic accelerator frozen when its microcontroller was taped out. Hardware acceleration still has a place, but the system also needs an updatable route for algorithms the chip designers could not foresee. Otherwise, the software-defined vehicle becomes cryptographically hardware-defined at exactly the wrong moment.