Key Takeaways

• The real challenge in autonomy has shifted from building impressive prototypes to proving software-defined vehicles are safe and secure in the real world.
• Centralized vehicle architectures boost capability but create new systemic risks that demand holistic validation.
• Software supply chain traceability and ongoing cybersecurity management are now core to autonomy success.
• Early integration and cross-functional collaboration are essential for how we fundamentally validate safety and security.

 

“You can architect and build a beautiful system on paper, but the moment that you try to prove it’s safe enough to put on a public road with real passengers, that’s kind of where you see the gaps.”

That warning from Hemanth Tadepalli, Senior Cyber Security and Compliance SME at May Mobility, gets to the heart of the challenge facing autonomous vehicle programs. In RunSafe Security’s recent Mobex webinar with Automotive World, May Mobility, and SODA, one theme came through clearly: autonomy is no longer limited by the ability to prototype impressive technology. It is limited by the ability to validate, secure, and scale that technology in the real world.

The next generation of vehicles will depend on AI, centralized architectures, cloud connectivity, fleet infrastructure, and software from a sprawling supplier ecosystem. But the companies that lead the market will not simply be the ones with the most advanced models or the most ambitious roadmaps. They will be the ones that can prove their systems are safe, secure, traceable, and resilient long after launch.

The hard part of autonomy is no longer getting software into the vehicle. It is controlling what happens after that software begins interacting with sensors, infrastructure, cloud systems, remote operators, suppliers, regulators, and passengers. Every new connection creates value. Every new dependency creates risk. 

The Bottleneck Has Moved from Invention to Evidence

The bottleneck in autonomy has shifted from invention to evidence. A prototype can prove that a system works under controlled conditions. A production deployment has to prove that it can keep working safely across real roads, changing environments, software updates, supplier changes, and unexpected edge cases.

Traditional validation methods still matter, but they were built for a more deterministic world. Unit testing, hardware-in-the-loop testing, and simulation cannot bear the full burden when AI becomes part of the decision-making process. 

“When you start introducing AI into the decision path… they’re no longer really sufficient on their own,” Tadepalli said. “You really need more of a fundamentally different evidence package that you build together.”

That evidence package is becoming the foundation of autonomy at scale. It needs to connect requirements, design choices, implementation, test results, safety goals, cybersecurity controls, and operational data. Without that traceability, teams may not discover the gaps until they are preparing for launch, when the cost of fixing them is highest.

Centralized Architectures Improve Capability, but Increase Systemic Risk

Centralized and zonal architectures are changing what vehicles can become. Architectures make it possible to orchestrate functions that once lived in separate domains, improve the user experience, and support more advanced software and AI capabilities. But they also concentrate risk.

As Sergey Malygin, CEO of SODA, put it, centralization “allows you to think about your system on a more integral level.” That is the opportunity. The challenge is that the vehicle can no longer be secured or validated as a collection of isolated parts.

Autonomy now depends on vehicle platforms, edge devices, zonal controllers, cloud infrastructure, fleet operations, OTA updates, APIs, and supplier-delivered software. “All of that becomes a system of systems,” Malygin said. In that environment, a weakness in one layer can ripple into another. Architecture is no longer just an engineering decision. It is a security and safety decision.

AI Changes the Assurance Model

AI adds many capabilities to vehicles, but it also changes what assurance has to prove.

Classical automotive safety approaches often assume systems can be tested against known, deterministic outcomes. AI-enabled autonomy complicates that model. These systems must be evaluated within their operating boundaries, continuously monitored, and improved based on real-world performance.

Malygin captured the shift with a simple question: “Can we guarantee that a human will not fail?” As AI systems take on more driving-related decisions, validation may need to look less like certifying a static machine and more like assessing whether an intelligent system can operate safely within clearly defined limits.

That makes operational design domains critical. The goal is not to prove that an autonomous system can handle every possible scenario everywhere. The goal is to define where it can operate, under what conditions, with what safeguards, and with what evidence.

Software Supply Chain Risk Is Now Autonomy Risk

Software supply chain risk is no longer a back-office compliance issue for autonomous vehicles.

Modern vehicle software pulls from suppliers, open source projects, internal codebases, cloud services, fleet systems, APIs, and AI tooling. Each dependency can introduce vulnerabilities, licensing issues, update challenges, or unknown behavior. The more complex the stack becomes, the harder it is to answer a basic but critical question: what exactly is running in the vehicle?

“When your software stack is pulling from dozens of suppliers and hundreds of open source components, I think it’s really important to maintain that trace,” Tadepalli said. “That’s kind of the hard part right now.”

That traceability has to survive beyond launch. Regulations such as UN R155 require ongoing cybersecurity management, vulnerability handling, incident response, and maintenance throughout the vehicle lifecycle. A one-time SBOM or static compliance document is not enough for software that changes continuously in the field.

Security Is Part of Safety

For autonomous and software-defined vehicles, cybersecurity is integral to safety.

A successful cyberattack can become the mechanism by which a safety failure occurs. A compromised software component, tampered fleet connection, malicious OTA update, or intercepted remote-operator communication can quickly move from digital risk to physical consequence. Tadepalli was direct: “It has to be a requirement.”

That requires safety and security teams to work together earlier and more often. Functional safety analysis and cybersecurity risk assessment cannot happen in separate rooms, produce separate documents, and converge only at the audit stage. “What actually works is integrated threat and hazard analysis,” Tadepalli said.

This becomes even more urgent as attackers use AI to find weaknesses faster. As Malygin observed: “We use AI to develop the things, we use AI to test the things, we use AI to attack the things.” Security has to be designed for that reality from the start.

Shift Left, but also Close the Loop

The practical answer is not to slow innovation but to move evidence-building earlier.

Safety cases, cybersecurity cases, SBOMs, software provenance, validation strategies, and incident response plans cannot be reconstructed at the end of development. They have to grow with the system.

“If you don’t collect evidence as you go, you can’t really reconstruct that at the very end,” Tadepalli said.

Shift-left security is part of that answer, but it is not the whole answer. Teams also need a closed engineering loop that connects requirements, architecture, implementation, simulation, testing, certification, and operational data. That loop is what allows organizations to keep iterating without losing control.

The Organizational Challenge May Be Harder than the Technical One

Many automotive organizations were built around hardware programs and component ownership. Autonomy requires a different operating model: safety engineers who understand threat modeling, security engineers who understand functional safety, software teams that understand compliance, and leaders who treat resilience as a product requirement.

“You need to have safety engineers who understand threat modeling,” Tadepalli said. “You need security engineers who understand functional safety.”

Tools matter, but they will not fix a siloed organization. Scaling autonomy requires teams that can make safety, security, software, and validation decisions together.

The Cost of Waiting Will Be Measured in Consequences

Businesses that can demonstrate that their systems are reliable will win autonomy, not those that prototype the fastest.

That means building security into the architecture, maintaining traceability across the software supply chain, validating AI-enabled behavior within clear operating boundaries, and treating safety and cybersecurity as one connected discipline.

The vehicles of the future will be smarter, more connected, and more capable. They will also be more complex. The question is whether the industry can build the evidence, resilience, and operational discipline needed to scale them safely.

Watch the full Mobex webinar, “Scaling Autonomy: AI, Software Complexity, and Next-Generation Vehicle Architectures,” to hear the full conversation.