Why the Cybersecurity Concept (ISO/SAE 21434) Cannot Be Limited to the Vehicle Alone: Considerations for Cybersecurity Managers

In practical terms, the requirements from UN R155 and ISO/SAE 21434 mean nothing less than establishing a veritable “operating system” for cybersecurity across the entire vehicle organization — one that consistently connects project management, plants and production sites, suppliers, IT and OT infrastructures, quality assurance, as well as human resources and procurement.

Thus, cybersecurity in the vehicle context represents more than an isolated technical discipline that can be located somewhere in the development department.

The Central Role of the Cybersecurity Manager: Responsibility Between Organization and Project

At the center of this overall architecture typically stands the role of the Cybersecurity Manager. What is critical here: This role cannot be understood as one-dimensional. In practice, this function is used for two different areas of responsibility that, while closely interwoven, address different levels of impact. On one hand, the project; on the other, the organization.

From our experience, approximately four out of five colleagues with the title Cybersecurity Manager are ultimately operating primarily in project-related roles.

They are responsible for the proper implementation of cybersecurity activities within a concrete development project: from refining the item definition through planning the TARA, cybersecurity concept, and verification to providing the required work products for reviews, assessments, and type approval. Put simply: This role is intended to create an accountable function that, at the operational level of the project, shall realize “somehow everything related to cybersecurity.”

Alongside this exists — sometimes explicitly named, sometimes implicitly practiced — a role at the organizational level, often titled Global Security Manager, Head of Cybersecurity, or similar.

By definition, this role is not responsible for individual projects, but rather for overarching cybersecurity governance within the organization: policies, role models, processes, interfaces, escalation mechanisms, as well as the integration of cybersecurity into existing management systems.

And here emerges the core problem this article aims to address: Frequently, cybersecurity-relevant necessities cannot be “solved” at the project level. Rather, the prerequisites must be created at the organizational level (structures, processes, procedures) so that projects can implement cybersecurity effectively, efficiently, and in an audit-proof manner at all.

Thus, this interface between organization and project determines whether cybersecurity in practice ends up as a formal documentation artifact or functions as an effective system in the development, production, and operational daily routine.

The cybersecurity concept is therefore not only a technical link, but also a reflection of how well organization and project are interwoven in their responsibility.

The Cybersecurity Manager as Governance Owner for Security

The role of the Cybersecurity Manager must therefore be understood fundamentally differently than the classic notion of a technical security specialist.

Rather, the Cybersecurity Manager functions as the owner for the entire cybersecurity governance: He or she is responsible for the establishment and enforcement(!) of policies, the clear definition of responsibilities across organizational boundaries, the design of effective escalation paths, the strategic allocation of resources, as well as the continuous effectiveness verification(!) through KPIs and audits.

This is of fundamental importance for any organization that wants to sell something on the market.

Not least, the role of the Cybersecurity Manager bears responsibility for providing evidence to external audits — an aspect that becomes business-critical at the latest during type approval according to UN R155, GB-44495 & Co.

This applies equally in the world of suppliers and technology providers: ISO/SAE 21434 explicitly emphasizes organizational anchoring by requiring defined responsibilities and the distribution of cybersecurity activities across multiple organizations—for example, between OEM, Tier-1 suppliers, and downstream suppliers.

Important: The Mandate and Authority to Act for the Automotive Cybersecurity Manager

The operational implementation of these requirements demands from the Cybersecurity Manager a clear mandate (keyword: management commitment), sufficient budget, and pronounced interface competence to build core teams, establish specialized functions such as test teams or incident response units, develop competencies in a targeted manner, and define binding escalation paths.

A proven approach consists of closely connecting cybersecurity governance to already established management systems — particularly to quality management structures.

Defined processes, independent audits and reviews, management reviews, as well as a clear “authority to act” are then not new inventions, but are adapted as proven mechanisms and transferred to the cybersecurity context.

Only then are the prerequisites at the organizational level in place for the person responsible for cybersecurity at the project level to be able to effectively address his/her portion of the topics in the project.

So much for the somewhat abstract introduction. What does this mean concretely?

The Cybersecurity Concept (per ISO/SAE 21434) as a Central Work Product: More Than Just Vehicle Technology

A particularly illustrative example of why sustainable cybersecurity must necessarily go beyond pure vehicle technology is the so-called Cybersecurity Concept, one of the central work products that ISO/SAE 21434 explicitly requires in the concept phase.

The purpose of this work product is clearly defined: The cybersecurity concept describes the strategy for systematically reducing the identified technical cybersecurity risks in the vehicle. It translates the results of the risk-based analysis (particularly the Threat Analysis and Risk Assessment method, TARA for short) into concrete cybersecurity requirements and specifies with which technical and non-technical measures cybersecurity shall be effectively achieved.

With this “strategic translation function,” it becomes clear why the cybersecurity concept cannot be limited to vehicle-internal security mechanisms.

In addition to technical requirements for the vehicle, it explicitly also addresses requirements for the operational environment — and thereby recognizes that the effectiveness of technical controls is inseparably dependent on the surrounding processes, structures, and organizational framework conditions.

More precisely: This document is far more than a technical specification of security mechanisms in the vehicle.

And even more precisely: It consists of cybersecurity requirements for the product and requirements for the operational environment, both of which are derived from the Cybersecurity Goals and based on a comprehensive consideration of the item under consideration.

The Cybersecurity Concept is the connecting element between the risk-based analysis and assessment work and the technical implementation — but it is by no means limited to the latter.

Critical is the formulation “requirements for the operational environment”: Here it is explicitly recognized that even the most robust technical security architecture in the vehicle can only be effective if the surrounding processes, systems, and organizational framework conditions support this.

A Cybersecurity Concept that would exclusively define which cryptographic methods or network mechanisms are used in the vehicle falls structurally short.

Thus we are talking about the necessity of supplements at the organizational level. In other words: This organizational foundation should not represent a downstream implementation detail in the cybersecurity concept, but rather constitutes a prerequisite for the cybersecurity concept as a work product to be meaningfully created, verified, and transferred to subsequent phases at all.

A cybersecurity concept that ignores these organizational dimensions may formally meet the requirements, but will fail in practice because the necessary capabilities, structures, and effectiveness verifications are missing to implement it effectively.

But what are “requirements for the operational environment” that a complete cybersecurity concept must necessarily address? And — this expanded — what basic prerequisites must actually be fulfilled so that a cybersecurity concept can be effectively functional?

Eight Central Fields of Action as Prerequisites for an Effective Cybersecurity Concept

Against this background, central fields of action can be identified, each of which is of immense importance for overall vehicle cybersecurity at critical transitions — for example, between plant and development, between test environments and production, at supplier interfaces, at IT/OT boundaries, in change processes.

The following list, which by no means claims to be exhaustive, is primarily intended to demonstrate how far-reaching these fields of action impact the entire organization, structures, and processes.

Above all, it should clarify that it is not the mere existence of technical mechanisms that ultimately achieves the intended effect, but that effective security is only guaranteed through the surrounding organization. This includes compliance, authorization, traceability, and if necessary restoration of the mechanisms in daily operations.

Let’s begin:

1. Network Segmentation: More Than Architecture Diagrams

Network segmentation in the automotive context is not exhausted by drawing clean architecture diagrams. Rather, it is a governance question about responsibility boundaries and actual operational reality.

Segmentation separates zones with different protection needs — such as engineering networks, test environments, production OT systems, or supplier remote access zones — and reduces the risk of lateral movement after an initial breach (which is frequently an insider attack).

If we think about this in the methodology of TARA: Effective network segmentation specifically reduces the window of opportunity along potential attack paths. For example, a developer does not receive access to the finally released software artifacts that are flashed into the vehicle in production, while conversely employees in production — often temporarily employed and with limited pre-screening — have no access to sensitive development data, architectures, or safety-/security-critical documentation.

Organizationally, this requires clear network ownerships that unambiguously regulate who is responsible for which network zone (IT department versus OT operations versus engineering), defined interfaces and handover points between these zones, release processes for justified exceptions, binding logging and monitoring obligations, as well as regular reviews of the segmentation architecture.

Because in practice, even the most well-conceived segmentation quickly erodes through “temporary” bridges — debug interfaces for developers, special test setups, or short-term supplier VPNs.

The R155 thinking reinforces this requirement, as the capability for monitoring and detection across the entire relevant infrastructure is understood not as an optional add-on but as a mandatory capability (see Annex 5, part C)

What devastating consequences neglect can have has already been clearly illustrated by consequential cybersecurity incidents in automotive practice. For instance, a globally headline-making case of a large OEM from the United Kingdom in 2025 exemplified how lacking network segmentation enabled a simultaneous failure of production and business systems, and especially payment systems, across all global sites.

2. Password Management: From Policy to Lived Practice

Password management becomes critical in the vehicle environment particularly where people and tools interact with production and test systems: diagnostic access, software build and flash pipelines, test rigs, or supplier portals.

In many smaller OEM and supplier organizations, for example, comprehensive protection of the flash process through digital signatures is not yet fully established. In these cases, when flashing, access to control units is often regulated through a password query that checks whether the system is authorized to install new software.

However, this mechanism is only effective if the relevant password actually remains exclusively with the few authorized persons. As soon as credentials are broadly shared, used multiple times, or informally passed on, this protective mechanism loses its security-relevant effect — with serious consequences for the integrity of the software introduced in production.

ISO/SAE 21434 explicitly aims at demonstrable processes and repeatable evidence.

Password rules must not exist as abstract policy, but must be anchored as enforced practice with technical controls: password vaulting, rotation intervals, multi-factor authentication where possible, as well as consistent application of the least privilege principle.

At the same time, practice shows that a sensible balance must be found here. Excessively restrictive rules — such as very short password change cycles — frequently lead to employees no longer being able or willing to work sensibly with their passwords. The result is informal workarounds such as sticky notes under the keyboard, entries in cabinets, or storage in unsecured files.

Particularly with a multitude of different access points, the use of a professional password manager is therefore not only advisable but factually a prerequisite for secure and simultaneously practical implementation.

Targeted training and awareness programs that ensure such rules are understood and lived in daily operations are indispensable. (Particularly in the time-honored automotive industry, the greatest discrepancies between “on paper” and actual practice can be observed extensively.)

Best practice is, moreover, to treat credentials as an integral component of configuration and asset management: Who possesses which secrets, where are they stored, how often are they rotated, and how is it technically prevented that credentials appear in ticketing systems, emails, or even manufacturing instructions? Only this combination of technical control, organizational embedding, and realistic implementability makes password management actually effective in the sense of ISO/SAE 21434.

3. Software Flashing in Production: The Critical Control Point

Software flashing in production represents a classic “high-impact control point.” Here it is determined whether exclusively authorized, integrity-protected software versions enter the vehicle and whether the necessary access to these systems is effectively controlled.

Ideally conceived, the flash process is based on cryptographically signed and unambiguously bound software artifacts. Each individual flash operation is thereby traceably documented (who flashed which image at which station when), and exceptional cases such as rework or repairs are regulated through clearly defined and released processes.

Practice looks different. Particularly with control units of older generations, the technical prerequisites for complete signature verification or secure key storage on the control unit are often lacking. In such cases, alternative mechanisms are employed, such as a mandatory password or authentication query of the control unit before starting the flash operation (cf. password management above). What is critical here is less the specific mechanism than its effectiveness, access restriction, and traceable embedding in defined processes.

Independent of the specific technical implementation, two central challenges arise that must necessarily be addressed at the organizational level and cannot be solved in the project.

• Signature-based flash process requires a clearly defined key strategy: It must be specified where cryptographic keys are stored within the infrastructure, how they are protected, and how it is ensured that they cannot be replaced or misused unnoticed.
• In the supplier-customer relationship, a binding strategy for the exchange and use of keys is required. Particularly when a supplier initially installs the software but the OEM must later be able to perform updates or re-flashes, it must be unambiguously regulated which party possesses which keys, how handovers occur, and how long-term update capability is ensured.

Organizationally, this control point around software flashing is particularly sensitive because production environments are typically optimized for maximum throughput. Without clear governance and consistent effectiveness verification, there is a risk that security controls are deactivated “just for testing” or “just briefly due to time pressure” and subsequently not reactivated.

A resilient flash process therefore requires clean interplay of authorization management, separation of duties (e.g., release vs. execution), comprehensive logging, as well as clear interfaces between engineering release processes, production OT, and quality assurance. Only in this way can it be ensured that security is not only defined but remains permanently effective in real production daily operations.

4. Storage and Handling of Keys: Organizational Control Beyond the Flash Process

The storage and handling of cryptographic key material — private and public keys, certificates, seed and key material — is less an isolated cryptography question than rather a central operational and misuse risk at the organizational level.

While previously the specific use of keys in the production flash process was considered, we now address the overarching question of how keys are controlled across projects, products, suppliers, and lifecycle phases.

A loss of this control has immediate systemic consequences: As soon as private keys are readable or key material diffuses uncontrolled into engineering tools, test images, or factory systems, the entire root of trust is factually compromised — independent of how well individual technical controls are implemented in the vehicle. (This has already been demonstrated too frequently in practice through illustrative incidents.)

Organizationally, therefore, an independent key management system with clearly assigned ownership and defined lifecycle becomes necessary: generation, distribution, use, rotation, revocation, and decommissioning. This includes unambiguous rules for separation of test and production keys, clean delineation of associated environments, as well as technical and procedural measures to prevent unauthorized copies or substitution of keys.

Additionally, a clear distinction must be made between infrastructural key management and product-side key usage. Mechanisms such as Hardware Security Modules (HSM), Secure Elements, or Secure Storage in the control unit address the secure use of keys in the product. However, the responsibility for their generation, distribution, activation, and withdrawal lies in the organization — typically supported by a Public Key Infrastructure (PKI), i.e., a central system for managing certificates, keys, and chains of trust.

An additional, often underestimated challenge arises from the supply chain.

Manufacturers must be able to trace at all times which supplier possesses which keys or certificates, for what they may be used, and in what status they are. With modern vehicle architectures with several dozen to well over a hundred control units, this is factually no longer manageable without tool-supported transparency. Lack of overview here leads not only to security risks but also to operational problems with updates, re-flashes, or the controlled termination of supplier relationships.

ISO/SAE 21434 explicitly addresses this topic across all lifecycle phases — including production and operations.

Cryptographic keys are thereby not a local project artifact but an organization-wide asset whose control is a prerequisite for auditability, update capability, and regulatory conformance. Only the combination of clear governance, tool-supported transparency, and clean separation between product and organizational responsibility makes key management manageable in practice.

5. Governance, Knowledge, and Awareness: The Underestimated Prerequisites for Effective Security Controls

Governance and management — including clear responsibilities, defined decision-making authorities, and appropriate personnel measures — remain the most underestimated field of action in vehicle cybersecurity, although they have a direct impact on the effectiveness of technical and procedural controls in projects.

Project-side security measures only unfold their protective effect when the organizational framework conditions do not already open attack surfaces upstream.

A significant portion of real attack paths does not begin with technical exploitation, but rather with social engineering. Typical entry scenarios include, for example, access to sensitive information by impersonating a trustworthy identity (digitally via email or messenger, but also physically on-site), penetration into internal networks through phishing attacks, or even the targeted insertion of persons with access to development, test, or production environments.

Such entry points directly affect the feasibility of attack paths that are later assessed in the TARA.

To effectively counter such attack vectors and reliably reduce the attack feasibility rating, organization-wide measures are required:

• Regular and mandatory IT security awareness training for all employees,
• Target-group-specific training for privileged roles,
• As well as — depending on the threat profile — background checks for security-critical positions, as are already common practice in some markets.

Otherwise: Without these measures, it is factually not permissible to assess these attack steps in the TARA as “difficult.” (Simply because they are not difficult, but easy to execute.)

Important here is also always the clear delineation of responsibilities: The establishment of such awareness, training, and personnel measures typically does not lie within the direct responsibility or operational feasibility of the Cybersecurity Manager  — here not even at the project or organizational level.

Nevertheless, these measures directly affect the quality of the project-side risk argumentation. If they are missing, technical controls in the project remain isolated and lose their protective effect in the overall system.

For the regulatory perspective — particularly in the context of UN R155 — another aspect is added: demonstrability.

It is not sufficient to conceptually define awareness programs, access restrictions, or governance rules. Associated resilient evidence must exist, such as training certificates, participation rates, recertifications of privileged roles, or documented reviews of critical authorizations. Only this evidence makes it possible to demonstrably show in assessments that attack vectors are not only theoretically but organizationally effectively secured.

This interplay of governance, knowledge, and awareness thus forms the invisible but critical foundation for project-side cybersecurity controls to be plausible, arguable, and regulatory resilient.

6. Supplier Evaluation: Regulatory Responsibility Meets Distributed Implementation

The evaluation and management of suppliers under UN R155 is by no means a “nice to have,” because the regulatory responsibility ultimately lies with the vehicle manufacturer — even when the actual implementation of security-relevant functions is distributed across a multitude of parties.

Organizationally, this requires a consistent supplier cybersecurity operating model that ensures at least four central aspects:

1. Defined requirements for suppliers must be formulated, including expected work products and evidence.
2. A systematic capability assessment through assessments or audits is needed to verify the actual CSMS maturity of the supplier.
3. Bidirectional traceability of requirements must be ensured at all times — from the overarching item or project down to the concrete supplier work product and back again.
4. Ongoing monitoring and issue management across the entire supply chain is required to identify and manage risks early.

ISO/SAE 21434 explicitly addresses the distribution of cybersecurity activities between customer and supplier and aims to operationalize this “interface governance.”

In practice, this means that supplier contracts must not only contain clear technical specifications in distributed development, but must also define binding requirements for processes, evidence, and the demonstrable integration of the supplier into the overarching CSMS.

This applies equally to the use of components-off-the-shelf (COTS) products, which are often procured without direct involvement of the Cybersecurity Manager, yet may not fulfill central technical prerequisites for defined cybersecurity controls — such as missing hardware security modules for secure key storage or limited update capabilities.

Additionally, particularly with suppliers who are establishing cybersecurity incrementally, resilient evidence and work products are often not yet available at the beginning of a collaboration.

To avoid later risks — whether through structural vulnerabilities on the supplier side or through missing technological foundations in the product — it is therefore critical to be able to make a well-founded assessment of the cybersecurity capability of the respective supplier early on. This assessment forms the basis for whether a product or development service is at all suitable to effectively support defined cybersecurity controls, or whether additional measures, restrictions, or compensations become necessary.

Compliance with the agreed requirements must subsequently be verified and traceably documented not only selectively but holistically and continuously within the framework of CSMS integration, supplier audits, capability assessments, and review cycles. (Here, more in-depth audits should not be overlooked, such as the Korea Vehicle Security Regulation, where for example it is also inquired how cybersecurity assurances received from suppliers were effectively verified on one’s own side.)

We note: What sounds here somewhat generally like quality, organization, and process always has tangible effects on the effectiveness of cybersecurity in the cybersecurity concept, or in the final vehicle product.

7. Communication and Information Exchange: The Banal but Critical Risk Factor

The way communication occurs internally and externally appears banal at first glance, but is a frequent root cause for credential leaks and the circumvention of established controls.

In automotive development organizations, email, ticketing systems, chat tools, and supplier portals are everyday work tools.

Without clear and enforced rules, passwords, usernames, diagnostic access, or test accounts are shared, forwarded, and archived over insecure channels — often with the best intentions but catastrophic security consequences.

Organizationally, therefore, binding communication policies are required, supported by technical enforcers: multi-factor authentication, conditional access, automatic detection and blocking of secret patterns in tickets, as well as secure secret-sharing mechanisms.

Additionally, a “default secure” toolchain should be established that, for example, provides single sign-on and multi-factor authentication wherever privileged functions are used.

This aligns directly with the logic of ISO/SAE 21434, which aims to build a cybersecurity culture and traceable processes — not only technical engineering controls.

Very concrete training and awareness programs must support employees in understanding the risks of insecure communication and naturally using secure alternatives — for example, by consistently exchanging software and associated passwords through separate channels, or providing large development and service documents exclusively through controlled exchange platforms instead of via email or open external access.

8. Change and Configuration Management: Where Sustainability Is Determined

Change and configuration management is the field of action in which the long-term sustainability of the entire cybersecurity concept is determined.

One can define the best controls and implement them technically perfectly — if after test runs in production or after debug sessions security-relevant functions remain deactivated, or if no one can say with certainty which software versions are actually installed where, one loses both control and assessability.

ISO/SAE 21434 is explicitly lifecycle-oriented; UN R155 demands a continuous capability for monitoring and response. From this organizationally follows the necessity of a central configuration management and release system that is viable across all domains and consistently connects engineering, plant, and aftermarket.

A central component of this configuration management is also access management to software artifacts themselves, particularly to source code. Protected code repositories with clearly regulated access rights, review obligations, and traceable change tracking create the basic prerequisite to structurally prevent unauthorized or manipulative software changes. The threat path “malicious software modification” appears in nearly every TARA — and is already significantly reduced in its feasibility by this organizational measure, even before technical runtime controls take effect.

Concretely, this means: clear baselines for each product variant, unambiguous identities of software artifacts (for example, through cryptographic hashes or version numbers), binding change gates where security-relevant changes must pass through a formal security sign-off, as well as established mechanisms for “control re-enablement” after exceptional states.

The principle “no control left behind” must be anchored technically and procedurally: After every test, every rework, every debug session, it must be ensured that all deactivated security functions are systematically reactivated.

This is simultaneously the bridge to evidence provision, which is central in cybersecurity-specific product assessments: One needs not only the documented decision that a certain control exists, but the comprehensive proof of when this control was active, when it was deactivated for what reason, who released this deactivation, and when reactivation occurred.

Only in this way can it be resiliently demonstrated in the UNR155-audit that the CSMS functions not only on paper but also in operational reality.

The Management Framework: Three Central Capabilities of the Cybersecurity Manager

Drawing these initial fields of action together, a clear management framework emerges: The sustainable cybersecurity concept is fundamentally a set of organizational capabilities that first enable technical mechanisms in the vehicle through real development and production daily operations and keep them effectively functional throughout the entire lifecycle.

The Cybersecurity Manager must master three central capabilities for this.

1. Governance: The establishment and enforcement of clear roles, binding policies, and resilient decision-making authority. Without this foundation, even the best technical solution remains a toothless tiger because it cannot be enforced in case of conflict with other priorities (time, costs, throughput).
2. Integration: The consistent connection between IT/IT security, quality management, engineering, production, and the supplier interface. Cybersecurity must not operate as an isolated silo, but must be embedded as a cross-functional activity in existing processes and decision structures. This requires pronounced interface competence and the ability to communicate in different “languages” with different stakeholders—from the development department through the plant to procurement.
3. Evidence: The assurance of auditability through resilient evidence, meaningful metrics, and comprehensive traceability. In a regulated industry, it is not sufficient to “do” security — one must also be able to prove that one does it, how one does it, and that the measures taken actually work. This requires a well-conceived system for documentation, regular internal gap analyses and audits, as well as the ability to successfully pass management reviews and external assessments based on this evidence. Independent of what is, for example, “customary” in production or IT, this system must then also be consistently applied across the above-mentioned functions and areas of responsibility.

Summary: Technology Protects Vehicles — Organizations Maintain the Capability to Enable Cybersecurity Sustainably

The central message of this article can be summarized in a single sentence: Technical measures protect vehicles, but organizations maintain the capability to deliver cybersecurity sustainably.

Whoever, as Cybersecurity Manager, robustly establishes the organizational capabilities, clearly defines roles, designs processes resiliently, and systematically integrates the supply chain, creates the indispensable foundation for technical controls in the vehicle to work reliably — not only at the moment of delivery but throughout the entire lifecycle.

Following this, cybersecurity with all associated fields of action must be understood as a strategic management task and equipped with corresponding priority, resource allocation, and enforcement authority.

Whoever consistently adopts this perspective and understands the described domains and tasks not as technical checkboxes but as organizational enablement questions will be able to establish a sustainable cybersecurity concept that both withstands regulatory requirements and actually functions in the rough daily reality of development, production, and operations.

Precisely this logic — processes and measures, transparency and evidence, integration and governance — is repeatedly emphasized as the critical success factor in practice-proven interpretations of ISO/SAE 21434 and in UN R155 CSMS contexts.

The challenge for Cybersecurity Managers consists in translating this logic into their own organization and bringing it to life there.

Note: This article constitutes a conceptual continuation of the theoretical foundations presented in Chapter C07 Cybersecurity Implementation of the industry-established technical publication 1000 Things Worth Knowing in Automotive Cybersecurity (2025)