Software quality is now a safety control in connected vehicles

At a glance

What this is: This is an analysis of how connected cars and software-defined vehicles are changing the testing problem, with Arxan Technologies arguing that software quality now affects safety, reliability, and user experience together.

Why it matters: It matters to security, IAM, and governance practitioners because vehicle software increasingly behaves like a connected platform, which raises questions about update integrity, ecosystem access, and control assurance across the supply chain.

By the numbers:

• Modern vehicles now ship with up to 100 million lines of software code, and that number is expected to climb in next-generation electric and autonomous vehicles.
• The global automotive software and electronics market is projected to reach around $462 billion by 2030.
• The in-vehicle apps market was valued at $62.6 billion in 2024 and is projected to reach $132 billion by 2034.
• 26% of drivers have downloaded more than five connected-car apps, and 1 in 10 have downloaded more than ten.

👉 Read Arxan Technologies' analysis of software quality in connected vehicles

Context

Connected vehicles are now software platforms with safety consequences, not just mechanical products with digital features. That shift changes the governance problem: quality, release control, and update assurance must keep pace with continuous delivery in environments where software defects can affect driver attention and operational reliability. The primary keyword, software quality in connected vehicles, is really about whether modern automotive systems can be tested and governed at app speed without losing control.

The article’s core point is that testing methods built around physical vehicles and local head units are too slow for OTA updates, multi-app dashboards, and fast-moving software-defined vehicle ecosystems. That creates a governance gap across the automotive stack, from the developer to the automaker, and it makes release assurance a shared responsibility rather than a final QA step. This is a broader cybersecurity and resilience issue, even though the article is not about identity in the narrow sense.

Key questions

Q: How should teams test software-defined vehicles without relying on physical cars?

A: They should move toward automated validation that covers OTA updates, OS versions, display variants, and rollback behaviour inside CI/CD pipelines. Physical vehicles can still support targeted checks, but they should not be the primary gate when release cadence is continuous. The goal is repeatable assurance before deployment, not manual confirmation after the fact.

Q: Why does multi-app infotainment create more governance risk?

A: Because every additional app adds dependencies, integration points, and failure paths that can affect the whole in-vehicle experience. When navigation, payments, media, and assistants share the same runtime, quality problems stop being isolated defects and become platform issues. Governance has to cover interactions, not just individual app behaviour.

Q: What are the signs that automotive software testing is not keeping up?

A: Common signs include reliance on physical head units for most validation, slow release cycles, limited coverage across vehicle variants, and defects that appear only after deployment. If OTA updates routinely create unplanned rework, the testing model is lagging the delivery model.

Q: What should organisations do when software quality becomes a safety issue?

A: They should elevate quality assurance into resilience planning, with defined ownership, release gates, and traceable test coverage for every critical update path. Safety-relevant software cannot depend on informal sign-off. The program needs measurable assurance that each release has been exercised against the environments it will actually encounter.

Technical breakdown

Why OTA delivery changes the testing model

Over-the-air updates turn vehicle software into a continuously changing runtime rather than a static release artifact. That means defects can arrive after purchase, not just at manufacturing time, and validation must cover update paths, rollback behaviour, compatibility across operating systems, and the interaction between infotainment features and vehicle functions. Traditional test cycles assume infrequent release gates and controlled environments. Connected vehicles break that assumption because every patch, UI change, and third-party integration can alter the risk profile in production-like conditions.

Practical implication: teams need automated regression and release-validation coverage for every OTA path, not just final build certification.

How multi-app infotainment expands the attack and failure surface

Infotainment systems now function like app ecosystems, combining navigation, messaging, payments, media, and assistant services. Each added application introduces new dependencies, privilege boundaries, and third-party failure modes. Even when the article focuses on quality rather than security, the architecture is relevant because every integration widens the surface that needs integrity checking, compatibility testing, and update control. In practice, this is a platform governance problem, not a single-app QA problem.

Practical implication: treat in-vehicle apps as governed platform dependencies and test cross-app interactions, not only individual features.

Why physical-only validation no longer scales

Testing against physical vehicles, cables, and local head units can still be useful, but it does not scale to the rate of software-defined vehicle change. The bottleneck is not just hardware availability. It is the mismatch between continuous software delivery and slow, manual validation models. Modern programs need repeatable automation across OS versions, display types, and release branches so that testing becomes part of the development pipeline rather than a post-build checkpoint.

Practical implication: move validation into CI/CD with automated device and display coverage to reduce release lag and blind spots.

Threat narrative

Attacker objective: The practical objective in this kind of failure chain is not necessarily malicious compromise, but uncontrolled software behaviour that undermines safety, reliability, and trust in the vehicle platform.

1. Entry occurs through complex vehicle software delivery paths, where OTA updates, app integrations, and ecosystem dependencies introduce defects or integrity failures into the runtime environment.
2. Escalation happens when poor validation allows a faulty update or incompatible app behaviour to propagate across multiple vehicle configurations without being caught early.
3. Impact is driver distraction, degraded reliability, and in some cases safety-relevant failures that turn software defects into operational risk.

NHI Mgmt Group analysis

Software quality has become a governance control, not just a development metric. In connected vehicles, the quality problem affects safety, reliability, and user trust at the same time. That makes release assurance a cross-functional control issue for engineering, security, and operations. Practitioner conclusion: treat validation coverage as part of resilience governance, not a late-stage QA activity.

Vehicle software now behaves like a multi-tenant platform, which creates control gaps familiar to identity and access teams. Each app, service, and integration introduces a new trust relationship, and the article correctly shows that the ecosystem is expanding faster than testing discipline. The named concept here is vehicle software governance debt: the accumulated risk created when release, integration, and validation controls lag behind platform complexity. Practitioner conclusion: govern the platform as an ecosystem with explicit assurance boundaries.

Continuous delivery in automotive environments demands continuous assurance. Manual, hardware-bound testing assumes a slow release cadence that no longer matches software-defined vehicles or OTA deployment patterns. The practical issue is not whether automation is desirable, but whether organizations can prove that every update path and device variant has been exercised before release. Practitioner conclusion: align testing policy with deployment velocity, or release risk will outpace control maturity.

The automotive market is moving toward software-defined accountability. As apps, updates, and third-party services become central to the driving experience, ownership of quality shifts from a final test team to the entire delivery chain. This mirrors what identity teams already know about shared control boundaries in modern platforms. Practitioner conclusion: define who owns software integrity at each stage, because ambiguity becomes operational risk.

Quality failures in connected vehicles should be treated as operational resilience events. The article’s focus on user experience is real, but the deeper issue is that defects propagate through connected systems and can influence physical-world outcomes. That puts automotive software governance in the same conversation as reliability engineering and safety assurance. Practitioner conclusion: measure release confidence the way you would measure other resilience-critical controls.

What this signals

Software-defined platforms tend to accumulate control debt faster than teams expect, and automotive software is now following that pattern. The practical signal for practitioners is that release governance must be designed for continuous change, not periodic certification. Where the platform changes faster than validation, reliability begins to behave like a security problem.

Vehicle software governance debt: the risk created when testing, integration assurance, and release ownership lag behind platform complexity. That is now a useful lens for any organisation shipping software into safety-relevant environments. Teams should prepare for more automated validation, tighter release accountability, and stronger evidence of rollback readiness before deployment.

For practitioners

• Automate regression testing for OTA releases Build repeatable test coverage for every over-the-air update path, including compatibility checks across software versions, display configurations, and rollback scenarios. This reduces the chance that a valid patch creates new defects in production-like vehicle states.
• Test cross-app interactions as a platform control Validate how navigation, messaging, payments, media, and assistant features behave together, not just in isolation. Platform-style testing helps catch integration failures that emerge only when multiple in-vehicle apps share the same runtime.
• Move validation into CI/CD pipelines Use automated flows and repeatable test environments so release decisions can be made at software speed instead of waiting for physical vehicle access. CI/CD-integrated validation reduces bottlenecks and makes quality measurable before deployment.
• Define release ownership across the delivery chain Assign responsibility for software integrity from developer through automaker to ecosystem partner, with clear sign-off criteria for update readiness. Shared accountability matters because the article shows quality is no longer owned by a single team.

Key takeaways

• Connected vehicles are no longer primarily mechanical products, so software quality now affects safety, reliability, and user experience together.
• The scale of vehicle software, app growth, and OTA delivery means manual validation cannot keep pace with modern release cycles.
• Teams need automated, pipeline-integrated testing and clearer release ownership if they want quality assurance to function as a control, not a bottleneck.

Key terms

• Over-the-Air Update: An over-the-air update is a wireless delivery of software, firmware, or provisioning data to a connected device. In security terms, it is also a trust decision, because the device must verify the sender, the payload integrity, and the intended recipient before accepting change.
• Software-defined vehicle: A software-defined vehicle is a vehicle whose features, controls, and updates are increasingly managed through software and connected digital systems. It depends on centralized compute, remote updates, and supplier-integrated tooling, which makes access control and containment more important than in traditional vehicle architectures.
• In-Vehicle App Ecosystem: An in-vehicle app ecosystem is the set of third-party and native applications that run on a vehicle’s infotainment or connected-car platform. It expands the testing surface because interactions between apps, services, and operating systems can create failures that do not appear when each component is tested alone.
• Release Assurance: Release assurance is the set of controls used to prove that software is fit for deployment before it reaches users or production environments. In automotive settings, it includes automated validation, compatibility checks, rollback readiness, and sign-off criteria that reflect the safety implications of vehicle software.

What's in the full article

Arxan Technologies' full blog covers the operational detail this post intentionally leaves for the source:

• The specific testing workflows for Android Auto, Android Automotive, and Apple CarPlay environments.
• The continuous validation approach used to reduce dependency on physical vehicles and local head units.
• The Appium-based automation model for end-to-end in-vehicle testing across OS versions and display configurations.

👉 Arxan Technologies' full post covers the testing bottlenecks, OTA delivery risks, and automation model in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and workload identity. It gives identity and security practitioners a common control language for programmes that now span software, platforms, and connected ecosystems.