Transformation at all levels
Requirements such as UNECE R155, ISO/SAE 21434 and OEM specifications are diverse, often contradictory and lack clear prioritisation. Many projects lack the structures needed to implement security in a scalable and auditable manner.
We show how we develop concepts that combine standards, laws and customer goals – clearly, scalably and practically.
With increasing digitalisation in vehicle development, cybersecurity is becoming a central component of technical responsibility. Modern vehicles are no longer isolated machines, but are embedded in highly networked systems. The development towards software-defined vehicles means that classic mechanics are increasingly being replaced by software and electronic control systems. This makes vehicles more adaptable and serviceable – but also significantly more vulnerable.
In addition to vehicle architecture, the focus is also shifting to the connected IT infrastructure – in particular cloud-based backend systems that enable and secure essential functions. To ensure that data remains protected, trade secrets are preserved and no vulnerabilities arise for the entire vehicle fleet, it is essential to systematically analyse backend architectures using clearly defined processes and methods.
The threat is real
Attacks on vehicles and their digital infrastructure—especially backend systems, communication interfaces, and update mechanisms—are no longer theoretical scenarios. Phishing, ransomware, and manipulated over-the-air updates now affect not only central IT systems, but increasingly vehicles themselves. Anyone who manipulates communication between control units or deceives the sensor technology for driver assistance systems not only accesses data, but also jeopardizes function, safety, and ultimately human lives.
In addition to internal communication networks, typical points of attack in modern vehicle architectures include cloud-based services, user and access interfaces, and data-driven control systems.
The paradigm shift in the automotive industry is in full swing: since the introduction of the UN regulation “UNECE R155,” cybersecurity is no longer optional, but a mandatory requirement for market access.
However, many companies are still in the early stages of practical implementation – or are struggling with insufficiently established processes.
Uniform framework – different expectations
Since 2022, UNECE R155 has made it clear that manufacturers who cannot demonstrate a clear cybersecurity strategy will no longer receive type approval. ISO/SAE 21434 provides the normative framework for this. However, in practice, we encounter a complex area of conflict. In addition to international requirements, many OEMs have their own security processes, checklists, and gate criteria that must be met.
This applies not only to traditional passenger car manufacturers, but also to our customers in the commercial vehicle and trailer sector, such as Meiler and Goldhofer. We have already supported both of them in obtaining initial certification in accordance with CSMS and SUMS as cybersecurity consultants and pre-assessors.
In our projects, we often see that different requirements conflict with each other. Only a structured and transparent security concept can bring them to a common denominator. This is because the combination of international standards, OEM-specific guidelines, and project-specific architecture requires good moderation of all parties involved and careful, comprehensible documentation.
We are currently preparing a targeted cybersecurity sales campaign that will address over 80 additional potential customers in the commercial vehicle and trailer segment.
Security begins with understanding the system
We always start with the question: Which functions need to be protected – and why?
We begin with threat analysis and risk assessment (TARA) – in line with ISO/SAE 21434 – and systematically analyze threats, vulnerabilities, and potential impacts. It is particularly important that we don't just think in technical terms, but also take relevant stakeholders, operating scenarios, and system dependencies into account.
The goal: security objectives that are truly tailored to the system – instead of generic protective measures based on a checklist.
The results are incorporated into a modular security concept that can grow with the system – in other words, it responds flexibly to new functions, interfaces, and architectural changes.
After all, what seems secure today may have gaps tomorrow – whether due to new interfaces, feature updates, or changes in the backend.
We systematically analyze attack vectors on communication flows, management channels, and monitoring interfaces in the cloud – as well as classic control units in the vehicle.
From analysis to concrete action
Security concepts must be more than just nice-sounding declarations of intent. That's why we not only identify the risks, but also specify their specific protection goals, associated functions, and the appropriate measures for addressing them:
- Which data flows need to be protected?
- Which components require authentication, which require encryption?
- Where are updates necessary—and how are they protected against manipulation?
In practice, we rely on, among other things:
- Secure boot and code signing
- ECU hardening
- Segmented vehicle networks
- Role-based access controls
- Intrusion detection systems (onboard & in the backend)
This is supplemented by higher-level mechanisms such as encrypted interface communication, least privilege access concepts, and transparent monitoring and logging structures for all digital services.
We document all of this along defined audit trails so that it remains traceable in the type approval process where, how, and why protective measures take effect.
Security does not end with delivery
An often underestimated aspect: even after SOP (start of production), cybersecurity must be permanently ensured. This includes secure software updates, effective incident handling, and clear responsibilities—especially in SDV projects where suppliers contribute safety-related functions.
Over-the-air updates are becoming increasingly important in this context. To prevent software errors from ending up in the cloud or being distributed to countless vehicles, it must be ensured that only authorized, tested updates are installed – preferably without customer intervention.
This requires robust update, release, and recovery concepts – in vehicle functions and cloud systems.
Also in the supply chain: Trust is good, auditing is better
No vehicle is created in a vacuum – security is always a matter of cooperation. That is why we attach great importance to clear agreements with suppliers in our projects:
- Which security requirements are binding?
- Who tests what – and when?
- What does the chain of evidence look like?
We establish consistent processes – for example, through coordinated security requirement specifications, joint FMEA workshops, or security assessments as part of supplier approvals.
The following are also becoming increasingly important:
- Contractually defined logging paths
- Minimum technical requirements for cloud services
- Mandatory participation in cross-platform reviews
We use interface agreements to define clear responsibilities on behalf of our customers, most of whom are OEMs. At the technical level, we analyze products using SBOMs (software bills of materials), for example.
Conclusion: Structure beats uncertainty
Those who think about cybersecurity early on, in a structured and collaborative manner, not only create trust, but also stability in development. Regulatory requirements such as UNECE R155 or ISO/SAE 21434 are not a tiresome hurdle – they are a catalyst for clean processes, long-term security, and better products.
Our approach: no more effort than necessary, but with enough substance to make systems secure – and keep them secure.
This means not treating cybersecurity as a downstream testing step, but integrating it into the product development process from the outset. Specifically, this means that security requirements, analyses, and measures are defined early on in the PEP phases and recorded as binding work products – instead of only becoming visible during testing.
This early involvement has several advantages: risks are identified earlier, architecture decisions can be made with security in mind, and costly changes at the end of the project are avoided. This is exactly what the shift-left concept describes: security-related tasks are moved forward in time. This is complemented by security by design, i.e., the basic idea of considering security as an integral part of the system and software architecture instead of “adding” it to existing structures later on.
In the end, it is not the sophisticated document that counts, but the process in practice.
Good documentation creates the basis—security comes from consistent implementation.
Inspired by: Wie Hacker die Zukunft der Software Defined Vehicles bedrohen
