Automotive security may be decided as much by the design of the chip as by the software running on it, according to an analysis of hardware security modules, or HSMs. These components are examined as part of the secure boot process and as hardware roots of trust, the starting points that establish which code and keys a vehicle system will accept.
The work is a qualitative, architecture-focused analysis intended to provide practical design insights. The supplied text reports no empirical participant or vehicle sample, and no quantitative comparison that ranks one design or measures a security gain.
Three ways to build the security boundary
The paper compares three broad ways of integrating an HSM into an automotive system-on-chip: dedicated coprocessor HSMs, security islands and firmware-based HSMs. The three patterns place the security boundary differently, which is why the analysis considers them in terms of separation, integration cost, flexibility and the size of the trusted computing base.
That tradeoff is not presented as a simple contest with one universal winner. The analysis sets separation, integration cost, flexibility and trusted-computing-base demands against one another, without an empirical ranking.
In production, the paper describes HSM functions as centered on startup trust, protection of long-term cryptographic assets, authenticated communication and diagnostic access.
The chain of trust starts before the operating system
The secure-boot model begins with an immutable boot ROM. Each stage verifies the next, creating a chain in which later software is accepted only after verification. An HSM may provide the verification engine, hold the root keys that begin the chain, or enforce the policies that decide whether an image is accepted.
The same boundary is used for key management. Keys are tied to hardware policies, raw export is generally prohibited, and lifecycle states govern their use during development, production, service and decommissioning. In this design, key handling and trust decisions stay inside HSM firmware, while application software and middleware remain outside the security-critical trusted computing base and raw key material is not returned.
The software-update process follows the same logic. The described over-the-air workflow covers secure download, staging, signature and policy checks, reboot activation, a fresh boot-time verification and anti-rollback protection. An update must therefore continue to pass the trust checks when it is installed and when the system starts again.
Software signing uses a hierarchy in which an OEM root key authorizes intermediate signing keys, and those intermediate keys sign firmware images. That separates the ultimate source of trust from the keys used to authorize individual images.
Protection still has a long list of weak points
The threat assumptions are broad. They include remote code execution, physical access, attacks aimed at backend systems or the supply chain, and software vulnerabilities over vehicle lifetimes that may exceed 15 years. These are qualitative threat assumptions, not measurements of how often any attack occurs.
An HSM does not make the rest of the system irrelevant. The analysis identifies side-channel leakage, fault injection, leakage through shared resources and bugs in HSM firmware as residual risks. It discusses countermeasures, but does not experimentally evaluate how effective they are.
The paper also describes practical constraints that can narrow the security boundary in production. Secure memory and processing capacity may be limited, real-time systems impose latency requirements, algorithms and key assumptions may be fixed, and integration errors can undermine the design. Some operations therefore remain outside the HSM.
The unanswered question is how these designs age
Looking ahead, the authors call for cryptographic agility and post-quantum readiness. Future HSM designs would need to accommodate changes in cryptographic algorithms and the demands of new key material over a vehicle's long service life.
They also call for scalable HSM isolation, key management and policy enforcement across zonal or centralized computing. The recommendations are prospective: the paper does not experimentally test how those designs perform.
Open questions include how real implementations compare in latency, silicon area, power, protected-memory capacity and attack resistance, and how systems handle algorithm migration, key rotation and post-quantum storage. The analysis also leaves unresolved how isolation and inter-domain communication should work in zonal and centralized systems.
Taken together, the paper is best read as a map of architectural choices and security responsibilities, not as evidence that one HSM model reduces attacks or failures in production vehicles. It does not demonstrate improved vehicle safety, establish that one architecture is best across vehicle platforms, or quantify latency, area, power or cost.
The supplied metadata labels the work an arXiv preprint, and the front matter reports no funding statement.
Paper data and sources
Original title: Automotive HSMs - Architectural Challenges and Security Implications
Authors: Krishna Teja Medam, Austin Bruce
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-25
DOI: Not available
Original paper · Full text