Cybersecurity and Data Privacy: Stakeholders’ Stand on Regulations and Standards

Abstract

AVENUE’s technological interest lies in those state-of-the-art technologies and solutions that either are already commercial or close to the market and are expected to reach commercialisation within the following years. For the successful implementation of the project activities, a wide range of technological as well as non-technological elements will be employed, adapted, integrated, and, where required, partially developed. The present chapter focuses on those connected automated vehicle (CAV) technologies from the perspective of cybersecurity, delving into questions on in-vehicle, back-end, and infrastructure, including the communications between vehicle to vehicle (V2V), vehicle to infrastructure (V2I), vehicle to cloud (V2C), vehicle to everything (V2X), software safety, as well as security and privacy by design principles for the development of connected devices. Furthermore, non-technological issues cover stakeholder and user acceptance, regulatory and legislative requirements, a new standardisation progress, ethical considerations, and vehicle and technology certifications and licensing. The purpose of this chapter is to present the project context and relating it to the potential cyber assaults and data privacy threats. It further delineates the conducted assessment and the provided recommendations which were built based on the key standards and regulations wrapping together CAVs, cybersecurity, and personal data protection pursuits.

1 Introduction

More than ever, cybersecurity and data privacy are crucial to the introduction of new technologies, as everything tends to be automated, autonomous, and, most of all, connected. In this chapter, connected automated vehicle (CAV) technologies related to new digital services will be closer inspected to elaborate on a plurality of new threat vectors.

1.1 CAVs’ Threats

AVENUE involves a wide spectrum of technologies for a broad coverage and analysis of the existing advancements in a full ecosystem of the CAVs as depicted in Fig. 6.1:

• In-vehicle equipment: categorised in the present work as (1) sensors, representing the elementary devices through which the vehicle builds its perception and awareness model; (2) in-vehicle communication, the subsystems within the vehicle that serve for communication; and (3) ports, granting physical access to various parts of the vehicle systems.

• External communication technologies: from vehicle to vehicle (V2V) for fleet coordination to vehicle to infrastructure (V2I) and vehicle to everything (V2X) for infrastructure deployment in the cities and public transport operators (PTOs).

Fig. 6.1

Attack vectors within the CAV ecosystem

1.1.1 In-Vehicle Equipment

To assure the CAV’s highly automated navigation of levels 4 and 5 as defined by the Society of Automotive Engineering (SAE) (SAE, 2021), the vehicle intelligently compiles inputs collected from its internal equipment (including cameras, Global Positioning System (GPS), radio detection and ranging (RADAR), light detection and ranging (LiDAR), tire pressure monitoring system (TPMS), odometry, and ultrasound sensors). The processing and fusion of the collected data from such sensors support on providing accurate data on positioning, behaviour predictions, collision avoidance, pedestrian detection, and object recognition (Parkinson et al., 2017). Despite the sensors’ crucial role to safe self-driving, they remain victims to attacks like spoofing, jamming, relay, and tampering, leading the vehicle to either hit non-perceived objects or consider non-existent obstacles (Benyahya, Collen, et al., 2022).

Furthermore, electronic control units (ECUs) are part of the essential in-vehicle components which control the CAV’s systems by receiving and processing broadcast signals from sensors (Dibaei et al., 2020). On the same note, ECUs are connected to in-vehicle networks like controller area network (CAN), Local Interconnect Network (LIN), Media-Oriented System Transport (MOST), FlexRay, and Ethernet (Wu et al., 2020). Each protocol supports different communication within the in-vehicular network. However, they embed many security concerns and risks of potential attacks such as denial of service (DoS), packet injection, sniffing, eavesdropping, spoofing, relaying, and bus-off (El-Rewini et al., 2020).

Physical ports can broaden the points of entrance to an attack over the in-vehicle network. The on-board diagnostic (OBD) is a port that is normally used for the vehicle diagnosis or for ECU firmware upgrade (Elliott et al., 2019). Though if false messages are injected through it, the control over the automotive functions (like braking) can be granted to the attacker (Parkinson et al., 2017). Similarly, falsified data, malware, or a virus can be injected through Universal Serial Bus (USB) ports or the electric charging port (Bhusal et al., 2020).

1.1.2 External Communication Technologies

External vehicular communications come to complement the in-vehicle equipment on the automated driving functions. CAVs communicate to their surroundings using V2V to broadcast and receive signals from other vehicles and V2I to exchange data with the infrastructure (Elliott et al., 2019). Besides, V2X embeds both V2V and V2I in addition to communication with any external devices like smartphones (El-Rewini et al., 2020). Such communication modes are taking place thanks to vehicular ad hoc networks (VANETs) where vehicles and infrastructure are referred to as nodes which can exchange traffic-related messages.

The VANET architecture is composed of on-board units (OBUs), which are located at the level of the CAV, roadside units (RSUs), which are placed within the infrastructure, and a trusted authority (TA), which is the base station connecting OBUs and RSUs to the core network and which distributes public/private keys and certificates among nodes (Noh et al., 2020). VANETs are supported by wireless technologies like IEEE 802.11p, which is the basis of dedicated short-range communication (DSRC) (Ali & Li, 2020). Maple et al. (2019) added that further Internet of Things (IoT) technologies such as IEEE 802.15.4 or ZigBee might be used to facilitate information exchange. However, if the VANETs’ signals are eavesdropped by an attacker, the CAV can be compromised or maliciously tracked (Veitas & Delaere, 2018). Further attacks were identified and asserted to dangerously impact the traffic including sybil attack, distributed denial of service (DDOS), and man in the middle (MitM) (Dibaei et al., 2020).

CAVs use a plethora of technologies to come to fruition of safe automated driving and high connectivity with their surroundings. Nevertheless, such minibuses end up inheriting security weaknesses and accumulating additional threat vectors that can be real showstoppers to the CAV’s prevalence.

1.2 Motivation

Bearing in mind the rampant CAV’s threats, the different automation levels, and the multiple stakeholders within the AVENUE ecosystem, a cybersecurity and data privacy assessment and a guide of references regarding standards and regulations will be provided. Figure 6.2 depicts the adopted approach fusing thorough understanding of CAV’s challenges, analysis of existing regulations and standards chasms, and an evaluation of the AVENUE landscape, resulting to what is presented as the standards coverage map (SCM).

Fig. 6.2

Investigation methodology

This article addresses the following questions:

• Within the AVENUE ecosystem, how can cybersecurity and data privacy threats be efficiently mitigated?

• What are the key technical tools recommended by legal policies and standardisation bodies to countermeasure those threats?

• How are risk assessment, vulnerability analysis, and penetration testing considered by the partners to shield the AVENUE minibuses?

• By being compliant to the existing standards, how anchored would the CAV be from both cyber assaults and data leakages?

The remainder of this chapter is structured as follows. Section 6.2 sheds light on the most recent (up to 2021 fourth quarter) regulations and standards to be considered within the CAV’s landscape. Moreover, it discusses global efforts which can infer some lessons learned. Section 6.3 outlines the cybersecurity assessment and data collection tools adopted within the AVENUE scope. Section 6.4 presents the means and input collection from the different PTOs and software providers. Section 6.5 depicts the key recommendations upon the identified shortcomings from the cybersecurity and data privacy perspectives. Finally, Sect. 6.6 provides concluding statements and future work orientations.

2 Regulations and Standards

Being crucial for the evolution, development, and deployment of CAVs, cybersecurity and data privacy challenges have attracted many stakeholders including automotive manufacturers, legal and regulatory bodies, information technology (IT) and telecommunication suppliers, operators of intelligent transport system (ITS), and mobility service providers to collaborate and come up with new laws, strategies, and guidelines. Figure 6.3 reflects an in-depth overview of the existing and forthcoming efforts from the key players in providing both mandatory and nice to have requirements.

Fig. 6.3

Taxonomy of regulation and standardisation of stakeholders

The 4 years of the AVENUE project witnessed a major progress in regulating CAVs’ deployment. In August 2022, the European Commission (EC) published the regulation (EU) 2022/1426 (Regulation (EU) 2022/1426, 2022) where technical specifications for the type approval of fully automated vehicles were defined, built upon the generic vehicular regulation 2019/2144 (Regulation (EU) 2019/2144, 2019). Furthermore, Network and Information Security (NIS) 1 and 2 (EU 2016/1148; EU 2020/1148) directives call the operators of IT service providers to take the appropriate measures to manage cyber risks posed to the security in a general scope.

While the EC regulations laid down on either generic type of approval or IT cybersecurity, the United Nations Economic Commission for Europe (UNECE) published acts joining cybersecurity measures to the CAVs’ environment. The UNECE R155 (UNECE R155, 2020) and R156 (UNECE R155, 2020) came with the purpose to unify the automotive standards by requiring cybersecurity management system (CSMS) and software update management system (SUMS) certifications accordingly for the SAE level 3 onward. The two certifications cover the cybersecurity risk management, security by design, and security incident detection and mitigation and secure software updates over the CAV’s life cycle including development, production, and post-production (Suh, 2020). The involvement of certification third parties, such as TÜV SÜD and CertX, can be compulsory to generate CSMS and SUMS either for the first time or for their renewal occurring every 3 years.

Under the auspices of standard development organisations (SDOs), efforts were made to shield the entire CAV’s environment. The International Organisation for Standardisation (ISO) and SAE working groups claim to provide a complete cybersecurity management for the driverless landscape with a focus on the in-vehicle components (Schoitsch & Schmittner, 2020). The ISO/SAE 21434 (ISO/SAE 21434, 2021) and ISO/PAS 5112 (ISO/PAS 5112, 2021) represent the salient standards providing a high-level guidance on cybersecurity governance and auditing for the CAV’s ecosystem. The European Telecommunication Standards Institute (ETSI), Publicly Available Specification (PAS), Automotive Open System Architecture (AUTOSAR), European Committee for Standardisation (CEN), World Wide Web Consortium (W3C), IEEE Standards Association (IEEE SA), and 5G Automotive Association (5GAA) institutions provide standards for securing vehicular communication (Kim & Shrestha, 2020).

As depicted in Fig. 6.3, further recommendations were provided by the International Telecommunication Union (ITU) outlining security threats definition, security guidelines for V2X, specification of secure software update procedure for ITS devices, and guidelines for intrusion and misbehaviour detection (ITU-T, 2020). Additionally, the European Union Agency for Cybersecurity (ENISA) published several reports spotlighting the CAVs’ cybersecurity risks once deployed within smart cities. Besides, automotive associations such as the European Automobile Manufacturers Association (ACEA) (ACEA, 2019) and the Automotive Information Sharing and Analysis Centre (Auto-ISAC) (Auto-ISAC, n.d.) are orienting the original equipment manufacturers (OEMs) towards self-audit, testing, and deploying incident response plans.

2.1 CAVs Privacy Initiatives

The General Data Protection Regulation (GDPR) is the fundamental privacy data law in the European Union (EU). It sets strict obligations related to personal data (PD) processing, rights for concerned individuals (data subjects), technical requirements to employ privacy preserving techniques (anonymisation and pseudonymisation), and Data Protection Impact Assessment (DPIA) as an assessment for any new technologies with privacy risks (Regulation (EU) 2016/679, 2016). Nevertheless, within the CAV’s complex environment, GDPR implementation remains convoluted, as the stakeholder can accumulate multiple roles (e.g. being data processor and data controller simultaneously) (Benyahya, Kechagia, et al., 2022). Another limitation of the GDPR within the CAV context is considering anonymisation as a permanent solution. Though with minor reverse engineering efforts, the PD can be de-anonymised with no compliance violation to the GDPR (ENISA, 2022). Hence, a full compliance does not rhyme with an absolute PD protection.

To limit the GDPR pitfalls, the European Data Protection Board (EDPB) provided guidance on the processing of PD in the context of ITS, which highlighted privacy risks and provided recommendations on data protection by design and by default within the CAV’s environment (European Data Protection Board, 2020). Moreover, the guidelines focused on consent as the legal basis for processing PD inside the vehicle and through V2X communications (European Data Protection Board, 2021).

Further European initiatives, such as GAIA-X, DATEX-II, and Data for Roads, aim to overcome the current privacy hurdles within the vehicular environment. GAIA-X provided proposals on data protection rules and architecture standards in many areas including location-based services (LBS) and mobility as a service (MaaS) in smart mobility (BMWi, 2020). DATEX II has been addressing traffic data sharing and transmission including transmitted data in cooperative and connected mobility (DATEX-II, n.d.). Data for Road Safety is another EU initiative who has been discussing connected vehicles of all automation levels and gathers partners from the European Commission, industries, and governments to reach cooperative, trustworthy, and free of charge vehicle data exchange with respect to the protection of PD (Data for Road Safety, 2021).

Within the AVENUE landscape, data should be processed with the consideration of the essential factors summarised in Fig. 6.4. It wraps up the GDPR and other aforementioned privacy initiatives recommendations. In other words, it reflects the data controllers’ obligations regarding the data subjects’ rights including the processing restrictions, privacy by design deployment, and consent implementation. From the privacy preserving perspectives, the figure depicts the anonymisation and pseudonymisation challenges. Finally, it calls back the high privacy risks linked to LBS and MaaS which are more likely to be deployed within the CAV’s environment.

Fig. 6.4

Data privacy challenges within the AVENUE environment

3 Methodology

An overall evaluation and recommendations are built based on the final in-vehicle and out-of-vehicle services implemented in AVENUE. A questionnaire was conducted to collect updated inputs from the different key stakeholders. Based on the collected data, the cybersecurity and data privacy mechanisms were assessed per deployment site and service provider. The questionnaire findings were evaluated further by matching the identified surface attacks to required standards from Sect. 6.2. Such mapping supported on providing the recommendations through an SCM defining the required standards to adopt per layer and sub-component of the minibuses’ ecosystem.

To conduct the intended cybersecurity and data privacy assessment, it was crucial to identify the involved service providers and the final AVENUE services. Multiple data collection tools were deployed through several iterations, where questionnaires represented the most relevant source of extensive findings, summarised in Fig. 6.5. The orange entries were substituted by the respondent organisation name and related services. Questions related to hardware attributes were targeting the OEM, and questions on software patterns were designated to software service providers. The questionnaire was shared with several key stakeholders (henceforth providers):

Fig. 6.5

Applications’ service provider questionnaire

(1) Three on-demand service providers, each providing services in one or more deployment sites (SP1, SP2, and SP3); (2) three software developers, developing in-vehicle and out-of-vehicle services (SD1, SD2, SD3); and (3) one OEM responsible for manufacturing the automated minibuses and vehicle operational software. Furthermore, the four public transport operators (TP1, TP2, TP3, TP4) for the deployment sites have been included as well.

The questionnaire consists of 19 questions that are split into 4 main parts. The first section spotlights the applications that are in the AVENUE scope and which are intended to be delivered by the end of the project. With the multiple types of respondents, the first section of the questionnaire aims to identify the site, the application that is or will be deployed, and by whom. Then multiple questions are raised regarding cybersecurity in the second part of the questionnaire with the purpose to highlight the cybersecurity tools, standards, and regulations adopted by the respondent to identify if the mandatory UNECE regulations (R155 and R156) and the key vehicular cybersecurity ISO standards are taken into consideration. The third part of the questionnaire collects information related to data privacy and to the GDPR compliance. Finally, the fourth part gathers any sketched architecture or design that the respondent aims to deploy within the AVENUE project.

4 Findings

From the qualitative analysis perspective, it is noteworthy to highlight that the synthesised outputs from the questionnaire provided valuable findings regarding the final applications and the cybersecurity and privacy governance within AVENUE.

Table 6.1 gives an overview of the various application types and their usage by the operators. During the project’s lifetime, the operators faced numerous challenges, which affected the selection and development of the services that were ultimately realised and utilised thereafter. The presented table abstracts this view and shows the mapping of the applications provided by the various service providers and software developers with the operators. It can be noted that only one service provider (SP1) was utilised by two PTOs. In most cases the service operators provided the client application (a mobile application) and also an application for the safety operator to receive new on-demand trip orders from the client. Meaning, the service provider may send an order through the OEM interface and act as the fleet manager or utilise a semimanual approach by informing the safety operator (from the PTO) to select the destination through the in-vehicle control service (using a touch screen).

Table 6.1 Application type and usage by transport operators

In addition to the applications’ mapping, the questionnaire inputs supported in assessing the cybersecurity governance generally and the code security measures specifically. Prevention, monitoring, and audit tools were gathered from the collected answers. Table 6.2 wraps up the key security measures adopted by every service provider. All respondents are highly concerned with the code vulnerabilities prevention. However, more efforts are still required to conduct continuous assessments and internal and external audits. From the standardisation perspective, valuable inspirations are retrieved from ISO and SAE key standards, while the mandatory UNECE R155 (UNECE R155, 2020) and R156 (UNECE R156, 2020) are still envisioned and planned before end of 2023. Though no accomplished certification or concrete compliance has been recorded yet.

Table 6.2 Code security measures indicated by providers

From the data privacy angle, Table 6.3 showcases how the providers are careful about the GDPR compliance in terms of respect to data processing principles. For key stakeholders who are collecting sensitive data such as personal and location data, their efforts are reflected through the user consent implementation, data storage limitation, and data destruction procedures. Additionally, worthy pseudonymisation techniques are deployed like encryption and tokenisation for authentication. Moreover, at that stage of the mini-shuttle deployment, sharing data with LBS platforms remains limited without claiming any PD. Albeit laudable efforts are adopted by the service providers, data privacy assessments such as DPIA are omitted from the data protection procedures set in the AVENUE project.

Table 6.3 Data privacy measures indicated by providers

5 Discussion and Recommendations

Per the conducted assessment, the cybersecurity and data privacy governance were evaluated including risk prevention, vulnerability management, events monitoring, and data leakage plans. From the aforementioned discussion, the governance strengths can be summarised as follows:

• The AVENUE partners are highly aware of the cybersecurity risks.

• Several “security by design” principles such as risk prevention are considered while implementing AVENUE services.

• The GDPR compliance is a high-priority obligation for all partners.

• The mandatory certifications (CSMS and SUMS) related to the UNECE R155 (UNECE R155, 2020) and R156 (UNECE R156, 2020) are envisioned and planned before end of 2023.

• The V2X immaturity represents an instinctive mitigation solution to the connectivity threats where the minibuses have limited V2I and V2V.

On the other hand, it is noteworthy to spotlight the following weaknesses:

• Albeit the high awareness about the cyber assaults, further thorough implementation of a cybersecurity culture is still required through all the system layers and among all the partners.

• For a flawless cybersecurity governance, the partners’ efforts should not be limited to prevention tools, but it should be broadened to implement monitoring, continuous assessments, and risk mitigation strategies through the overall life cycle including the decommissioning stage.

• Despite the GDPR considerations within the project, an in-depth implementation of the law is still recommended as several obligations are still missing such data privacy assessments.

• There is a scarcity on deploying cybersecurity validation process as no penetration testing is conducted while testing the vehicles on the AVENUE sites.

5.1 Standards Coverage Map

To overcome the asserted hurdles, the CAV’s ecosystem SCM is suggested as a roadmap to be followed by the AVENUE partners upon their provided services and scope. The SCM is foreseen as a suitable approach on building a robust cybersecurity and data privacy governance based on the CAV’s standards and regulation discussed in Sect. 6.2. The map combines both the technical and organisational audit avenues applied to the automated minibuses’ landscape as depicted in Fig. 6.6. The map is classified into four layers, in vehicle, out of vehicle, applications, and organisation, where every layer groups the respective technical standards.

Fig. 6.6

Standards coverage map

As a parent node of the four layers, ISO/SAE 21434(ISO/SAE 21434, 2021) is set as the core standard; however it is very generic to be followed per se. The combination of both generic and technical standards on the SCM is foreseen to overcome the broadening of the ISO/SAE 21434 leading to a more thorough assessment.

The in-vehicle layer addresses the potential attacks at the vehicle level (as discussed in Sect. 6.1.1) which were classified into six sub-layers. First, the sensors category defines the guidance on standardising the interfaces between the different sensors and the fusion unit leading to the automation navigation decisions. Second, the network buses category where standards propose guidelines on detecting intrusions and authentication measures within the in-vehicle communication networks. Third, the ECU standard aims to prevent non-authorised access to the vehicular software modules. Fourth, the software update outlines the directives on how to conduct secure software updates during the vehicle life cycle. Fifth, the artificial intelligence (AI) components standard provides guidance on secure usage of AI-based functions involved on the automation decision-making. Finally, the physical access specifies countermeasures against threats from plugged-in external devices.

Even with a limited V2X implementation within AVENUE, the communication-related recommendations for future development are anticipated. In Fig. 6.6, the out-of-vehicle layer relies on two main categories wrapping standards related to countermeasure CAV’s Internet and V2X threats. To secure the vehicle’s Internet access using DSRC, long-term evolution (LTE), and 5G, standards provided a set of secure channel models and through several use cases. Besides, the multiple V2X communications have been standardised by ISO, ETSI, and SAE. The security credential management standards, which sets V2X certificates security and privacy requirements, define the precise structure, format, and authentication schemes supporting the minibuses’ communication to peer instances. It is noteworthy to mention that other V2X communications such as V2I and vehicle to grid (V2G) have been supported by dedicated standards, while others as per the vehicle to cloud (V2C) is still considered under the umbrella of broad standards like SAE J2735.

Moreover, the application layer consists of two sub-layers reflecting two types of applications: users and ITS. The minibuses’ deployment is associated to the means of several services provided to the end user, such as the on-demand application, and to the smart city. The user application standards focus on data access and cryptography best practices to consider while building interfaces to the CAV’s hardware or software. Likewise, the ITS application standards recommend mechanisms to determine permitted actions among the peer ITS applications to achieve security properties such as authorisation, integrity, and confidentially. Nevertheless, standards such as SAE J2735 and ISO/TS 21177 have a larger scope covering the V2X communication in general and, hence, other subcomponents from the second layer too.

Finally, the organisation layer in Fig. 6.6 incorporates four procedural sub-layers supporting on mitigating the assessed weaknesses in the previous section. The risk assessment reflects evaluation procedures on quantifying the likelihood and impact of cybersecurity threats. The privacy impact assessment wraps standardised procedures, sample reports, and checklists to fulfil. The regulatory obligations sets the mandatory laws that the minibuses’ environment has to comply with, which are summarised into the GDPR, the UNECE R155, and the UNECE R156. Finally, the associate’s authorisation group points out the managerial methods that need to be conducted by the minibuses’ trained associates while facing a cyber threat and processing any PD. The combination of both generic and technical standards on Fig. 6.6 is foreseen to provide a clear roadmap overcoming the cybersecurity and data privacy challenges discussed in the present work.

5.2 Further Recommendations

If a granular certification and standardisation, as recommended by the SCM, bring endeavours and extra efforts to AVENUE partners, we recommend to at least enforce the cybersecurity and data privacy culture through the following key actions:

• Accelerate the compliance process to the UNECE R155 (UNECE R155, 2020) and R156 (UNECE R156, 2020), the new mandatory regulations

• Deploy officially the intended mitigation strategies

• Plan cybersecurity assessments on the organisational and project levels

• Determine clear responsibilities and roles within the AVENUE partners and stakeholders by asserting who are data processors, sub-processors, data controllers, and joint controllers as defined by the GDPR (Regulation (EU) 2016/679, 2016)

• Unify the attack rating approaches among the partners, like threat analysis and risk assessment (TARA) and CVSS approaches

• Maintain permanent and up-to-date risk monitoring through risk matrices for the overall environment not only limited to the vehicle itself

• Conduct data privacy (such as DPIA) and event assessments

• Invest further resources on operators training on cyberattacks to deploy accurate countermeasures on real time while supervising the minibuses

• Identify clear procedures and plans in case of a data leakage

5.3 Assessment Limitations

With the CAVs’ market evolution and rivalry, the automated minibuses are still foreseen as a black box for partners who are not OEMs or hardware providers. It is true that with less knowledge about the embedded technologies and the monitoring tools, the CAV can benefit from higher protection from cyberattacks. However, as security practices dictate, security by obscurity is not a viable solution in the long term. Furthermore, such shelter can represent a blocking wall for a granular cybersecurity and data privacy assessment.

Standards from various standardisation bodies at any stage, published or work in progress, change very often which requires a recurrent update of the SCM. As a matter of fact, the SCM should be updated frequently to cope with the evolving regulation and standardisation bodies publications.

6 Conclusion

As the public transport sector is dipping their toes into utilising the latest CAV technologies with the vision of offering on-demand, door-to-door, automated fleet of minibuses, this chapter brought forth the concerns regarding the cybersecurity and data privacy. As these vehicles are highly digitised and connected, they are not only prone to the same threats as traditional Internet connected devices but also affected by additional vulnerabilities due to their non-static behaviour and physical outdoor exposure. This was illustrated through two main attack vectors, namely, in-vehicle and external communications, and further briefly overviewed the related standards and regulations applicable in the domain.

As a use case the perceptiveness of the public transport operators, OEMs, and service providers (involved with or affiliated to the EU AVENUE project) was analysed through a questionnaire, with the outset to investigate if cybersecurity is taken thoroughly into account and integrated at an early stage. As per general observations, a great focus lies on getting the CAVs running and integrating the right services in place, where cybersecurity and privacy may easily become an afterthought. The outcome shows that cybersecurity and privacy are considered and several strategies are in place by the respective parties. However, instead of being pushed by regulations, more emphasis needs to be in place to naturally woven into the development process and life cycle of any related soft- and hardware development. For example, the OEM adheres the most for its implementation, but as the manufacturer of a CAV, they are under close observation of all the safety and security standards regulations, whereas any service developer and/or fleet managers who are providing higher level (software) functionalities are not.

From the assessment, a further set of recommendations is rationalised, and a standards coverage map is presented that organises known standards and legal policies into several layers (categories). It aims to provide a roadmap to ease the integration of cybersecurity and data privacy aspects. Finally, some limitations of the current work are pointed out attributed to the fast changing landscape of standards and regulations, as well as limited transparency due to highly competitive market and therefore reluctance of providing insights in ongoing/active developed products.