The connectedness of today’s cars to the broader digital ecosystem introduces cybersecurity risks that original equipment manufacturers (OEMs) must identify and address. These risks include not only a data breach that could expose the intimate details of an individual’s life but, even more critically, threats to the physical safety of a vehicle’s occupants.

This final installment in a four-part article series on connected cars explores the technical and legal issues surrounding the cybersecurity of connected cars. It provides an overview of the legal regime governing vehicle cybersecurity, examines potential vulnerabilities and offers best practices for implementing a cybersecurity and incident response framework, with insights from Exponent, McDermott, Will & Schulte and Morrison Foerster. Part one covered FTC enforcement activity related to connected vehicles, part two discussed the legal framework and part three examined privacy compliance issues.

See “What International Companies Should Do to Comply With the E.U. Cyber Resilience Act” (Jan. 28, 2026).

E.U. and U.S. Legal Landscape

The cybersecurity of connected cars is governed by different legal frameworks in the U.S. and E.U., as well as by industry standards and best practices. While other countries have relevant requirements, the discussion below addresses U.S. and E.U. laws and guidance.

U.S.

Connected cars are a “highly unregulated industry right now,” Summer Fowler, corporate VP and principal at Exponent, told the Cybersecurity Law Report.

At a high level, connected car companies can be subject to overlapping cyber frameworks, but it depends on a number of factors and where they sit in the regulatory ecosystem. In general, the U.S. has a somewhat “disjointed approach” to regulating cybersecurity since “there isn’t one single uniform law that applies across the board,” Morrison Foerster partner Kaylee Bankston said. The various regulators, each with their own jurisdiction, approach cybersecurity from different angles, she noted.

Many existing laws regulating cybersecurity that would be applicable to connected cars focus on prohibiting unfair and deceptive acts and practices and protecting individual privacy rather than mandating prescriptive safety measures, Bankston explained. The FTC is “generally viewed as the lead federal regulator in the U.S. on cyber and privacy matters under its Section 5 authority,” with a main focus on protecting against unfair and deceptive acts and practices, she said. 

To the extent automakers are public companies, they also would be subject to SEC cybersecurity rules that require disclosure of material cyber incidents and disclosures regarding the company’s approach to cyber risk management and governance.

State unfair, deceptive or abusive acts or practices laws are also leveraged to regulate cybersecurity (as well as privacy) from a consumer protection standpoint, Bankston noted. Similar to the FTC Act, they prevent consumer harm by prohibiting false or misleading statements about a company’s cybersecurity policies, she stated.

In addition, every state has a data breach notification law that primarily focuses on “notification obligations when an individual’s personal information has been subject to a security breach,” she explained.

Furthermore, Bankston continued, proposed regulations under the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) are pending. They would impose a short timeframe (72 hours) for mandatory reporting on critical infrastructure industries whose systems are affected by covered cyber incidents, “though it is unclear how the final rules may differ from the current proposal,” she noted. “As proposed, CIRCIA would be a marked shift in U.S. cybersecurity notification laws, emphasizing operational disruption and system resilience rather than the traditional focus on breaches of personal information,” she emphasized.

There is a trend toward more prescriptive cybersecurity requirements, as reflected in some state regulations and consent orders issued in enforcement actions brought by the FTC and state AGs, Bankston observed. Whereas five or 10 years ago regulations may have afforded great flexibility for a company to determine what constitutes “reasonable” cybersecurity protection for its organization, “we’re seeing more regulators and legislators trying to tell companies what reasonable is by setting forth specific security controls that need to be implemented,” she observed.

See “CISA’s Proposed Rule for Critical Infrastructure Cyber Incident Reporting: How Organizations Can Prepare and Engage” (May 29, 2024).

Europe

In the E.U., applicable cybersecurity laws and regulations include the NIS2 directive, the Cyber Resilience Act (CRA) and General Safety Regulation (GSR) (EU) 2019/2144, Alex van der Wolk, a partner at Morrison Foerster, told the Cybersecurity Law Report.

The NIS2 regulates cybersecurity at the organizational and manufacturing levels. In turn, the CRA and GSR concern products with digital elements, with the GSR regulating the cybersecurity of the vehicle as a product, and the CRA regulating the non-vehicle components of the car, for example, the car app or charging stations, van der Wolk said. The CRA and GSR in regard to vehicles are “different sides of the same coin,” he explained.

The GSR does not contain cybersecurity requirements itself but operates by incorporating UN Regulations Nos. 155 and 156, which contain detailed cybersecurity rules throughout the vehicle lifecycle and software updates, van der Wolk clarified.

In addition, the Radio Equipment Directive governs the wireless connection between the key or app and the car, van der Wolk said.

Other Guidance

In addition to laws and regulations, OEMs look to guidance from other sources that do not have the force of law.

The standards that the U.S. auto industry primarily looks to are published by the International Organization of Standards (ISO) - particularly ISO 21434, which addresses cybersecurity engineering across vehicle life cycles; ISO 26262, which relates generally to functional safety; and ISO 21448, which concerns the safety of the intended functionality of vehicles, Fowler explained. Additionally, for automated vehicles, the Society of Automotive Engineers has some taxonomies and standards for cybersecurity, she said.

Some guidance is issued by U.S. administrative agencies. For instance, the National Highway Transportation Safety Administration has issued cybersecurity best practices guidance for connected cars, Fowler noted.

The National Institute of Standards and Technology’s (NIST) Cybersecurity Framework (CSF) 2.0 also provides guidance. “The NIST CSF is one leading recognized framework, particularly in the U.S. So, if companies in this space are aligning to that, they are heading in the right direction,” Bankston remarked.

Connected Vehicle Vulnerability and Risk

Vulnerability Points

Connected car vulnerabilities can arise at every stage of the vehicle lifecycle, from initial design through end of life.

A vehicle’s connection to outside systems “in and of itself creates potential vulnerability and exposure,” Bankston explained. In addition, “multiple parties may be involved in developing the different systems – the firmware and the software – that are leveraged by the vehicle,” she noted. This creates supply chain risks that must be managed, she said.

“Any time a system takes inputs from another system, there’s a susceptibility, there’s some risk,” McDermott partner Stephen Reynolds told the Cybersecurity Law Report. As cars become increasingly connected, there is more risk that some of the inputs that they receive, whether through over-the-air software updates or by talking to each other, contain malware, he said.

Reynolds suggested that malware is “less likely” to be introduced via software updates because hash values can help verify an update’s integrity. Rather, the “greater risk” comes from the use of open-source code or a software library that contains malicious code, he explained. “We haven’t seen that specifically in the automotive industry, but we have seen that generally in cyberattacks,” he stated.

One way bad actors create vulnerability is through a denial-of-service attack, in which an attacker floods a target such as the vehicle’s telematics or infotainment interface, a companion mobile app/API or even the OEM’s backend servers with traffic or messages until the system becomes overwhelmed, Reynolds added.

Safety and Data Breach Risks

Cybersecurity concerns about connected cars center on safety and data protection.

Safety Risks

Most cybersecurity concerns about connected cars relate to vehicle actuation – the control of car systems such as acceleration, braking and steering – which implicates safety, Fowler observed. That is more of a critical concern than the negative consequences that could flow from a data breach, she opined.

The principal security issue, van der Wolk concurred, is the risk that “someone takes over your car.” A bad actor could lock someone out of their car or tamper with the vehicle’s safety features, he said.

Data Breach Risks

Data can be vulnerable regardless of whether it is stored on a vehicle, in the cloud or in transit, Fowler emphasized.

Because the data collected by a connected car creates an intricate profile of a user, there is a real risk that in the event of a breach the data could be exploited for nefarious purposes, van der Wolk cautioned.

To access proprietary and confidential information, bad actors could hack a company’s servers and then threaten to publish the information if they are not paid, Reynolds explained. There is also the risk of a ransomware attack, where a bad actor hacks an OEM’s system, encrypts files that prevent the computer systems with which cars interface from running and demands money in exchange for the keys, he added.

See “Strengthening Cyber Defenses in an Ever-Evolving Threat Landscape” (Jun. 4, 2025).

Managing Cybersecurity Across the Vehicle Lifecycle

Managing connected car cybersecurity requires applying core information security principles across the vehicle lifecycle – from design and supplier management to authentication, layered defenses, updates and incident response.

Apply General Security Principles

Information security protections and principles that apply generally apply equally to connected cars, Reynolds noted. “A good cybersecurity framework is built on security by design. Some applicable general protections and principles include, according to Reynolds:

• Failing Safely. Since, more so than in other domains, safety in the automotive space is “paramount,” OEMs should apply the fail-safe principle. That concept holds that a failing system should default to a predefined safe state. For example, if for some reason a computer cannot access a server for authentication, it could either use a fallback authentication method or deny the request.
• Layering Defense. Another guiding principle is defense-in-depth. OEMs should utilize multiple defense layers – a good analogy is a medieval castle with a moat, gates and archers.
• Strict Access Controls. One example is multifactor authentication, for both humans and between connected car systems.
• Strong Supply Chain Management. As discussed more fully below, reasonable due diligence of suppliers and vendors to ensure partners maintain defensible security practices is important.
• Updates. Automatically installing critical updates or checking for updates prior to installing new software is another good practice.
• Zero Trust Architecture. OEMs should assume a zero-trust environment – that an attacker will access the system – and have the tools in place to monitor them.

Take a Lifecyle Approach

An OEM designing a connected vehicle and related software should take a lifecycle approach to cybersecurity, Fowler recommended. Cybersecurity planning needs to start early in the development cycle and cannot be “screwed on to the end,” she emphasized.

Software should be code signed, that is, the developer should attach a digital signature using cryptography, to ensure that the software engineering and booting processes are secure, Fowler advised. That way, the OEM can be sure that code booted onto the vehicle, either initially or through an over-the-air update, is what it says it is, she explained. Companies can also conduct secure code analysis, a process by which software is run through software composition analysis tools that look for known vulnerabilities or bad practices, such as hard-coding passwords, she recommended.

The vehicle should also have a secure communications architecture among its various systems – for example, signals a camera sends to the automated driving system (ADS) – to ensure that those systems communicate with the same path and those communications are secure, Fowler suggested. This can be done through certificates, encryption and secure tunneling paths, she said.

Communications with external systems such as satellites, other vehicles or infrastructure such as stoplights should also be made secure, Fowler urged.

Measures also should be taken to ensure that a vehicle’s code is not modified during maintenance, Fowler advised.

Likewise, there should be an end-of-life process that secures the information after the car is retired, Fowler said. “It’s layering security at every single point that things happen,” she explained.

Undertaking a Risk Assessment

Conducting a risk assessment is an essential part of an effective cybersecurity plan for OEMs.

Begin at the Design Phase

Like the implementation of cybersecurity measures, a risk assessment should also begin in the design phase. At this stage, companies should evaluate the vehicle’s overall system design and conduct an attack surface analysis, Fowler advised.

The assessment involves identifying where an attacker could potentially enter or move through the system (including interfaces and data flows) and mapping key trust boundaries, such as points where data or commands cross from one component to another, Fowler continued. It also should identify risks posed by external attack surfaces, such as internet-facing systems, and by internal attack surfaces that facilitate lateral movement within the network, she instructed.

Understanding the intended use of data is a critical part of the analysis. How data will be stored, transmitted and used will help determine the scope of the attack surface, Fowler noted, which can extend across virtually all of the vehicle’s components.

Decisions about data storage, however, are less about selecting the “most secure” location and more about applying appropriate controls, Fowler explained. Wherever data resides, the level of controls should match its criticality, she advised.

Conduct Regular Penetration Testing and Threat Modeling

OEMs should routinely conduct penetration testing and threat modelling to uncover any vulnerabilities that can be exploited and what risks that poses, Bankston suggested.

A holistic approach to cybersecurity requires OEMs to test system defenses by actively trying to “break the car,” including individual components, van der Wolk added.

Seek Stakeholder Input

A comprehensive risk assessment process should seek input from a company’s stakeholders. “Oftentimes we just interview key stakeholders,” Reynolds said. Open-ended questions offer employees an opportunity to discuss their cybersecurity concerns, he stated. “We often start with somewhat of a questionnaire” from which we put together a “risk matrix” outlining the highest risks and what can be mitigated and then develop a roadmap and set priorities, he explained.

Develop a Mitigation Plan

Once the assessment has identified the risks, companies should start mitigation planning, including examining what type of authentications and encryption is needed to reduce vulnerabilities, Fowler said. Business considerations and trade-offs come into play here, since “the greatest and most secure system is probably unaffordable,” she explained. The starting point is addressing anything that could put people at risk and then working outwards from there, she suggested.

An OEM should approach a risk assessment by thinking like the adversary – asking what bad actors could do if they gain control of a car system and reviewing the mitigations in place to prevent such harms, Bankston advised. The company should review whether its controls are defensible and document its analysis and conclusions as proof of review, she added, recommending that, for each system, the degree of controls should be appropriate to the level of risk.

See “Unifying Risk Assessments: Breaking Silos to Enhance Efficiency and Manage Risk” (Jan. 29, 2025).

Securing the Supply Chain

Good cybersecurity practices require good supply chain hygiene. Both vehicle manufacturers and suppliers should conduct reasonable due diligence of their respective suppliers and vendors to ensure that their partners maintain defensible security practices, Bankston recommended.

Vehicle manufacturers can ask suppliers about security practices related to product development, including how vulnerabilities are identified and tested, and the company’s incident response capabilities, Bankston elaborated. They can also ask for a SOC 2 report, which is a third-party evaluation of a company’s security practices, she suggested. Suppliers should extend similar diligence to their own suppliers, “reinforcing a cascading approach to supply chain risk management,” she said. As technology evolves, manufacturers and suppliers should periodically revisit these questions at “reasonable intervals” to ensure that their respective suppliers’ practices continue to be defensible, she recommended.

Supplier contracts should contain adequate representations regarding the security practices associated with the development of their product and requirements to timely report any vulnerabilities, Bankston instructed. Ideally, the contracts should grant the right to assess or audit the vendor’s security practices, she stated.

Since software is often changing, it requires constant monitoring for vulnerabilities and necessary patching. Thus, manufacturers and suppliers should also ensure that software and firmware contracts specify who is responsible for testing, validation and maintenance, Bankston suggested.

Establishing Organizational Governance

“In today’s world, it’s pretty well accepted that cybersecurity is an enterprise-level risk,” Bankston observed. Information security governance extends “all the way to the top,” with increasing expectations that a company’s board and executive team understand the cybersecurity risks to their organization, she said. In addition to the IT and security teams, companies should involve their executive, legal and business line teams as appropriate to create a “strong security culture,” she stated. And since “humans will always be the weakest link,” employee training and awareness is critical, she advised.

Planning and Implementing Incident Response

One thing that sets connected car incidents apart from other IoT products is that an incident can put lives at risk, van der Wolk said. “The worst-case scenario for the automotive industry is pretty much as bad as it gets,” he emphasized. An incident response plan should account for that possibility, he advised.

“A good incident response plan will essentially serve as an incident remediation roadmap, featuring key stakeholders, communications protocol and the steps needed to get systems back up,” Reynolds said.

Creating an Actionable Playbook

An incident response plan should be an actionable framework document, sufficiently detailed to give direction and the authority to execute on specific tasks, yet allowing for the flexibility that will “inevitably” be needed during a security incident, Bankston advised.

The plan should clearly assign roles – who is in charge, who is taking notes, who is capturing the logs, Fowler recommended. Establishing clear communication paths – knowing who should communicate with whom and who should prioritize what – is also extremely important, she said.

A good plan has “everyone singing from the same song sheet, particularly as it relates to escalations, prioritization, and decision-making authority,” Bankston emphasized.

Testing the Plan

The incident response plan should also be tested – technical or executive tabletop exercises can give stakeholders an opportunity to speak freely and openly about any security gaps, Bankston said. These can be “really helpful in bringing to life the controls that the company has on paper,” she stated. A tabletop exercise may reveal deficiencies that were not apparent when conducting the risk assessment or formulating the incident response plan, she explained.

See our two-part series on a ransomware tabletop’s 360‑degree incident response view: “Days One to Four” (Jan. 4, 2023), and “Day Five Through Post-Mortem” (Jan. 11, 2023).

Navigating the Response

Following Internal and External Communications Protocols

“Communications are a critical part of any security incident response” and are “often where companies get it wrong, either because they try to inadvertently downplay the incident or the opposite,” Bankston cautioned.

For client communications, it is essential to set up a secure channel, Reynolds stated. “I don’t want the hackers reading my messages to my client or knowing what we plan to do,” he emphasized. Establishing, prior to the breach, a communications protocol for outside parties is also necessary to ensure that company messaging is truthful, accurate and consistent, and includes all relevant facts, he explained. “It’s important to make sure folks are sticking to a known set of facts and not speculating,” he stressed.

Regardless of the audience – a vendor, the government, a partner – companies should not say anything misleading, Bankston insisted. If a company interacts with more than one entity or audience, it should be consistent in its messaging, she said. “Consistency . . . is critical truth,” she emphasized.

See “When the Phones Ring: What 100 Security Breaches Reveal About Candor, Fear and Trust in Crisis” (Apr. 1, 2026).

Eradicating the Threat

Another crucial early step following a breach is eradication, which involves containing and expelling the attackers from all systems. After that, the company should monitor to ensure that all systems are clean, Reynolds said. These tasks are usually done by a third-party forensics vendor or consultant that also furnishes information to outside counsel so they can provide legal advice regarding the incident, he explained.

During this process, data preservation is essential to maintain the company’s ability to determine the root cause of the incident, Fowler highlighted.

Conducting an Investigation

Following eradication, the focus shifts to investigation, which is important because it may be difficult to identify the attacker’s entry point, Reynolds said. “Finding the entry point for any attacker is difficult, but especially for an attacker that might be leveraging a system remotely,” he noted. To help mitigate future risks, the company should create an attack timeline that highlights what vulnerabilities were leveraged, he stated.

Determining Reporting Obligations

The OEM must also determine what its legal obligations are with respect to the incident, including any reporting obligations to consumers, vendors and regulators, Reynolds said.

In the U.S., when CIRCIA provisions become effective, they will require critical infrastructure entities, which are defined broadly, to report any cybersecurity incidents within 72 hours, Reynolds noted. Public companies may also have SEC reporting deadlines, he said, adding that reporting periods under state breach laws are longer, between 10 and 30 days. Further, companies may also be contractually required to notify vendors.

A cybersecurity breach raising a physical safety issue may warrant quicker notification than a pure PI breach even if not strictly legally required “because the consequences of security vulnerabilities potentially impacting the physical operation of a vehicle could be grave,” Bankston noted.

Conducting a Postmortem

One important step that often gets overlooked is conducting a postmortem analyzing not only how the incident happened, but also how the company could have responded better to the incident and what incident responses or procedures should be changed, Reynolds observed. The postmortem process “will vary drastically between organizations and between the type of cyber event, but I think it’s a very important step and helps folks get better,” he emphasized.