A common question that keeps surfacing in automotive cybersecurity is:
“Should production vehicles rely on a Secure Element (SE) or a Trusted Platform Module (TPM) for OTA-signed firmware updates?â€
The short answer is that the question itself is slightly misleading, SE and TPM both operate in different domains and confusing the two leads to architectural gaps.
- SE protects cryptographic keys inside the vehicle and
- TPM is typically used in Linux-based automotive platforms such as IVI and telematics ECUs to establish secure, hardware root of trust.
In practice, both address different parts of the problem, and neither is sufficient alone. Moreover, along with SE and TPM, most MCU-based automotive ECUs integrate an HSM to safeguard signing keys, while high-performance SoCs may include a Trusted Execution Environment (TEE) that enforces policy update.
These overall form the baseline of in‑vehicle trust and are central to any OTA architecture. This article will not only cover the differences between SE and TPM but also get into detail to help you understand what OTA security requires.
What Production Vehicles Actually Use
Current production vehicles typically use one of three patterns.
The dominant design pairs an HSM with a TEE, some programs add an SE with HSM and TEE for long‑duration key protection, especially in connected vehicle and digital key systems. Another TPM and TEE combinations are also used but remain rare, largely appearing in PC‑derived or experimental platforms.
However presently the adoption of SE in automotive is real and growing, especially in connected vehicle security and digital key systems. This is generally because TPM 2.0, was originally designed for PC platforms and its use in automotive is limited for three reasons:
- ECUs already have HSMs, providing secure key storage, crypto acceleration, secure boot, and secure debug.
- The automotive software stack does not map well onto TPM abstractions.
- Cost and integration complexity make TPM a difficult fit for constrained ECU environments.
Real Automotive Production Architecture
Figure 1: Realistic production architecture of vehicle-side and backend-side security components.
A realistic production architecture distributes responsibilities clearly across vehicle and backend domains:
| Vehicle Side | Backend Side |
|
|
What OTA Security Actually Requires?
Real vehicle programs need more than protected keys. OTA security must support a full trust and lifecycle model:
For this, the challenge is enforcing trust across the vehicle’s entire operational life, not merely storing credentials.
While a Secure Element (SE) provides tamper‑resistant storage, protects OEM root keys, maintains secure counters, and executes isolated cryptographic operations. It is suitable for long‑duration key protection and resisting physical extraction. However, it does not enforce system‑level update policy; firmware validation rules and state transitions must be managed elsewhere.
On the other hand, a Trusted Platform Module (TPM 2.0) adds measured boot via PCRs, attestation capabilities, secure key generation, and standardized identity flows. It supports backend integrity checking and device authentication. Still, update logic, versioning, manifest validation, rollback rules lives outside the TPM.
The Operational Gap:
Both the SE and TPM anchor trust but don’t control how OTA updates are validated or applied. Production OTA workflows require:
- secure execution of validation logic,
- update‑metadata checks,
- policy enforcement,
- lifecycle state management, and
- controlled access to crypto operations.
The Role of TEE:
Modern automotive SoCs increasingly rely on Trusted Execution Environment (TEE) to execute the update policy itself. A Trusted Application inside the TEE can verify firmware signatures using SE‑ or TPM‑protected keys, to enforce anti‑rollback, validate manifests, manage lifecycle states, and isolate update logic from the rich OS. The TEE becomes the enforcement layer that SEs and TPMs lack.
This results in a layered, production‑grade architecture in which:
- The SE protects root keys and counters.
- The TPM provides attestation and measured boot.
- The TEE, via a Trusted Application, executes policy and lifecycle control
Final Note
Automotive cybersecurity in production vehicles isn’t about picking a single component is about designing a layered architecture where each security element supports a specific part of the trust model.
Viewed from an OTA perspective, this means the architecture must be evaluated end‑to‑end. This includes, the OEM signing infrastructure and backend HSMs, device attestation and provisioning, firmware verification, anti‑rollback, and lifecycle state transitions inside the vehicle. Additionally, compliance with ISO/SAE 21434 and UNECE R155/R156 reinforces this systems‑level view and neither standard can be satisfied by securing a single component in isolation.
