AUTOSAR HSM Integration: Why it is Essential and How it Works?

HSM integration in AUTOSAR refers to integration of AUTOSAR crypto stack with a secure hardware module. It safeguards cryptographic keys from being scraped, copied, or compromised and align with automotive cybersecurity regulations.

Ransomware is no longer a distant IT problem. As our vehicles are turning increasingly software-defined, it has already taken over the driver’s seat.

The 2026 Upstream Security report shows automotive cyber incidents rose nearly 50% in Q1 2025, with ransomware accounting for 44% of all incidents. While many of these target supply chains and back-end systems, the attack surface increasingly extends into the vehicle itself and at the heart of that exposure is how cryptographic keys are protected inside ECUs

In our previous article Cryptographic Keys and Their Role, we broke down the intricacies of these keys in SDVs today. And moving forward on the lines, the next question is: Where and how should we anchor these keys to ensure their security?

In this article, we will answer why Hardware Security Module (HSM) is the right fit to anchor cryptographic trust. Further, we will break down how it is embedded in the AUTOSAR stack with insights from our in-house expert.

Role of Hardware Security Module (HSM) in High Assurance Automotive Functions

Every ECU in a vehicle carries a different risk weightage. While a compromised seat adjustment module causes minor inconvenience, a compromised ADAS domain controller or V2X communication stack can lead to a serious safety event. Hence, the cryptographic protection each ECU needs, varies by the domain it operates in.

And this is where Hardware Trust Anchors (HTAs) play a key role. Software-based security in vehicles ensures some degree of protection but it has their own limitations, it can be overwritten, exploited at the application layer, or bypassed through a privileged software attack.

HTAs eliminate that exposure by moving the trust boundary into hardware. Cryptographic keys are generated, stored, and operated on inside the HTA itself. This prevents anything running on the host processor (i.e., applications, OS, or bootloader) from extracting them.

Generally, automotive ECUs use different forms of hardware trust anchors depending on cost, performance, and security requirements.

Cost-sensitive classic ECUs often rely on Secure Hardware Element (SHE), HSM-lite, or embedded HSM capabilities for symmetric cryptography, secure key storage, MAC generation, and secure boot. However, Secure Elements are also used where tamper-resistant credential storage and authentication are required; depending on the product, they may support both symmetric and asymmetric cryptography.

For richer Linux-based platforms such as infotainment, telematics, and gateways OEMs often use Trusted Platform Module (TPMs) for measured boot, attestation, device identity, and protected key storage.

For real-time AUTOSAR ECUs, integrated automotive HSMs are typically the preferred option. They are designed around ECU security use cases.

For a detailed breakdown of where each fit and where neither is sufficient alone, check out our article on SE vs TPM in Automotive OTA Security.

However, in AUTOSAR-based ECUs, the integration of HSMs goes through a complex process defined by the crypto stack.

How AUTOSAR Connects Software to the HSM

In an automotive program, every ECU comes from a different supplier. Each ECU is built on a distinct microcontroller with its own HSM and its own way of exposing cryptographic services.

Without a standardised abstraction layer, application software on each ECU communicates to the HSM directly through vendor-specific APIs. This works in isolation but breaks down the moment the application and cryptographic functions needs to run consistently across multiple ECU variants, microcontrollers, and supplier stacks.

AUTOSAR solves this with a standardised three-layer crypto stack that sits between the application software and the HSM hardware.

1. Crypto Service Manager (CSM)

CSM sits at the top and is the only layer the application interacts with. It receives cryptographic job requests (I.e., a signature verification, an encryption call, a MAC generation) and queues them to dispatch downward. The application never needs to know what hardware is underneath.

2. Crypto Interface (CryIf)

CryIf sits in the middle and acts as a routing layer. It maps each job coming from the CSM to the correct Crypto Driver Object based on pre-configured channel assignments. It also handles key ID translation between the application-facing reference and the actual hardware key slot.

3. Crypto Driver (CryDrv)

CryDrv sits at the hardware boundary. It has two variants– Hardware Crypto Driver (CryHw), which talks to the physical HSM, and Software Crypto Driver (CrySw), which handles software-based fallback operations. The HSM itself sits below this layer and is never accessed directly by anything above it.

Every cryptographic request in the ECU travels this path, and the result is communicated back up the same way. At no point does key material cross that hardware boundary and the host system only ever get the output. This abstraction makes cryptographic services portable across ECU variants and supplier stacks.

EVITA HSM Classification

The HSM under each ECU domain is fundamentally different and is classified based on the security requirements it serves. AUTOSAR uses the E-safety Vehicle Intrusion proTected Applications (EVITA) to define HSM capability in three tiers (Light, Medium, and Full).

1. EVITA Light is designed for cost-sensitive, low-complexity ECUs like body control modules, basic sensors, and actuator nodes. The cryptographic requirement in this tier is limited to to handle AES-based encryption and message authentication.
2. EVITA Medium covers gateway ECUs and domain controllers that handle both symmetric and asymmetric operations. This requires support RSA and ECC alongside moderate throughput requirements and broader key management needs.
3. EVITA Full is built for the highest-assurance automotive functions like powertrain controllers, ADAS units, and V2X stacks. It supports the complete cryptographic suite, hardware-accelerated asymmetric operations, scalable key storage, and full execution isolation from the host core.

This classification plays a critical role in practice. And therefore, identifying the EVITA tier your ECU domain requires, is the first concrete input the AUTOSAR crypto stack demands. Everything above it is shaped by what the underlying hardware can do.

CSM Queue Configuration

Once the EVITA tier is established, the next configuration layer is the CSM queue. Every cryptographic job the application submits does not go to the HSM immediately, it enters a queue inside the CSM first.

Each CSM queue maps to a CryIf channel, which in turn maps to a specific Crypto Driver Object on the hardware. This means engineers must configure the queue size, job priority, and CsmMainFunction timing based on the ECU’s expected cryptographic workload.

An EVITA Full domain running concurrent ADAS and V2X operations has a fundamentally different queue requirement than an EVITA Light body control module. Sizing both in the same manner, is a configuration mistake.

Moreover, this is also where the choice of how jobs are dispatched comes into picture.

CSM Dispatch: Direct API vs Job-Based API

The AUTOSAR CSM supports two modes to dispatch the CSM queues:

1. Direct API
2. Job-based API

The separation between cryptographic operations and key management is what drives this split. It allows an application to focus on the required cryptographic operation such as MAC calculation or verification while a key manager handles key provisioning during configuration setup.

Direct API is synchronous and straightforward to implement and debug. It is designed primarily for key management operations. It works like a simple function call where the application sends a request, waits for a response, and gets the result back. There is no job structure involved; the parameters go straight from the application down to the Crypto Driver. As it is synchronous and simple to trace, it works well for ECUs with low cryptographic workload and no strict timing requirements.

Job-based API is used mainly for cryptographic operations. Instead of passing parameters directly, the application packages everything the Crypto Driver needs into a job structure and hands it to the CSM. The CSM then routes it down through CryIf to the Crypto Driver. This approach supports both synchronous and asynchronous execution:

For EVITA Medium and Full domains, asymmetric operations like RSA and ECC are in play, and tasks have hard real-time deadlines. In such a scenario, synchronous dispatch blocks the caller for the duration of the HSM operation. In a powertrain or ADAS context, if the application is forced to wait on every cryptographic call, it risks missing task deadlines, triggering the watchdog, and resetting the ECU. Therefore, for such domains asynchronous calls are preferred.

Nevertheless, this choice between synchronous and asynchronous needs to be locked in early. Switching dispatch modes late in a program, after integration has already started, is expensive and often surfaces failures that are hard to trace back to the original decision.

Host HSM Communication

The AUTOSAR Crypto Driver does not directly communicate with the HSM. It relies on a vendor-supplied host driver that handles the low-level communication protocol between the host processor and the HSM.

This means the integration has two sides that must stay aligned:

1. The host side, where the AUTOSAR stack and its configuration live.
2. The HSM side, which runs its own firmware and its own internal configuration.

The HSM firmware defines what cryptographic operations the HSM exposes, how key slots are organised, and what the communication protocol looks like. The host driver then wraps that interface for the Crypto Driver to consume.

The point where both sides align is the preconfig file. The HSM side generates a preconfig file describing its internal configuration including key slot layout, supported algorithms, channel assignments. This file is loaded into the host-side AUTOSAR configuration to align the stack with what the HSM exposes.

If the HSM firmware is updated without regenerating the preconfig file, or a hardware change is not reflected on the host side, the two fall out of sync. This further causes the stack to not behave as expected at runtime.

This is also where vendor dependency becomes a real program risk. The HSM firmware binary is owned and released either by the silicon vendor or by third-party HSM firmware suppliers, depending on the microcontroller platform. When a vendor releases an update mid-program, it can invalidate the existing preconfig file entirely. Every ECU variant using that hardware then requires host-side configuration changes. Teams that skip this step rarely discover the gap in testing, but it surfaces during production.

Conclusion

Getting HSM integration right in AUTOSAR is not a one-time configuration task. The stack decisions made early in a program compound across the vehicle lifecycle. A misconfiguration that surfaces as an intermittent runtime failure at system integration is almost always traceable back to an architectural decision that was never revisited.

The engineering complexity is real, but it is manageable when approached with the right expertise at the right stage of the program. If you are working through HSM integration challenges on an AUTOSAR-based ECU or building a security architecture, we can help you. Check out our automotive cybersecurity capabilities.