Software quality is now a safety control in connected vehicles

At a glance

What this is: Connected vehicles are being treated as software platforms, and Arxan Technologies argues that software quality now functions as a safety control rather than only an engineering concern.

Why it matters: For IAM and security practitioners, the shift matters because vehicle software now depends on continuous governance across apps, updates, and third-party integrations, not just static product testing.

Context

Connected vehicles are no longer static machines with embedded software bolted on. They are software-driven platforms that receive updates, run apps, and depend on continuous validation across versions, devices, and integrations. That changes the governance problem from isolated release testing to lifecycle control over a moving digital surface.

The identity angle is indirect but real. As vehicles increasingly depend on third-party apps, cloud-linked updates, and connected services, access, trust, and release integrity become part of operational safety. Software quality and identity governance now intersect wherever a vehicle platform depends on external code and managed update channels.

Key questions

Q: What fails when connected vehicle software is tested only on physical hardware?

A: Manual vehicle labs cannot keep up with frequent software changes, multiple operating systems, and many display configurations. The result is incomplete coverage, slower validation, and a higher chance that a defect reaches production before it has been exercised in realistic combinations. In connected vehicles, that is a governance problem, not only a test-efficiency problem.

Q: Why do over-the-air updates raise the risk of software defects in vehicles?

A: OTA updates shorten the distance between code change and real-world exposure, so defects can affect drivers before teams have enough operational feedback. They also increase the importance of rollback criteria, compatibility testing, and release gating because each update can interact with other vehicle functions and connected services.

Q: How should teams measure whether connected vehicle testing is actually working?

A: They should measure whether the testing process can prove safe change at the pace software is released, across operating systems, device types, and user flows. If teams can only validate by relying on scarce physical hardware, the programme is not yet matched to the speed of the platform it governs.

Q: Should automakers treat software quality as part of safety governance or product engineering?

A: They should treat it as both, but safety governance must lead. In a connected vehicle, quality defects can affect driver attention, reliability, and the behaviour of features that are active on the road. That means release approvals, rollback plans, and compatibility checks belong in the same governance conversation as engineering standards.

Technical breakdown

Why software-defined vehicles turn quality into a safety dependency

A software-defined vehicle is not just a car with more code. It is a platform where features, interfaces, and user experience are continuously modified through over-the-air updates and third-party applications. That shifts quality from a downstream engineering check to a live control point, because a defect can affect driving context, distraction, or core vehicle behaviour after release. The more the vehicle resembles an app ecosystem, the more release assurance has to account for compatibility, regression risk, and failure containment across the whole stack.

Practical implication: Treat software release quality as part of operational safety governance, not a post-development checkpoint.

Why manual in-vehicle testing no longer scales

Physical vehicles, cables, and local head units are useful for validation, but they do not scale well when teams are shipping frequent updates across multiple operating systems and display configurations. The testing bottleneck is created by environment drift, where one build must be verified against many permutations that a manual lab cannot cover quickly enough. Continuous delivery in automotive therefore requires automation that can reproduce user flows, integrate with CI/CD, and reduce reliance on scarce hardware for every validation cycle.

Practical implication: Build automated test coverage for release pipelines so quality checks keep pace with software delivery speed.

How OTA updates change the release-governance model

Over-the-air delivery makes the vehicle more adaptable, but it also shortens the time between code change and real-world exposure. That means rollback readiness, compatibility testing, and release gating matter more than they did in a dealership-era model, where software changed far less often. When app ecosystems expand to include navigation, media, messaging, payments, and assistants, each update can introduce dependencies that affect user experience or driver attention. Governance has to assume constant change rather than rare software events.

Practical implication: Define release gates, regression thresholds, and rollback criteria specifically for OTA-delivered vehicle software.

NHI Mgmt Group analysis

Software quality has become a safety control because the vehicle itself is now a governed software environment. Once a car behaves like an app platform, release quality affects more than user satisfaction. It influences the trust boundary between the automaker, the app developer, and the driver. Practitioners should stop treating automotive software as a narrow engineering issue and manage it as a safety-relevant control surface.

Continuous testing is the only realistic answer to continuously changing vehicle software. Manual validation on physical hardware cannot keep up with frequent updates, multiple operating systems, and third-party app ecosystems. That creates a control gap between change velocity and assurance velocity. The field should measure quality by how quickly it can prove safe change, not by how thoroughly it can test a static release.

Vehicle app ecosystems introduce a governance problem that looks increasingly like platform security. The more maps, media, payments, assistants, and productivity tools move into the cockpit, the more release integrity, compatibility control, and rollback discipline matter. Connected vehicle quality gap: the failure mode is no longer just a buggy build, but an under-governed software stack that reaches the driver before the organisation can prove it is safe. Practitioners should align automotive release governance with continuous assurance models.

Automotive teams need to think in terms of blast radius, not isolated defects. A minor software fault on a phone can be frustrating, but the same fault in a driving context can affect attention, trust, and safety outcomes. That changes how risk should be prioritised, especially where connected services and OTA updates are now routine. Security and engineering leaders should evaluate how much operational exposure each software release creates before it reaches the road.

What this signals

Connected vehicle governance now depends on proving safe change at software speed. The practical challenge is not whether teams can test a build, but whether they can continuously validate new software across the combinations that matter in live driving conditions. Release discipline, rollback readiness, and compatibility control become the operational controls that decide whether an update is safe enough to ship.

Software quality gap: this is the point where automotive assurance starts to resemble platform security, because every new app, integration, or OTA change expands the blast radius of a defect. Teams should evaluate connected services as governed change objects, not one-time features, and align release gates with the risk they create in the cabin.

For practitioners

• Expand release governance beyond functional testing Define quality gates that include compatibility, regression, rollback readiness, and user-impact validation for every OTA change.
• Automate cross-platform in-vehicle test coverage Use automation to exercise Android Auto, Android Automotive, Apple CarPlay, and other connected interfaces across OS versions and display types.
• Measure the safety impact of software defects Track which defects can affect driver attention, feature availability, or connected-service reliability so severity reflects real-world vehicle use.
• Treat third-party app integration as governed change Require validation for every external app or service that can alter in-vehicle behaviour, not just for automaker-owned code.

Key takeaways

• Connected vehicles are becoming software platforms, so defects now carry safety implications as well as usability and reliability consequences.
• The main control gap is testing velocity, because manual vehicle-based validation cannot keep pace with continuous software delivery.
• Automakers should govern OTA release quality with the same discipline they apply to safety-critical change control, including rollback and compatibility checks.

Key terms

• 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.
• 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.
• 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.
• Continuous Testing: Continuous testing is the practice of assessing security conditions throughout the life of a system rather than at fixed intervals. In the bug bounty context, it means live, ongoing discovery that can reveal issues created by rapid changes in code, configuration, or access paths.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for security and identity practitioners who need a stronger control model for software-driven ecosystems and delegated access.