It’s the same as always with EU directives. In theory, they are about doing the right thing. They are issued to solve a problem and harmonise the associated areas of action for all EU member states. However, the process from the EU to the national governments and to the actual practical application on the desks of those actually affected is always complex. This is also the case with the NIS-2 Directive (EU 2022/2555), which is intended to serve as a new basis for cybersecurity risk management, incident reporting and the implementation of minimum cybersecurity requirements. What we are witnessing first and foremost in this context are service providers, solution vendors and consultants who are using the directive as an invitation for heavy advertising. We do not want to join them. Rather, the following lines are intended to give those responsible for automotive cybersecurity and security in vehicle development an initial, introductory overview of the actual points of contact between the legal framework of NIS-2 and the fields of action of vehicle security. Here we go.
Philipp Veronesi
NIS 2? At first glance, this seems to be purely about information security. So it’s a job for IT security officers. Have fun, you’ll figure it out. Is it that simple? Not really, especially since the directive’s effects will sooner or later extend to a number of aspects of value creation.
Especially in view of the rapid technological developments in vehicles, components and systems, it should be noted that classifications, assignments and ways of thinking from the past may no longer be applicable in the future. This is especially true in view of the fact that the product ‘vehicle’ is no longer in the hands of OEMs alone, but (e.g. particularly visible for end users in infotainment) new, deeper interdependencies with suppliers, technology providers, etc. are now shaping responsibilities.
Automotive security managers are therefore advised to keep an eye on emerging specifications, guidelines and requirements in the field of cybersecurity.
A brief summary: Where have we come from, where are we going?
At this point, a brief explanation is needed: Anyone who has already had a look at the NIS 2 Directive document on the European Commission’s website will quickly realise that the Directive is primarily addressed to the EU Member States, which are faced with the task of creating a valid legal framework and associated structures at national level to ensure an EU-wide harmonised implementation of the defined minimum cybersecurity requirements with the help of national institutions and procedures (a small but important detail: when the country-specific legislation is adopted, the details may be ‘stricter’ than required by the EU).
At this point, a brief explanation is needed: Anyone who has already had a look at the NIS 2 Directive document on the European Commission’s website will quickly realise that the Directive is primarily addressed to the EU Member States, which are faced with the task of creating a valid legal framework and associated structures at national level to ensure an EU-wide harmonised implementation of the defined minimum cybersecurity requirements with the help of national institutions and procedures (a small but important detail: when the country-specific legislation is adopted, the details may be ‘stricter’ than required by the EU).
As always with legal texts, this makes things a little more complicated. So, if you are looking for precisely specified requirements that you can systematically tick off, you will be disappointed.
Especially since the first step is to find out to what extent an organisation falls within the defined scope of NIS-2 (if it is not part of the critical infrastructure and thus directly affected).
To this end, NIS-2 addresses organisations in high and very high criticality sectors, which are defined quite generically in Annex I and Annex II.
How does NIS 2 affect the automotive industry, suppliers and vehicle manufacturers?
Let’s start at the end, literally, in the annex. Annex II, paragraph 5.5. of the Directive, which was finally adopted on 14 December 2022, identifies both the “manufacture of motor vehicles, trailers ans semi-trailers ” and the “manufacture of other transport equipment” as critical sectors and therefore directly affected by the requirements of the NIS 2 Directive.
In case of doubt, Member States can even make their own classifications, or they usually already provide official tools to help economic operators determine the extent to which they are affected by the NIS 2 Directive.
10 things automotive security managers should know about NIS-2
Below we try to give a first overview of what might be important.
(1) Approach cybersecurity in a formal and proper way: assigning responsibilities and ensuring accountability
In the structured OEM cosmos, the requirements for defining responsibilities, ensuring accountability and organising information flows (etc.) may be quickly dismissed with a shrug of the shoulders. In smaller organisations and units, however, it should be clear that NIS-2 requires the formal designation of responsibility for cybersecurity measures at the highest management level. It is no longer enough to delegate responsibility somewhere; it is about taking a top-down approach to cybersecurity and overseeing implementation.
This means that management is more strongly encouraged to understand cybersecurity as a strategic issue and to ensure real support. On the one hand, NIS 2 should largely act as an awareness catalyst, which at best will lead to new implementation options. On the other hand, it can be expected that, from an internal perspective, all security-related developments will have to be justified more strongly to management and the need for cybersecurity will have to be presented in a more substantiated manner.
(2) NIS-2 requirements for comprehensive risk assessment and the UN R155-Cyber Security Management System
First, a little applause for the automotive industry. The development and maintenance of a Cybersecurity Management System (CSMS) has been mandatory since the middle of last year under UN Regulation No. 155 as part of the type approval of new vehicles – with distributed risk management along the entire vehicle value chain, the economic operators in the supply chain are usually already involved.
This means that the CSMS, although primarily vehicle-focused and based on an Information Security Management System (ISMS), is currently one of the best ways to meet the NIS-2 requirements.
Nevertheless, it is still necessary to ensure at an organisational level that the detailed requirements of all NIS-2 aspects are properly covered and regularly reviewed.
Excursus: To what extent is the connected vehicle itself subject to the NIS-2 Directive?
The question of whether vehicles themselves fall within the definition of network and information systems under NIS-2 remains open to interpretation. It could be argued (with reference to the definition in Article 6) that modern connected vehicles, with their underlying data processing, could meet the criteria listed. However, this would mean that the Directive would directly regulate the vehicle itself, which is not the intention of the Directive, which is primarily aimed at system operators.
In the course of the implementation of the NIS-2 Directive into national law, the German Association of the Automotive Industry (VDA), for example, argues in its position paper (03/2023) that, as in the Cyber Resilience Act, vehicles (or vehicle services) should be excluded because sector-specific regulations already impose cybersecurity requirements that are at least equivalent.
There is an urgent need to clarify this issue, as it would fundamentally affect issues such as processes, obligations and reporting.
(3) Cybersecurity in the supply chain is trending
With NIS-2, cybersecurity is no longer focused on individual actors, but on entire supply chains. The identification of cybersecurity risks in supply chains and the corresponding processes and measures to manage them are becoming an important field of action. With cybersecurity becoming more and more embedded as a quality dimension in vehicle development, this should not be a new issue for those responsible.
However, NIS-2 shows how far-reaching the integration of suppliers into a company’s own security architecture should be:
- Risk assessments
- Definition of security requirements for suppliers and their inclusion in contracts
- Audits, audit certificates
- Incident response processes
- Threat and vulnerability information sharing
- …
The whole catalogue. The automotive industry, which still tends to collaborate too restrictively in this area (keyword: intellectual property), must find ways to share information about vulnerabilities and risks more systematically (especially in distributed development). In the big picture, but also, for example, in terms of cooperation in implementing the TARA methodology.
(4) The whole issue of reporting requirements
Particular attention should be paid to the rather strict security incident reporting requirements that NIS-2 entails. Reports must be made to national authorities (in Germany, to the Federal Office for Information Security, BSI) at various levels and within appropriate timeframes.
Anyone familiar with GDPR/DSGVO and data protection, for example, knows that data protection incidents must also be systematically reported there – accordingly, the handling of security incident reports to authorities should be taken seriously, the corresponding requirements should be known and functioning processes (and knowledge of them!) should be established.
(5) Priority for Business Continuity
Although the NIS 2 directive might be thought of as primarily aimed at initiating ‘document pushing’, it also intervenes in business processes, or more precisely in their maintenance.
Specifically, it addresses Business Continuity (BC) and Disaster Recovery (DR). We have already discussed the critical consequences of failures, for example in the area of cybersecurity in automotive production.
Even though business continuity is not explicitly mentioned in UN R155/CSMS, it is clear that these aspects need to be considered in the context of overall risk management at all stages of the entire vehicle lifecycle.
In particular, with regard to the cybersecurity requirements that the industry will face in the future, it is clear that emergency plans, reliability and maintenance of security related structures, processes and mechanisms with regard to the functions involved in the entire vehicle lifecycle (software update management, incident response, etc.) will be absolutely essential – also (if not especially!) on the supplier side.
(6) Yes, secure development processes.
From a product security perspective, it could be said that NIS-2 primarily addresses the ‘trappings’, but the directive clearly mentions ‘secure development processes’ in the context of cybersecurity risk management (including for the suppliers and service providers involved).
The tangible assessment of secure development, the organisational management of the review of ‘cybersecurity working practices’ (with the incredible breadth and depth that this involves!), these things will not disappear from the vehicle cybersecurity responsibilities.
But one thing is clear: NIS-2 will not ‘overlap’ in the sense that security principles and development practices (starting with ISO/SAE 21434 and in the domain-specific specialisations) will not be undermined.
Those who have already recognised Security-by-Design as a driver in vehicle development should always consider the necessary balance between the business case and cybersecurity requirements at an early stage to avoid unpleasant surprises later on.
(7) Since cybersecurity awareness is probably getting on everyone’s nerves, is it now called cyberhygiene?
As (cyber) security professionals, we are quick to dismiss anything to do with cybersecurity awareness and consciousness as banal.
At the same time, however, we are aware that many structures, processes, procedures, functions and roles often deviate from an ideal of how cybersecurity requirements are taken into account.
The relevant passages in ISO/SAE 21434 and UN R155 on automotive cybersecurity competence development and the importance of awareness are well known at best – NIS-2 also clearly states that awareness of cyber risks needs to be raised.
However, NIS-2 is particularly aimed at small and medium-sized enterprises, which for structural reasons have fewer resources and, just as often, less awareness of cybersecurity requirements.
In particular, the aim in future will be to focus even more consistently on raising awareness of cybersecurity issues, providing the necessary training and actually empowering people to apply cybersecurity in practice. The members of the management bodies are also explicitly mentioned here and are particularly obliged to participate in regular training courses.
(8) Establish, implement, document – exchange with national authorities… Cybersecurity is becoming a top management issue.
It is important to understand that the NIS 2 Directive is very clear that the responsibility for cybersecurity must be anchored at the executive level of an organisation. Not only does this relate to the specific approval and monitoring of risk management measures, but also to the fact that natural persons can be held liable for breaches of their duties to ensure compliance with the NIS 2 Directive.
In plain language, this means that board members and directors can be held personally liable if they fail in their duties to adequately consider cybersecurity.
While, as mentioned above, delegating responsibility is not enough, transferring responsibility to external service providers does not release them from personal liability either.
This shows how deeply the Directive interferes with corporate governance and processes, and what new responsibilities arise at the level of the organisation as a whole.
(9) Potentially relevant: The question of “intelligent transport system operators”
The question of who is directly or indirectly affected by NIS 2 and to what extent should (theoretically) be clarified by systematically working through the relevant national questionnaire (see above) or, if a business partner is affected, by subsequently examining the business relationships that play a role here.
Alternatively, the simplified rule of thumb applies: you may be affected.
It is also important to note that ‘operators of intelligent transport systems’ are considered a highly critical sector (see Annex I).
Specifically, this refers (also) to private organisations, service providers and data suppliers responsible for providing and processing traffic and mobility data. While the term ‘operator’ here primarily refers to actors responsible for the operation and management of such systems, it is necessary to assess on a case-by-case basis to what extent their own services related to ITS may fall under this definition. (Disclaimer: This is not legal advice).
(10) Last but not least: It is still important to keep an overview
As welcome as it is that NIS-2 represents a major effort at European level to promote the harmonisation of cybersecurity standards among economic actors and national institutions, the immense challenge of keeping track of all the relevant requirements remains.
In particular, those responsible for automotive cybersecurity, who must primarily take into account their industry-specific regulations, directives, requirements, industry standards, guidelines, best practices and industry standards, would do well to think holistically.
While different requirements should not contradict each other, a consistent, organisation-specific approach (e.g. with regard to the required documentation) can provide good support for comparability, auditability and continuous development.
Ultimately, it is about doing the right things, following up on implementation and producing the right reports where necessary. If the EU can achieve it, perhaps your organisation can too.
