What happens when software stops being a supporting layer and starts defining the vehicle itself?
Well, we are talking about modern vehicles, where software is redefining how vehicles function, connect, update, and respond.
However, as phenomenal as it sounds, the controls integrated are equally vulnerable. Behind every vehicle functionality you see in a car today are multiple lines of code running that interface with the ECUs to enable data exchange and vehicle control. But if any of these codes are manipulated the consequences can be devastating.
To prevent such mishaps OEMs and suppliers align offers solutions aligned with cybersecurity standards. The controls are built and embed with such attack scenarios in consideration. But a secure implementation without validation is only a mandate; not a guarantee.
Therefore, cybersecurity validation comes in not as optional but as a core step in overall automotive cybersecurity posture. It lays down a detailed verification process that ensures every control integrated in a vehicle system work as intended before it reaches the road.
To understand what this looks like on the ground, we sat down with Sunrag, our in-house automotive cybersecurity expert with over a decade of experience. In this blog, we will break our conversation and the understanding we derived out of our it.
Q1. What makes the cybersecurity validation process complex?
“To understand the complexity, you first have to understand what changed,” Sunrag says.
“Earlier, automotive testing was straightforward. Validation activities mainly focused on proving grounds, dynamometers, climate chambers, and vehicle performance under real-world conditions, and the questions were tangible, like
- Does this part wear out?
- Can it withstand continuous mechanical stress?
- Does it hold under heavy load and extreme conditions?
The scope was defined and the answers were physical. But things have significantly changed as the architecture shifted to an electrical/electronic (E/E) communication system.
The (E/E) architecture depends on ECUs, not a few but dozens of them. These ECUs constantly interact over communication protocols like CAN and Ethernet. That single architectural shift is what fundamentally changed the complexity of validation and has expanded its scope to cover:
- Software validation
- Communication protocol testing
- Cybersecurity validation
- Functional Safety Validation,
- System-level validation and
- Diagnostic validation
“And it doesn’t stop there. With increasing vehicle connectivity, we are now dealing with additional ECUs and additional interfaces, each expanding the threat radius,” Sunrag explains.
“It’s really crazy how far automotive technology has come, and we’re still exploring,” the interviewer remarks.
“Exactly,” he agrees. “And that exploration is exactly why having the right guardrails in place matters.”
Q2. What role does regulation play in the cybersecurity validation process?
“Compliance regulations give you a baseline,” Sunrag says. “But the goal is building systems that are secure in the real world, not just systems that pass an audit.”
Frameworks like ISO 21434 and UN WP.29 have brought much-needed structure to the overall automotive cybersecurity process. It mandates OEMs and suppliers to address cybersecurity across the vehicle lifecycle. But it’s important to understand that a mandate is not a guarantee.
“The regulation tells you what needs to be achieved. The validation process is how you prove that you’ve achieved it,” he explains. “And that gap between the two is where the real work happens.”
A system that satisfies requirements on paper and a system that holds up against a real attack are not always the same thing. Cybersecurity validation is what closes that gap.
“So, if validation is what closes the gap,” the interviewer follows up, “what does that process actually look like on the ground?”
Q3. What actually happens during Cybersecurity Validation of an ECU?
“Most people hear cybersecurity testing and picture someone running a scan,” Sunrag says and smirks. “The reality is far more layered than that.”
At its core, the process is about verifying that the software meets its security requirements. It must ensure secure communication between ECUs, and confirming data integrity, authenticity, and confidentiality across the system.
“It’s a six-step process, and each one feeds directly into the next,” he explains.
- Test Specification Review
- Setup and Execution
- Log Collection and Analysis
- Verdict Management
- Defect Identification and Reporting
- Re-Validation and Closure
We start with the existing test specifications and refine them to ensure clarity, completeness, and traceability. This means checking whether the test cases are clear enough to execute without ambiguity, and whether they can be traced back to the cybersecurity requirements they’re supposed to cover.
“At times, specs exist but they’re patchy or you can say they are written for a slightly different context or missing critical coverage. We refine them, tighten the language, close the gaps. This step sounds administrative but it’s foundational. Bad specs produce useless results.”
Once specifications are in order, we flash the software onto the ECU, run pre-checks, and set up the environment to execute the test cases. The focus here is on identifying deviations and anomalies as they surface during execution.
Alongside execution, logs and traces are collected from multiple sources. We generally use tools like Wireshark, ODIS, ESO trace, Linux depending on what the test demands. These are analysed for timing issues, communication behaviour, and security-related events.
“And that’s usually where we find actual issues,” he mentions.
Next, we pass every test case with clear verdict: pass or fail, and document them against the expected versus actual behaviour. For every test case, supporting evidence is attached. Vague verdicts create ambiguity downstream, so precision matters here.
If there’s a mismatch, a defect gets raised with a clear description, steps to reproduce, environment details, and all relevant logs attached.
Once fixes come in, we re-execute the failed test cases, run regression testing to ensure nothing else broke, and validate the fix before formally closing the defect.
“Well, now I get why you term the process to be complex and honestly its somewhat overwhelming for amateurs like me,” Interviewer remarks and continues “With AI hype everywhere is it actually making any change in cybersecurity validation process?”
Q4. How is AI shifting the Validation process?
“Honestly, AI has its own role in the cybersecurity validation process, but it is definitely not a replacement,” Sunrag says.
Artificial intelligence is making the validation process smarter, faster, and more efficient and we notice its impact across multiple stages. The most immediate value is in log analysis. The validation process generates enormous volumes of data across every test cycle. Manually combing through those logs for anomalies is time-intensive and prone to human error.
“We use AI to analyse those logs at scale, flag patterns that indicate security-related events, and surface issues faster than any manual review cycle would allow,” he explains.
Beyond log analysis, we also use AI for test coverage optimisation. It helps my team in identifying gaps in test cases, predict higher-risk areas of the system, and prioritise accordingly. The broader shift is from reactive to proactive validation.
“While its use cases help us improve test coverage,” Sunrag adds. “But the fundamentals that includes robust specifications, rigorous execution, precise defect documentation, those remain as important as ever.”
“So, the human judgement still sits at the centre of it,” the interviewer reflects.
“Always,” Sunrag says. “And I think that’s the most important thing to understand about where we are today.”
“That’s great,” Interviewer remarks. “We have covered a lot of ground we went from understanding the complexity, regulation, process, and then AI as well. Let’s close this discussion with one last outlook. Where do you see cybersecurity validation in headed from here?”
Q5. Where is Cybersecurity Validation in Automotive System Heading Towards?
The foundation is already being laid. Secure Boot, SecOC, Intrusion Detection System (IDS), diagnostic security, and OTA validation are active workstreams in production programs today.
“What changes from here is the scale and the scope. Moving ahead the focus will shift more on advanced real-time threat detection, AI-driven security analysis, cloud security, and validation of autonomous driving functionality,” Sunrag says. “The complexity of vehicle features, connected services, and ECUs is only going to increase. And validation has to keep pace with all of it.”
