Software-defined vehicle cybersecurity: why data at rest is the next regulatory and operational risk 

In software-defined vehicles, cybersecurity increasingly depends on data at rest (the firmware, certificates, keys, and logs stored inside the vehicle), not just data in motion. Regulations including UN R155, ISO/SAE 21434, GB 44495-2024, and the EU Cyber Resilience Act now shape how that stored data is protected, validated, and recovered, and encryption alone does not deliver transactional integrity, predictable recovery, auditable failure modes, provable erasure, or protection from silent corruption. Tuxera builds purpose-built, automotive-grade storage software for exactly these guarantees.

As software-defined vehicles take on more connectivity, autonomy, and OTA complexity, attention is expanding from the network to include the storage layer as an under-examined attack surface, and regulatory expectations are expanding with it.

This article covers:

• SDV cybersecurity has a blind spot: Much of the public discussion centers on data in motion. The protections for data at rest (firmware, certificates, credentials, logs) are equally consequential, but get less narrative attention.
• Regulation is catching up: UN R155, ISO/SAE 21434, and the EU Cyber Resilience Act increasingly shape how vehicle software and stored data are protected, validated, and recovered.
• Encryption isn’t enough: It secures confidentiality, not transactional integrity, predictable recovery, auditable failure modes, or detection of silent corruption. Those properties reside in the storage stack.
• Storage is strategic, not background: Purpose-built automotive-grade storage software is becoming a defensibility layer for OEMs, not a commodity.

The overlooked layer in SDV cybersecurity

Recent automotive recalls tied to failed OTA updates and software faults point to a quieter problem: the data stored inside the vehicle. Not breached networks. Data at rest, failing under conditions the architecture wasn’t built to handle.

In April 2022, a software logic fault in the skid-control ECU led Toyota to recall approximately 458,000 vehicles. More recently, a failed over-the-air update briefly affected braking on the Volvo XC90 (May 2025), resolved through a follow-up OTA. These were software and update-logic faults rather than pure storage failures, but they show how directly vehicle behavior now depends on the integrity of what is written to, and read from, the vehicle.

Most SDV cybersecurity work focuses on data in motion: encrypted communications, secure OTA pipelines, hardened gateways. Those protections matter. But they leave an open question: what protects the data at rest inside the vehicle?

SDVs generate and retain enormous volumes of embedded data: firmware images, security certificates, authentication credentials, diagnostic logs, AI model artifacts, regulatory records, and personal and biometric data from in-cabin systems. This data validates secure boot, confirms update authenticity, and supports UN R155 compliance, and it also falls under GDPR. If it cannot be trusted, retained, or erased on demand, the cybersecurity architecture above it weakens.

Why integrity is getting harder to uphold

Continuous connectivity, ADAS, EV platforms, and frequent OTA updates push flash write activity well beyond legacy ECU levels. Vehicles also experience abrupt power-down events as part of normal operation: every key-off, every 12 V dropout.

Traditional ECUs see flash write loads ranging from near-zero to a few MB per day. They persist small parameters such as diagnostic trouble codes, calibration values, and counters, not data streams. As functions consolidate into domain controllers and especially central high-performance computers, that climbs to the order of several to tens of GB per day, driven by OS logging, telemetry, OTA staging, and ADAS event capture. Once physical AI data-flywheel workloads enter the picture, another order of magnitude is easily within reach.

Without deterministic, fail-safe storage behavior, embedded data drifts, corrupts, or silently desyncs. Many of these artifacts at rest (signed firmware images, certificate revocation lists, audit logs, and key material) are themselves cybersecurity controls, so a storage failure becomes a security failure, not merely a reliability one. (Functional safety is a related but separate discipline.) That’s not a technical inconvenience. A compromised file system weakens compliance evidence, expands recall and warranty exposure, and creates lasting brand risk.

The economics reinforce the point. Traditional recalls run on the order of $500 to $2,000 per vehicle, while OTA remediation can cost under $100 per GB delivered, far cheaper per fix, yet at fleet scale the cumulative exposure can still reach into the billions.

Regulation is reaching the storage layer

UN R155 mandates lifecycle cybersecurity management. ISO/SAE 21434 requires secure-by-design engineering. The EU Cyber Resilience Act sets horizontal obligations for products with digital elements; vehicles are largely carved out today, but that carve-out is conditional on equivalence, and ecosystem parts (aftermarket, diagnostics, EV charging, apps, and backends) already fall in scope.

This is global, not regional. China has aligned automotive cybersecurity regulation with UN R155, including the mandatory GB 44495-2024 standard, alongside the Data Security Law and PIPL. Japan and South Korea have adopted UNECE cybersecurity regulations. NHTSA continues to expand U.S. expectations on software integrity and supply chain security.

And encryption alone doesn’t close the gap. Secure storage in an SDV needs five things at once:

• Transactional integrity: writes complete cleanly or don’t happen.
• Predictable recovery: power loss can’t leave the file system undefined.
• Auditable failure modes: when something fails, evidence is preserved. If power drops mid-write, the file system should leave a traceable, logged transaction rather than a silently truncated file; a journaling or copy-on-write design can prove afterward what state it was in.
• Resistance to silent corruption: a flipped bit in a stored certificate or calibration table, whether from read disturb or a partial program, must be caught rather than absorbed. End-to-end checksums, ECC, and metadata checksums are the defenses; otherwise, corruption only surfaces when secure boot or an audit fails.
• Provable erasure: key material and personal data can be verifiably destroyed, despite the flash wear-leveling and FTL remapping that otherwise leave “deleted” data readable on the NAND.

Many legacy embedded file systems weren’t engineered for this combination. Purpose-built automotive-grade storage software, built for flash behavior, deterministic performance, and safety processes, is becoming a regulatory defensibility layer, not a commodity.

The question worth asking now

As regulation tightens across Europe, China, North America, and Asia-Pacific, the question for automotive organizations is direct: Does our storage architecture provide the deterministic integrity, recoverability, and traceability the SDV era now requires?

In software-defined vehicles, long-term cybersecurity confidence comes down to one capability: the ability to trust the data stored inside the vehicle.