The automotive industry’s cyber-risk curve has steepened sharply: high-severity vulnerabilities more than doubled in the second quarter of 2026, rising from 75 in Q1 to 161 in Q2, according to PCA Cyber Security’s latest sector analysis. Across 345 unique automotive vulnerabilities, the most worrying pattern was not simply volume, but the combination of impact and accessibility: a large share could potentially expose sensitive data, compromise privacy, or affect significant vehicle functions without requiring highly sophisticated attacker preparation. PCA Cyber Security’s reported findings
That is an uncomfortable development for an industry built around the promise of the software-defined vehicle. Cars are becoming more capable because they are connected to cloud platforms, mobile applications, charging infrastructure, fleet-management systems, dealerships, and a global software supply chain. Yet every one of those integrations adds code, credentials, data flows, remote-management interfaces, and potential failure points.
For Windows users and IT administrators, the story extends far beyond what happens inside a vehicle dashboard. Automotive businesses increasingly depend on Windows endpoints in dealerships, workshops, logistics centers, engineering teams, and supplier networks. A vulnerability in the broader ecosystem can disrupt data access, service scheduling, valuation systems, customer records, diagnostics, and business operations even when the vehicle itself is not directly compromised.
PCA Cyber Security’s Q2 analysis examined 345 automotive-sector vulnerabilities, with 161 categorized as high severity. The report’s definition is appropriately consequential: these are flaws that could be exploited to control major vehicle functions, access sensitive personal information, or undermine driver privacy. The reported Q2 breakdown suggests that automotive cybersecurity is no longer a niche engineering concern reserved for advanced research labs.
The jump from 75 to 161 high-severity findings represents more than a routine quarter-to-quarter fluctuation. It points to an environment where researchers, defenders, and criminal groups are spending more attention on systems that offer a greater operational payoff. A flaw that affects one infotainment unit may be serious; a flaw in a backend platform, charging identity system, supplier portal, or shared vehicle-management product can have a much broader blast radius.
That distinction is central. The automotive attack surface is now distributed across several layers:
The U.S. National Highway Traffic Safety Administration defines automotive cybersecurity broadly as protecting vehicle electronic systems, communications networks, software, users, and underlying data from malicious attack, damage, unauthorized access, or manipulation. That framing is important because it recognizes that the security target is not limited to steering, braking, or acceleration. It includes the information and infrastructure surrounding the car. NHTSA’s automotive cybersecurity overview
That does not mean every reported automotive vulnerability can instantly commandeer a moving vehicle. Severity labels depend on the affected component, required access, preconditions, mitigations, and the way systems are segmented. But the category matters because vulnerabilities in vehicle-adjacent systems may create pathways to personal information, remote services, operational networks, or systems that influence real-world behavior.
The security challenge also has an unusually long lifespan. A laptop might be replaced after three to five years, while vehicles can remain on roads for more than a decade. Their support chains can include original manufacturers, component suppliers, dealership service departments, insurers, fleet operators, independent repairers, and second-hand owners.
This lifecycle problem is reflected in ISO/SAE 21434, the automotive cybersecurity engineering standard. It addresses cybersecurity risk management across the lifecycle of road-vehicle electrical and electronic systems, from concept and development through production, operation, maintenance, and decommissioning. ISO’s overview of ISO/SAE 21434 The inclusion of decommissioning is particularly relevant when used vehicle electronics retain historical data.
PCA’s reported second-hand head-unit example illustrates why that lifecycle view matters. Researchers reportedly recovered unencrypted information from a used vehicle component that could reveal a previous owner’s vehicle history and personal data. The second-hand data exposure case The lesson is straightforward: deleting an account, selling a car, or replacing a head unit does not automatically guarantee that data has been securely removed.
Connected cars can handle a substantial amount of sensitive information, including:
This deserves careful interpretation. “Local” does not mean “harmless,” and it does not necessarily mean an attacker must sit in the driver’s seat. Vehicles pass through workshops, dealership lots, ports, rental fleets, repair centers, body shops, auctions, and corporate facilities. Diagnostic devices, removable media, engineering interfaces, and privileged service tools all create opportunities that must be governed.
For IT teams, Local Shell findings reinforce a security principle that applies equally to PCs, servers, and vehicles: debug access is production access unless it is deliberately removed, restricted, authenticated, logged, and monitored.
Automotive organizations should treat local interfaces as critical assets rather than mere maintenance conveniences. That means controlling who can connect, what tools they can use, whether software signatures are validated, and whether actions are attributable to an authenticated technician or system.
That does not mean 94% are universally easy to exploit in real-world conditions. Attack complexity is only one part of risk. An exploit might still require physical proximity, a certain firmware version, authenticated access, a specific configuration, or a vulnerable third-party service.
Still, low complexity matters because it reduces the friction between disclosure and misuse. When a vulnerability requires rare expertise, costly hardware, and a bespoke research setup, fewer adversaries can act on it. When it can be reproduced with ordinary tools, known credentials, exposed interfaces, or predictable workflows, the threat pool expands.
The rise of automation compounds the problem. PCA CTO Vlad Ryabyshkin argued that increased automation of vulnerability discovery and exploitation is pushing researchers and attackers toward higher-risk opportunities with broader reach. Ryabyshkin’s comments on automation and supply-chain targeting AI-assisted research does not eliminate the need for technical skill, but it can accelerate reconnaissance, code analysis, configuration discovery, proof-of-concept development, and targeting.
PCA highlighted white-hat research involving cloud-based authentication systems associated with rentable EV chargers, shared e-bikes, and e-scooters. The reported work showed how remotely manipulated authentication mechanisms could create disruption across parts of urban transport infrastructure. The report’s mobility-platform example
This is a key evolution in automotive cybersecurity. The most valuable target may not be an individual vehicle’s onboard computer. It may be the platform that authorizes a large group of users, allocates chargers, processes fleet telemetry, manages reservations, or distributes configuration changes.
A compromised charging platform might not directly alter a car’s safety systems, but it could still produce meaningful disruption:
That creates an incentive for attackers to favor centralized infrastructure over isolated endpoints. A vulnerability affecting a common cloud component may offer more leverage than a flaw tied to a particular car model or firmware release.
This is why security architecture must assume that backend systems are part of the vehicle environment. Treating cloud services as separate “IT” and vehicle electronics as “product security” can leave dangerous accountability gaps between teams.
That dependency is why supply-chain breaches can be so damaging. PCA’s report cited a ransomware incident affecting a UK automotive data and vehicle-valuation provider, reportedly leaving dealers, insurers, and original equipment manufacturers unable to access critical information and creating what was described as a regional valuation blackout. The reported automotive data-provider disruption
The incident is a useful reminder that automotive resilience depends on far more than production lines. Vehicle valuations, finance decisions, insurance workflows, trade-in transactions, parts ordering, repair estimates, registrations, and dealer sales processes can all depend on external data platforms.
When one of those services fails, organizations may still have vehicles, employees, and customers—but lack the data needed to transact normally.
That strategy makes sense from an attacker’s perspective. A large manufacturer may have a mature security operation, dedicated incident-response personnel, hardened infrastructure, and extensive monitoring. A smaller supplier might have fewer resources, older systems, inconsistent identity controls, weaker segmentation, or limited ability to detect intrusion.
PCA cited claims involving a Japanese automotive component maker, a Canadian parts retailer and distributor, and a major Indian electronics contract manufacturer. In the latter case, the World Leaks extortion group was said to have published more than 630 GB of stolen data across more than 200,000 files, including confidential engineering documents allegedly associated with a major EV manufacturer. The reported extortion-group cases
As with many ransomware and extortion claims, the specific scope and contents of a purported data theft should be treated cautiously until independently verified by the affected organizations. But the strategic risk is indisputable: a compromise at one supplier can expose information and operations tied to numerous customers.
UN Regulation No. 155 requires cybersecurity management processes that cover development, production, and post-production, as well as monitoring, detection, response, risk treatment, and the management of dependencies involving contracted suppliers and service providers. UNECE documentation describing UN R155 cybersecurity-management requirements
The UK Vehicle Certification Agency similarly notes that UN R155 covers vehicle cybersecurity and cybersecurity management systems, while UN R156 covers software-update management. It also emphasizes the relationship between these requirements and ISO/SAE 21434, as well as ISO 24089 for software updates. UK VCA guidance on cyber security and software updating
For suppliers, the implication is unavoidable: cybersecurity capability is becoming part of the qualification process, not a nice-to-have differentiator.
An SBOM, or software bill of materials, is essentially an inventory of the components and dependencies contained in a software product. In automotive use, that inventory can become complicated quickly: a vehicle may contain dozens of electronic control units, each with separate firmware, libraries, operating environments, supplier code, open-source components, and hardware dependencies.
A spreadsheet listing a few component names is not enough. The inventory needs to identify versions, relationships, suppliers, update status, and the systems in which a component actually runs. The U.S. Cybersecurity and Infrastructure Security Agency says an SBOM should cover all components in the target software, including transitive dependencies, and should be updated with each software version or release. CISA’s SBOM minimum-elements guidance
For Windows-based automotive environments, this same discipline should include service laptops, workshop PCs, diagnostic servers, application gateways, engineering workstations, Active Directory infrastructure, remote-access tools, and third-party data integrations. The boundary between “enterprise IT” and “vehicle security” is increasingly artificial.
NHTSA’s cybersecurity best-practices guidance stresses that organizations across the automotive supply chain have a role in vehicle cybersecurity and should establish clear cybersecurity expectations for suppliers while verifying implementation. NHTSA’s cybersecurity best-practices document
A stronger response should include the following priorities.
The inventory should answer basic questions quickly:
Organizations should also audit temporary exceptions. Factory modes, developer accounts, test certificates, service passwords, and diagnostic privileges often become security liabilities when they outlive their original purpose.
Security testing should therefore model complete paths—from mobile app to cloud service, from diagnostic tool to ECU, and from supplier portal to engineering repository. The goal is not merely to find vulnerabilities in isolation, but to understand how they can be chained.
That includes checking for failed over-the-air updates, offline vehicles, devices with unsupported firmware, configuration drift, and systems excluded from routine update workflows. The objective is to know what remains exposed, not merely what has been scheduled for remediation.
PCA Cyber Security’s findings—161 high-severity vulnerabilities among 345 total, a leading role for Local Shell access, and a reported 94% low-complexity share—should be read as a warning about exposure management rather than as a prediction of inevitable catastrophe. PCA’s Q2 automotive vulnerability analysis The greatest risk is not that every vulnerability will be exploited; it is that organizations will discover too late that their systems were more connected, less visible, and more dependent on third parties than their security models assumed.
The industry’s answer cannot be a manual spreadsheet, a once-a-year penetration test, or a patch policy that stops at the corporate network. It must be continuous: complete component visibility, verified remediation, rigorous supplier governance, secured diagnostic access, monitored cloud services, and an incident-response plan that reaches every part of the automotive ecosystem.
As vehicles become increasingly software-defined, cybersecurity will no longer be a supporting engineering function. It will be a core requirement for trust, safety, availability, privacy, and the basic ability of the automotive industry to keep moving.
That is an uncomfortable development for an industry built around the promise of the software-defined vehicle. Cars are becoming more capable because they are connected to cloud platforms, mobile applications, charging infrastructure, fleet-management systems, dealerships, and a global software supply chain. Yet every one of those integrations adds code, credentials, data flows, remote-management interfaces, and potential failure points.
For Windows users and IT administrators, the story extends far beyond what happens inside a vehicle dashboard. Automotive businesses increasingly depend on Windows endpoints in dealerships, workshops, logistics centers, engineering teams, and supplier networks. A vulnerability in the broader ecosystem can disrupt data access, service scheduling, valuation systems, customer records, diagnostics, and business operations even when the vehicle itself is not directly compromised.
Overview: The Numbers Matter, but the Pattern Matters More
PCA Cyber Security’s Q2 analysis examined 345 automotive-sector vulnerabilities, with 161 categorized as high severity. The report’s definition is appropriately consequential: these are flaws that could be exploited to control major vehicle functions, access sensitive personal information, or undermine driver privacy. The reported Q2 breakdown suggests that automotive cybersecurity is no longer a niche engineering concern reserved for advanced research labs.The jump from 75 to 161 high-severity findings represents more than a routine quarter-to-quarter fluctuation. It points to an environment where researchers, defenders, and criminal groups are spending more attention on systems that offer a greater operational payoff. A flaw that affects one infotainment unit may be serious; a flaw in a backend platform, charging identity system, supplier portal, or shared vehicle-management product can have a much broader blast radius.
That distinction is central. The automotive attack surface is now distributed across several layers:
- Vehicle hardware and electronic control units
- Infotainment and telematics platforms
- Mobile apps and remote-control services
- Over-the-air update systems
- Charging and energy-management networks
- Dealer and workshop diagnostic environments
- Cloud authentication and fleet platforms
- Component makers, engineering contractors, and software suppliers
The U.S. National Highway Traffic Safety Administration defines automotive cybersecurity broadly as protecting vehicle electronic systems, communications networks, software, users, and underlying data from malicious attack, damage, unauthorized access, or manipulation. That framing is important because it recognizes that the security target is not limited to steering, braking, or acceleration. It includes the information and infrastructure surrounding the car. NHTSA’s automotive cybersecurity overview
Why “High Severity” Carries a Different Weight in Automotive Security
In ordinary enterprise IT, a severe vulnerability may expose databases, interrupt business processes, or enable ransomware. In automotive environments, the potential consequences can merge cybersecurity, privacy, operational resilience, and physical safety.That does not mean every reported automotive vulnerability can instantly commandeer a moving vehicle. Severity labels depend on the affected component, required access, preconditions, mitigations, and the way systems are segmented. But the category matters because vulnerabilities in vehicle-adjacent systems may create pathways to personal information, remote services, operational networks, or systems that influence real-world behavior.
The security challenge also has an unusually long lifespan. A laptop might be replaced after three to five years, while vehicles can remain on roads for more than a decade. Their support chains can include original manufacturers, component suppliers, dealership service departments, insurers, fleet operators, independent repairers, and second-hand owners.
This lifecycle problem is reflected in ISO/SAE 21434, the automotive cybersecurity engineering standard. It addresses cybersecurity risk management across the lifecycle of road-vehicle electrical and electronic systems, from concept and development through production, operation, maintenance, and decommissioning. ISO’s overview of ISO/SAE 21434 The inclusion of decommissioning is particularly relevant when used vehicle electronics retain historical data.
PCA’s reported second-hand head-unit example illustrates why that lifecycle view matters. Researchers reportedly recovered unencrypted information from a used vehicle component that could reveal a previous owner’s vehicle history and personal data. The second-hand data exposure case The lesson is straightforward: deleting an account, selling a car, or replacing a head unit does not automatically guarantee that data has been securely removed.
Privacy Is an Automotive Security Issue
The public conversation around automotive hacking often gravitates toward dramatic scenarios involving remote vehicle control. Those risks deserve attention, but privacy failures can be both more common and more immediately exploitable.Connected cars can handle a substantial amount of sensitive information, including:
- Contact lists and call histories synchronized from phones
- Location history and route destinations
- Vehicle identification data
- Service and maintenance records
- Charging and payment-related account data
- Remote app credentials and access tokens
- Audio, messages, or personal settings stored by infotainment systems
Local Shell Dominance Is a Reminder That Physical and Service Access Still Matter
Among 14 entry methods identified in PCA’s Q2 findings, Local Shell was the most common, accounting for 28% of vulnerabilities. The term generally refers to command-line-level access to an onboard computing environment, potentially obtained through diagnostic ports, debug interfaces, maintenance connections, or other locally accessible mechanisms. PCA’s reported entry-point analysisThis deserves careful interpretation. “Local” does not mean “harmless,” and it does not necessarily mean an attacker must sit in the driver’s seat. Vehicles pass through workshops, dealership lots, ports, rental fleets, repair centers, body shops, auctions, and corporate facilities. Diagnostic devices, removable media, engineering interfaces, and privileged service tools all create opportunities that must be governed.
For IT teams, Local Shell findings reinforce a security principle that applies equally to PCs, servers, and vehicles: debug access is production access unless it is deliberately removed, restricted, authenticated, logged, and monitored.
Automotive organizations should treat local interfaces as critical assets rather than mere maintenance conveniences. That means controlling who can connect, what tools they can use, whether software signatures are validated, and whether actions are attributable to an authenticated technician or system.
The Low-Complexity Concern
PCA also reported that 94% of the quarter’s vulnerabilities involved low attack complexity. In practical terms, the report characterized these as flaws that often do not require specialized tools or extended preparation to exploit. The reported low-complexity figureThat does not mean 94% are universally easy to exploit in real-world conditions. Attack complexity is only one part of risk. An exploit might still require physical proximity, a certain firmware version, authenticated access, a specific configuration, or a vulnerable third-party service.
Still, low complexity matters because it reduces the friction between disclosure and misuse. When a vulnerability requires rare expertise, costly hardware, and a bespoke research setup, fewer adversaries can act on it. When it can be reproduced with ordinary tools, known credentials, exposed interfaces, or predictable workflows, the threat pool expands.
The rise of automation compounds the problem. PCA CTO Vlad Ryabyshkin argued that increased automation of vulnerability discovery and exploitation is pushing researchers and attackers toward higher-risk opportunities with broader reach. Ryabyshkin’s comments on automation and supply-chain targeting AI-assisted research does not eliminate the need for technical skill, but it can accelerate reconnaissance, code analysis, configuration discovery, proof-of-concept development, and targeting.
The Expanding Attack Surface: Vehicles Are Only One Layer
The report’s most important insight may be that attackers are increasingly looking beyond the individual car. Charging networks, micromobility systems, cloud identity layers, data providers, and suppliers can create opportunities to affect many customers or operations at once.PCA highlighted white-hat research involving cloud-based authentication systems associated with rentable EV chargers, shared e-bikes, and e-scooters. The reported work showed how remotely manipulated authentication mechanisms could create disruption across parts of urban transport infrastructure. The report’s mobility-platform example
This is a key evolution in automotive cybersecurity. The most valuable target may not be an individual vehicle’s onboard computer. It may be the platform that authorizes a large group of users, allocates chargers, processes fleet telemetry, manages reservations, or distributes configuration changes.
Charging Infrastructure Is Both an Opportunity and a Dependency
EV adoption creates a useful digital ecosystem around charging, energy management, billing, mobile authentication, route planning, and fleet coordination. It also creates dependencies that sit outside the traditional boundaries of automotive manufacturing.A compromised charging platform might not directly alter a car’s safety systems, but it could still produce meaningful disruption:
- Drivers unable to authenticate or begin charging
- Fleet operators unable to coordinate vehicle availability
- Billing disputes or payment exposure
- Charging-station downtime across a region
- Interrupted logistics schedules
- Customer support overload
- Loss of trust in public charging infrastructure
Mobility Platforms Create Shared Points of Failure
Shared scooters, rental EVs, car-share services, and connected fleet platforms have a distinct risk profile. They commonly rely on central identity services, APIs, mobile applications, cloud dashboards, and location telemetry. One weak implementation can affect a wide number of users, assets, or operating locations.That creates an incentive for attackers to favor centralized infrastructure over isolated endpoints. A vulnerability affecting a common cloud component may offer more leverage than a flaw tied to a particular car model or firmware release.
This is why security architecture must assume that backend systems are part of the vehicle environment. Treating cloud services as separate “IT” and vehicle electronics as “product security” can leave dangerous accountability gaps between teams.
Ransomware and the Supply Chain: The Industry’s Soft Underbelly
The automotive sector has always been a supply-chain business. A manufacturer depends on hundreds or thousands of external companies for chips, wiring harnesses, sensors, components, embedded code, logistics, engineering, production tooling, cloud services, and business data.That dependency is why supply-chain breaches can be so damaging. PCA’s report cited a ransomware incident affecting a UK automotive data and vehicle-valuation provider, reportedly leaving dealers, insurers, and original equipment manufacturers unable to access critical information and creating what was described as a regional valuation blackout. The reported automotive data-provider disruption
The incident is a useful reminder that automotive resilience depends on far more than production lines. Vehicle valuations, finance decisions, insurance workflows, trade-in transactions, parts ordering, repair estimates, registrations, and dealer sales processes can all depend on external data platforms.
When one of those services fails, organizations may still have vehicles, employees, and customers—but lack the data needed to transact normally.
Why Attackers Prefer Indirect Routes
PCA’s monitoring of criminal forums, ransomware leak sites, and dark-web marketplaces indicated mounting pressure on automotive supply chains. The report argued that attackers are increasingly targeting suppliers and associated firms as a route into the broader industry rather than attempting a direct breach of a major manufacturer’s core network. The report’s supply-chain assessmentThat strategy makes sense from an attacker’s perspective. A large manufacturer may have a mature security operation, dedicated incident-response personnel, hardened infrastructure, and extensive monitoring. A smaller supplier might have fewer resources, older systems, inconsistent identity controls, weaker segmentation, or limited ability to detect intrusion.
PCA cited claims involving a Japanese automotive component maker, a Canadian parts retailer and distributor, and a major Indian electronics contract manufacturer. In the latter case, the World Leaks extortion group was said to have published more than 630 GB of stolen data across more than 200,000 files, including confidential engineering documents allegedly associated with a major EV manufacturer. The reported extortion-group cases
As with many ransomware and extortion claims, the specific scope and contents of a purported data theft should be treated cautiously until independently verified by the affected organizations. But the strategic risk is indisputable: a compromise at one supplier can expose information and operations tied to numerous customers.
The Regulatory Direction Is Clear
Supply-chain security is not merely an aspirational best practice. Automotive cybersecurity frameworks increasingly require manufacturers to account for supplier dependencies.UN Regulation No. 155 requires cybersecurity management processes that cover development, production, and post-production, as well as monitoring, detection, response, risk treatment, and the management of dependencies involving contracted suppliers and service providers. UNECE documentation describing UN R155 cybersecurity-management requirements
The UK Vehicle Certification Agency similarly notes that UN R155 covers vehicle cybersecurity and cybersecurity management systems, while UN R156 covers software-update management. It also emphasizes the relationship between these requirements and ISO/SAE 21434, as well as ISO 24089 for software updates. UK VCA guidance on cyber security and software updating
For suppliers, the implication is unavoidable: cybersecurity capability is becoming part of the qualification process, not a nice-to-have differentiator.
Software Bills of Materials Are Becoming Operational, Not Administrative
PCA’s recommendation to focus on verifying whether patches are present across full software bills of materials is one of the report’s most practical conclusions. The report’s call for stronger software composition analysisAn SBOM, or software bill of materials, is essentially an inventory of the components and dependencies contained in a software product. In automotive use, that inventory can become complicated quickly: a vehicle may contain dozens of electronic control units, each with separate firmware, libraries, operating environments, supplier code, open-source components, and hardware dependencies.
A spreadsheet listing a few component names is not enough. The inventory needs to identify versions, relationships, suppliers, update status, and the systems in which a component actually runs. The U.S. Cybersecurity and Infrastructure Security Agency says an SBOM should cover all components in the target software, including transitive dependencies, and should be updated with each software version or release. CISA’s SBOM minimum-elements guidance
The Real Challenge Is Exposure Verification
Many organizations can identify that a vulnerability exists in a library somewhere in their environment. The harder question is whether it is:- Present in the specific software version they use.
- Included in a shipped vehicle, tool, backend service, or supplier product.
- Reachable in the deployed configuration.
- Patched in every affected environment.
- Still supported by the original component provider.
- Monitored after the patch is installed.
For Windows-based automotive environments, this same discipline should include service laptops, workshop PCs, diagnostic servers, application gateways, engineering workstations, Active Directory infrastructure, remote-access tools, and third-party data integrations. The boundary between “enterprise IT” and “vehicle security” is increasingly artificial.
What Automotive Organizations Should Do Now
The Q2 findings do not call for panic. They call for a more mature operating model—one built on continuous visibility and measurable resilience rather than periodic assessments and static compliance evidence.NHTSA’s cybersecurity best-practices guidance stresses that organizations across the automotive supply chain have a role in vehicle cybersecurity and should establish clear cybersecurity expectations for suppliers while verifying implementation. NHTSA’s cybersecurity best-practices document
A stronger response should include the following priorities.
1. Build a Unified Asset Inventory
Organizations need a live inventory that covers vehicles, ECUs, firmware, cloud services, APIs, mobile apps, charging systems, diagnostic tools, developer environments, and critical supplier integrations.The inventory should answer basic questions quickly:
- Which products use a vulnerable library?
- Which firmware builds are installed in the field?
- Which supplier owns a specific component?
- Which systems can reach a safety-relevant network?
- Which assets are no longer receiving updates?
- Which credentials or certificates grant remote-management access?
2. Treat Diagnostics and Debugging as Privileged Operations
Local Shell findings should trigger a review of diagnostic and engineering access pathways. Debug interfaces need strict access control, strong authentication, signed tooling, role separation, secure logging, and documented maintenance procedures.Organizations should also audit temporary exceptions. Factory modes, developer accounts, test certificates, service passwords, and diagnostic privileges often become security liabilities when they outlive their original purpose.
3. Test the Entire Attack Path
A secure vehicle component can still be exposed through an insecure cloud API. A hardened cloud service can still be undermined by compromised supplier credentials. A patched backend can still leave old vehicles running vulnerable firmware.Security testing should therefore model complete paths—from mobile app to cloud service, from diagnostic tool to ECU, and from supplier portal to engineering repository. The goal is not merely to find vulnerabilities in isolation, but to understand how they can be chained.
4. Demand Evidence From Suppliers
Contractual language stating that a supplier “follows industry best practices” is no longer sufficient. Manufacturers and major service providers need evidence of:- SBOM generation and maintenance
- Vulnerability-disclosure processes
- Patch and remediation timelines
- Secure-development practices
- Security testing and penetration-test results
- Incident-notification obligations
- Identity and privileged-access controls
- Business-continuity and ransomware recovery plans
5. Measure Patch Effectiveness, Not Just Patch Intent
A patch advisory is not a remediation outcome. Organizations should validate deployment across the real estate of vehicles, devices, backend services, and supplier-supported systems.That includes checking for failed over-the-air updates, offline vehicles, devices with unsupported firmware, configuration drift, and systems excluded from routine update workflows. The objective is to know what remains exposed, not merely what has been scheduled for remediation.
The Bottom Line: Automotive Cybersecurity Is Now an Ecosystem Discipline
The Q2 2026 increase in severe automotive vulnerabilities is significant because it captures a wider transition. The sector is moving from a world where security teams could focus primarily on individual vehicle components to one where risk is shared across software, cloud platforms, energy infrastructure, suppliers, mobility services, and business data systems.PCA Cyber Security’s findings—161 high-severity vulnerabilities among 345 total, a leading role for Local Shell access, and a reported 94% low-complexity share—should be read as a warning about exposure management rather than as a prediction of inevitable catastrophe. PCA’s Q2 automotive vulnerability analysis The greatest risk is not that every vulnerability will be exploited; it is that organizations will discover too late that their systems were more connected, less visible, and more dependent on third parties than their security models assumed.
The industry’s answer cannot be a manual spreadsheet, a once-a-year penetration test, or a patch policy that stops at the corporate network. It must be continuous: complete component visibility, verified remediation, rigorous supplier governance, secured diagnostic access, monitored cloud services, and an incident-response plan that reaches every part of the automotive ecosystem.
As vehicles become increasingly software-defined, cybersecurity will no longer be a supporting engineering function. It will be a core requirement for trust, safety, availability, privacy, and the basic ability of the automotive industry to keep moving.
References
- Primary source: IT Brief UK
Published: 2026-07-28T08:30:00+00:00
Automotive cyber vulnerabilities more than double in Q2
Greater exposure to remote attacks is worrying carmakers, as high-severity automotive cybersecurity flaws jumped to 161 in the second quarter.
itbrief.co.uk
