Engineering Deep Dive · Automotive Cybersecurity · Homologation & Compliance

Automotive Cybersecurity: From Attack Surface to Type Approval Readiness

A practical automotive cybersecurity study covering vehicle attack surfaces, TARA, defence-in-depth, ISO/SAE 21434, UN R155/R156, secure software updates, motorcycle risks and OEM compliance readiness.

Reviewed 11 September 202620 minute read

Automotive cybersecurity defence-in-depth: external interfaces—including cloud services, mobile apps, telematics, wireless connectivity, diagnostics, keyless systems, in-vehicle networks and software updates—can form attack paths toward safety-relevant vehicle assets. Select the infographic to view the full-resolution PNG.

Engineering and regulatory use

This article is an explanatory engineering study, not a substitute for a controlled standard, legal opinion or certification interpretation. Requirements vary by jurisdiction, vehicle category, model year and approval scope. Always verify the latest notified CMVR/GSR/AIS text and the applicable UN Regulation series before making a homologation decision.

Executive summary

A modern vehicle is a cyber-physical product. Software does not merely operate entertainment features; it can influence propulsion, braking, steering assistance, battery management, immobilization, diagnostics, charging, rider information and regulatory functions. A cyberattack can therefore progress from an information-security event to a safety, compliance, privacy, theft, warranty or business-continuity event.

The central message of the accompanying infographic is defence in depth across the complete vehicle lifecycle. No single measure—encryption, a firewall, secure boot or a penetration test—is sufficient on its own. Effective protection requires:

1. an accountable cybersecurity organization;
2. risk-based product development;
3. secure vehicle and backend architecture;
4. controlled suppliers and software components;
5. secure manufacturing, diagnostics and software updates;
6. independent verification and validation; and
7. field monitoring, incident response and continuous improvement.

ISO/SAE 21434 provides a lifecycle engineering framework. UN Regulation No. 155 requires an approved Cyber Security Management System (CSMS) and vehicle-type evidence where the Regulation has been adopted and applies. UN Regulation No. 156 addresses Software Update Management Systems (SUMS) and vehicle software-update requirements. ISO 24089 supports the engineering of software updates. These instruments complement one another, but they are not interchangeable.

For Indian two-wheeler programs, an especially important distinction is that the published scope of UN R155/R156 does not automatically extend to L-category motorcycles. Nevertheless, connected motorcycles remain exposed to real cyber risks, and global OEM processes, export-market requirements, customer protection, product liability, privacy obligations and future Indian rulemaking make ISO/SAE 21434-style engineering highly relevant.

1. Why automotive cybersecurity is different from ordinary IT security

Traditional IT security usually prioritizes confidentiality, integrity and availability of information. A vehicle must protect these properties too, but its risk assessment must also consider physical behaviour and road-user safety.

Characteristic	Conventional IT system	Road vehicle
Main consequence	Data loss, fraud or service outage	Can additionally cause unintended vehicle behaviour and physical harm
Product life	Often refreshed in a few years	Vehicle may remain in service for 10–20 years or longer
Update access	Usually continuously connected	May have limited bandwidth, workshop-only flashing or no practical field-update path
Computing margin	Often comparatively high	Many ECUs have constrained memory, processing and power
Safety response	Shut down or isolate service	Must consider controllability and a safe/minimal-risk condition
Supply chain	Software and cloud vendors	OEM, Tier 1/2 suppliers, chipset vendors, telecom, cloud, dealers, tools and aftermarket devices
Evidence	Enterprise controls and audits	Product-level traceability, type-approval evidence, configuration and vehicle population mapping

Cybersecurity and functional safety are complementary:

• Functional safety (ISO 26262) principally addresses hazards caused by malfunctioning E/E behaviour.
• Cybersecurity engineering (ISO/SAE 21434) addresses risks arising from deliberate malicious actions affecting vehicle E/E systems.
• SOTIF (ISO 21448) addresses hazards caused by functional insufficiencies or foreseeable misuse when the system may not be malfunctioning.

One event can cross all three domains. For example, spoofed sensor data is a cybersecurity cause, may expose a performance limitation relevant to SOTIF, and can lead to a safety hazard requiring ISO 26262 coordination.

2. Eight major automotive attack surfaces

An attack surface is any interface, component, process or relationship through which an attacker might reach a vehicle asset. Risk depends not only on the number of interfaces, but on the trust boundaries and privileges behind them.

No.	Attack surface	Typical entry method	Assets at risk	Possible outcome	Indicative priority
1	OEM cloud and backend APIs	Stolen credentials, insecure API, exposed service, cloud misconfiguration	Fleet commands, vehicle identity, customer data, update packages	Mass compromise, privacy breach, unauthorized remote action	Critical where backend can command many vehicles
2	Mobile application and user account	Credential stuffing, weak session control, malicious app, insecure phone storage	Digital key, location, user profile, remote functions	Vehicle theft, tracking, account takeover	High
3	Telematics, cellular and V2X	Protocol weakness, exposed service, rogue base station, certificate misuse	TCU, gateway, remote services	Remote foothold, false messages, denial of service	High to critical
4	Bluetooth, Wi-Fi, USB and infotainment	Malformed media/file, vulnerable wireless stack, untrusted paired device	Head unit, contacts, gateway path	Code execution, data theft, pivot to other networks	Medium to high
5	Diagnostics and workshop tools	Stolen tool, leaked seed-key logic, unauthorized flashing, weak dealer identity	ECU coding, calibration, immobilizer, DTCs	Unsafe configuration, theft, emissions/safety tampering	High
6	Keyless entry and short-range interfaces	Relay/replay, RF jamming, cloned credential, NFC/BLE weakness	Access and immobilization	Theft, unauthorized start, denial of access	High for theft; safety impact varies
7	In-vehicle networks, gateways and ECUs	CAN injection, compromised node, debug-port access, message replay	Powertrain, brake, battery, cluster and body functions	Unauthorized commands, false tell-tales, loss of function	Critical if safety domain is reachable
8	OTA, software supply chain and manufacturing	Compromised signing system, dependency vulnerability, insider action, malicious build or diagnostic station	Firmware, keys, configuration, complete fleet	Persistent or fleet-wide compromise	Critical

Important interpretation

Wireless connectivity is not the only risk. A vehicle without cellular OTA may still be attacked through diagnostics, a compromised workshop laptop, USB, Bluetooth, aftermarket accessories, manufacturing equipment or physical ECU access. Conversely, the existence of an interface does not automatically make risk unacceptable; secure architecture and restricted privilege can break the attack path.

3. How an automotive cyberattack becomes a safety event

A credible assessment should show the complete chain rather than using vague statements such as “the vehicle can be hacked.” A representative remote attack path is:

1. attacker compromises a user account or internet-facing backend service;
2. attacker obtains access to a remote vehicle function or the telematics channel;
3. a weakness in authorization, protocol validation or the telematics unit enables code execution or command misuse;
4. insufficient gateway separation permits movement toward a control network;
5. a forged or replayed message reaches a safety-relevant ECU;
6. the ECU accepts the command because authenticity, freshness, state validation or plausibility checks are inadequate; and
7. vehicle behaviour, tell-tales or availability changes in a way that creates a damage scenario.

Every arrow is a control opportunity. Multi-factor account protection, least-privilege APIs, mutual authentication, hardened telematics, network segmentation, gateway allowlists, authenticated messages, freshness counters, secure boot, runtime monitoring and safe-state logic can collectively make the complete path impracticable.

The highest-risk characteristic is often not a dramatic individual exploit, but scalability. A backend or signing-system compromise may expose an entire fleet, while a physical attack that requires vehicle disassembly may affect only one vehicle at a time. Scale should therefore influence risk treatment, incident escalation and validation depth.

4. Threat Analysis and Risk Assessment (TARA)

TARA translates an architecture into prioritized cybersecurity work. It should begin during concept development and be updated whenever the architecture, interface, supplier, software version, diagnostic function or threat environment changes.

Practical TARA sequence

1. Define the item and boundaries: vehicle functions, ECUs, backend, mobile app, diagnostic and update infrastructure, external systems and lifecycle assumptions.
2. Identify assets: safety functions, executable code, cryptographic keys, calibration, vehicle identity, personal data, diagnostic authority and regulatory configuration.
3. Define damage scenarios: what harm can result if confidentiality, integrity or availability is lost?
4. Define threat scenarios: how could a malicious actor cause that damage?
5. Construct attack paths: identify the interfaces, trust boundaries, prerequisites and sequence of actions.
6. Estimate attack feasibility: consider expertise, knowledge, equipment, opportunity/window of access and time, using the organization’s approved method.
7. Assess impact: evaluate safety, financial, operational and privacy consequences; add legal/reputational factors where the corporate method requires them.
8. Determine risk and treatment: avoid, reduce, share/transfer where legitimate, or accept with documented authority and rationale.
9. Derive cybersecurity goals and requirements: allocate controls to vehicle, ECU, backend, app, infrastructure and organizational processes.
10. Verify residual risk: test controls, close findings and preserve traceable evidence.

Illustrative connected-motorcycle risk register

This example is instructional; actual ratings require program-specific architecture and evidence.

Scenario	Potential impact	Likely assessment	Preferred treatment
Unauthorized powertrain firmware installed through diagnostics	Torque behaviour, emissions/non-compliance, engine damage	Critical/High depending on access and safeguards	Signed firmware, secure boot, authenticated diagnostics, role-controlled tool, calibration integrity check
Compromised connected service issues unauthorized immobilize command while riding	Loss of propulsion and rider stability	Critical	Prohibit unsafe remote actuation states, strong authorization, gateway policy, vehicle-state interlock and fail-safe logic
Keyless relay attack	Vehicle theft and customer loss	High	Distance-bounding/secure ranging where feasible, motion timeout, UWB or equivalent robust design, user alert and theft monitoring
Location history exposed by mobile app/backend	Privacy, stalking and reputational harm	High	Data minimization, consent/notice, strong account security, encryption, restricted retention and audited access
CAN denial of service causes loss of instrument information	Operational and possible safety impact	Medium to High	Bus-load protection, gateway filtering, fault containment, watchdog, degraded display strategy and event logging
Malicious accessory connected to diagnostic or accessory port	ECU/network manipulation	High	Restricted port exposure, authenticated services, segmentation, rate limits and accessory requirements

TARA quality checks

A good TARA is not a spreadsheet created once for an audit. It should answer:

• Is every external interface represented in the item definition and architecture?
• Are safety-critical assets and personal-data assets both included?
• Do threat scenarios describe an attacker, action and affected property clearly?
• Are attack paths technically plausible and linked to architecture?
• Are assumptions—physical access, vehicle state, connectivity, credentials—recorded?
• Does every unacceptable risk produce a requirement and verification method?
• Are supplier responsibilities contractually allocated?
• Is residual-risk acceptance signed by an authorized role?
• Can the OEM identify the affected ECU software versions and vehicle population when a vulnerability emerges?

5. Seven-layer defence-in-depth model

Layer 1 — Governance and CSMS

Define policy, executive accountability, competent roles, escalation, independent review, cybersecurity culture, records, audits and lifecycle processes. Cybersecurity must be integrated with program management, quality, functional safety, homologation, IT security, legal/privacy, procurement, service and crisis management.

Layer 2 — Secure system architecture

Minimize exposed services; separate infotainment, telematics, diagnostics and safety domains; enforce gateway rules; apply least privilege; define trust boundaries; restrict debug paths; and design safe degraded behaviour. Architecture is the most effective place to prevent one compromised component from controlling the whole vehicle.

Layer 3 — ECU and software trust

Use hardware roots of trust where justified, secure boot, authenticated code, protected key storage, memory protection, hardened operating systems, disabled production debug, secure coding, dependency control and rollback protection. Control must continue through manufacturing and service replacement.

Layer 4 — Secure communication and identity

Authenticate external connections and sensitive commands, protect confidentiality where necessary, manage freshness/replay resistance, validate message plausibility and manage certificates and keys throughout their lifecycle. Classic CAN was designed primarily for real-time communication, not native sender authentication; merely “encrypting CAN” is neither universally practical nor a complete architecture.

Layer 5 — Secure diagnostics and updates

Authorize diagnostic users and tools, separate read and programming privileges, sign update packages, verify compatibility, maintain software identities, control downgrade/rollback, protect update servers, confirm adequate power and recover safely after interruption. Workshop flashing is still a software update even when OTA is not used.

Layer 6 — Backend, mobile and operational security

Apply secure API design, identity and access management, secrets protection, cloud configuration control, rate limiting, fraud detection, logging, privacy-by-design, mobile application hardening, build-pipeline security and signing-key protection. Vehicle security cannot exceed the security of the backend that controls it.

Layer 7 — Verification, monitoring and response

Perform architecture review, static/dynamic analysis, fuzzing, penetration testing, interface abuse testing, vulnerability scanning, supplier evidence review and scenario-based validation. In the field, operate threat monitoring, a vulnerability disclosure channel, incident triage, fleet impact analysis, containment, corrective update/service action and lessons-learned feedback.

NHTSA’s 2022 guidance similarly emphasizes a risk-based, layered approach, hardware/software inventory, independent testing, monitoring and remediation, documentation, supplier expectations and secure internal/external interfaces.

6. Cybersecurity across the product-development lifecycle

Phase	Main engineering activity	Minimum evidence / gate output
Concept and business planning	Determine connectivity, remote functions, data use, update strategy, markets and regulatory scope	Item definition, applicability matrix, initial asset list, cybersecurity plan and budget
System design	Define architecture, trust boundaries and cybersecurity goals	TARA, cybersecurity concept, interface controls, functional-safety coordination
HW/SW development	Implement and review cybersecurity requirements	Detailed requirements, design review, code-analysis results, component tests and vulnerability records
Supplier sourcing	Allocate roles and evidence	Cybersecurity interface agreement, supplier capability assessment, delivery/incident obligations
Integration and validation	Prove that controls work and attack paths are mitigated	Integration tests, fuzzing, penetration testing, residual-risk decisions and cybersecurity case/argument
Industrialization and production	Protect keys, software and configuration in factories	Secure provisioning, end-of-line controls, traceability, access logs and production-audit evidence
Homologation / release	Demonstrate organizational and vehicle-type compliance where applicable	CSMS/SUMS certificates, type-level evidence, software identification and approval records
Operations and service	Monitor threats, vulnerabilities, field versions and incidents	SOC/monitoring process, disclosure channel, incident response, update/service campaign evidence
End of support / decommissioning	Retire services and credentials safely	Support-period decision, customer communication, backend/key decommissioning and data deletion plan

Gate-review questions

• Concept gate: Is the remote feature necessary, and can its privilege be reduced?
• Design gate: Can compromise of a public-facing interface reach a safety domain?
• Supplier gate: Who owns vulnerability monitoring and patch delivery after SOP and EOP?
• Validation gate: Has testing challenged the real trust boundaries, not only nominal functions?
• Release gate: Are all unacceptable risks closed or formally accepted with valid evidence?
• Post-production gate: Can affected vehicles and software versions be identified quickly?

7. Standards and regulation map

Instrument	Nature	Primary purpose	Practical relationship
UN Regulation No. 155	Type-approval regulation when adopted by a jurisdiction	Organizational CSMS certificate plus vehicle-type cybersecurity evidence	Defines regulatory outcome; does not prescribe one fixed technical solution
UN Regulation No. 156	Type-approval regulation when adopted	SUMS and controlled vehicle software updates, including update traceability and safe/secure execution	Links updates to configuration and approval-relevant software management
ISO/SAE 21434:2021	Voluntary international engineering standard unless contract/law makes it required	Cybersecurity risk management over the E/E lifecycle	Common implementation framework supporting R155 readiness; not itself an R155 approval
ISO 24089:2023	Voluntary international engineering standard	Organizational and project-level software-update engineering	Supports SUMS and secure, traceable update processes; not itself an R156 approval
ISO 26262	Functional-safety standard	Risk from malfunctioning E/E behaviour	Coordinate cybersecurity controls and safety mechanisms; neither replaces the other
ISO 21448	SOTIF standard	Hazards from functional insufficiency or foreseeable misuse	Relevant where sensor spoofing or perception limitations affect intended functionality
ISO/IEC 27001	Information-security management-system standard	Enterprise/back-office information security	Useful for cloud, enterprise and operational controls, but does not replace product cybersecurity engineering
NIST CSF 2.0	Voluntary organizational framework	Govern, Identify, Protect, Detect, Respond and Recover	Useful umbrella for corporate cybersecurity and backend operations

Scope warning for motorcycles

The published UN R155 scope covers M and N vehicle categories and certain O-category trailers; UN R156 covers specified categories that permit software updates. L-category two- and three-wheelers are not automatically brought into these Regulations merely because they have connectivity. Therefore:

• do not claim a motorcycle has an R155/R156 obligation without confirming the applicable national adoption and vehicle category;
• do not infer that motorcycles have no cybersecurity responsibility;
• apply corporate cybersecurity processes proportionate to the product risk; and
• track future Indian and export-market proposals separately from final notified requirements.

Indian regulatory position — how AutoPDP should report it

India regulatory status

India’s vehicle type-approval obligation arises only after an applicable requirement is formally notified under the Indian legal/CMVR framework, with defined scope and implementation dates. At the review date of this article, AutoPDP should not present third-party claims about “AIS-189/AIS-190” numbers or an October 2027 mandate as settled law unless the corresponding official AISC/MoRTH text and GSR notification are verified.

Use a three-stage status label in the AutoPDP regulatory tracker:

Status	Meaning	Website wording
Emerging / industry discussion	Direction is visible, but no controlled official draft verified	“Monitor; not a confirmed CMVR obligation”
Official draft / consultation	MoRTH/AISC controlled draft is available	Show draft number, publication date, comments deadline, scope and proposed dates
Final notified	Gazette/CMVR amendment establishes legal requirement	Show GSR number, effective dates for new/existing types, categories and transition provisions

Connected-vehicle services also process personal data such as identity, location, driving behaviour and device information. Indian programs should therefore coordinate vehicle cybersecurity with the Digital Personal Data Protection framework, consent/notice, purpose limitation, access control, retention, breach response and third-party processing obligations.

8. Special engineering considerations for motorcycles and electric two-wheelers

Motorcycles may contain fewer ECUs than premium passenger cars, but the rider has less physical protection and can be highly sensitive to abrupt torque loss, false instrument warnings or unexpected braking behaviour. Key areas include:

• ride-by-wire throttle and engine-control integrity;
• ABS, traction control, IMU and wheel-speed signal integrity;
• connected instrument cluster and smartphone pairing;
• telematics and stolen-vehicle tracking;
• keyless ignition and immobilizer;
• ECU flashing, tuning tools and aftermarket accessories;
• emergency-call or crash-detection functions;
• EV battery-management, charger communication and thermal-control logic;
• user account, location and journey-history privacy; and
• secure service diagnostics across the dealer network.

Motorcycle design principle

Remote convenience functions must never have unnecessary direct authority over riding-critical functions. If a remote immobilization feature exists, its state logic should prevent unsafe activation while the motorcycle is moving. Gateway and ECU plausibility controls should ensure that a compromised cluster, app or telematics unit cannot issue unrestricted powertrain or brake commands.

9. Homologation and audit evidence expected from a mature OEM

A regulator or technical service may review both the organization and the vehicle type. A practical evidence library should include:

• cybersecurity policy, governance chart, competence and audit records;
• CSMS and SUMS process descriptions where applicable;
• vehicle item definition, architecture and trust-boundary diagrams;
• asset catalogue, TARA, treatment decisions and residual-risk approvals;
• cybersecurity goals, requirements and bidirectional traceability;
• cybersecurity interface agreements with suppliers;
• hardware/software inventory and vehicle/ECU version mapping;
• secure-development and code-quality evidence;
• secure-boot, key-management, diagnostics and communication design evidence;
• vulnerability analysis, fuzzing, penetration and validation reports;
• update package, compatibility, rollback and failure-recovery evidence;
• software identification and approval-impact assessment;
• manufacturing provisioning and production access-control records;
• field monitoring, disclosure, incident response and campaign processes; and
• cybersecurity case or structured release argument showing why residual risk is acceptable.

Integration with change control and COP/WVSCoP

Cybersecurity configuration should be linked to the approved bill of materials, software version, calibration and vehicle identification. Changes to a TCU, gateway, ECU firmware, cryptographic library, mobile app, cloud API, certificate service, diagnostic access or update method should trigger an impact assessment. The assessment must determine whether the change affects:

• cybersecurity goals or attack paths;
• functional safety or SOTIF assumptions;
• emissions, braking, lighting, tell-tales or other approval-relevant functions;
• the software identification record;
• existing type approval or extension requirements;
• production conformity; and
• vehicles already operating in the field.

10. Testing strategy

Cybersecurity validation should combine methods because each reveals different weaknesses.

Test method	What it finds	Common limitation if used alone
Requirements and architecture review	Missing trust boundaries, excessive privilege, unsafe dependencies	Depends on design accuracy and reviewer competence
Static analysis and code review	Coding defects, insecure APIs and secret handling	May not expose runtime or integration behaviour
Software composition analysis	Known vulnerable third-party/open-source components	Does not find unknown vulnerabilities or unsafe application logic
Fuzzing	Parser, protocol and robustness faults	Coverage may be incomplete; needs realistic interfaces and monitoring
Penetration testing	Exploitable attack chains and control bypasses	A time-limited sample, not proof of absence of vulnerabilities
Hardware/physical testing	Debug, key extraction, bus access and tamper weaknesses	May focus on one ECU/sample and miss fleet-scale backend risks
Backend/API/mobile testing	Account, authorization, API and cloud weaknesses	Must be coordinated with vehicle-state and fleet-command consequences
Update interruption/rollback testing	Bricking, downgrade, power-loss and recovery failures	Needs all real update variants and vehicle configurations
Scenario-based safety validation	Vehicle response after a successful attack or detected anomaly	Requires close cybersecurity–functional-safety integration

Release criteria should cover both preventive control performance and safe behaviour when prevention fails.

11. Field monitoring and incident response

Cybersecurity does not end at SOP or type approval. New vulnerabilities can emerge in operating systems, open-source libraries, chipsets, telecom protocols, cloud platforms and supplier tools after vehicle launch.

A mature field process should:

1. collect authorized, privacy-conscious security telemetry and diagnostic evidence;
2. receive reports through a vulnerability disclosure channel;
3. correlate external intelligence with the software/component inventory;
4. identify affected vehicle types, ECUs, software versions and VIN populations;
5. assess exploitability, safety, compliance, privacy and fleet scalability;
6. contain backend access or risky features where appropriate;
7. create, verify and authorize an OTA update, workshop update or component/service action;
8. notify authorities and customers where legally required;
9. measure campaign completion and residual exposure; and
10. feed lessons learned into new programs and supplier requirements.

Not every cyber vulnerability automatically requires a physical recall. The response may be a backend correction, credential revocation, OTA update, dealer reflash, service campaign, user instruction, feature restriction or recall. The decision must be risk-based, legally reviewed, documented and fast enough to protect road users.

12. Common misconceptions

Misconception	Correct analysis
“The vehicle is secure because the external link is encrypted.”	Encryption protects only selected properties of one link. Endpoint compromise, weak authorization, key theft and unsafe internal architecture may remain.
“Passing a penetration test proves cybersecurity.”	It proves only that the tested team did not find an exploitable issue within the defined scope and time. Lifecycle monitoring remains essential.
“ISO/SAE 21434 certification equals UN R155 approval.”	ISO/SAE 21434 can support engineering evidence; R155 approval requires the applicable authority’s CSMS and vehicle-type assessment.
“The supplier is responsible for ECU security.”	Suppliers own allocated work, but the vehicle manufacturer must manage integrated vehicle and supply-chain risk.
“No OTA means no software-update risk.”	Workshop, factory, replacement ECU and diagnostic flashing are also update paths.
“Cybersecurity is an IT department task.”	It is a cross-functional product-safety and lifecycle responsibility.
“Motorcycles are outside R155, so no action is needed.”	Regulatory scope and engineering risk are different questions. Connected two-wheelers still need proportionate protection.

13. Recommended OEM implementation roadmap

First 30 days — establish scope and governance

• appoint accountable product-cybersecurity leadership and cross-functional RACI;
• create a market/category applicability register;
• select one pilot vehicle program;
• map the vehicle, backend, mobile app, update, manufacturing and service ecosystem;
• catalogue ECUs, software, external interfaces and suppliers;
• assess gaps against ISO/SAE 21434, R155/R156 where applicable and ISO 24089; and
• freeze unsafe new remote-feature releases until high-risk trust boundaries are reviewed.

Days 31–60 — perform engineering risk analysis

• complete the pilot item definition and TARA;
• identify fleet-scale attack paths;
• derive cybersecurity goals and technical requirements;
• issue supplier cybersecurity interface agreements;
• establish software/component inventory and vulnerability-monitoring ownership;
• define diagnostic roles, software signing and key lifecycle; and
• align TARA with HARA, SOTIF and privacy impact assessment.

Days 61–90 — prove readiness

• conduct independent architecture review and targeted penetration/fuzz testing;
• test update interruption, rollback and safe-state behaviour;
• exercise an incident-response tabletop scenario;
• demonstrate affected-population identification from a sample vulnerability;
• close or formally accept residual risk;
• build the auditable evidence index; and
• establish management KPIs and periodic review.

Six- to twelve-month maturity target

• institutionalize CSMS/SUMS across programs;
• integrate cybersecurity gates into APQP/product development and change control;
• automate SBOM/software-version correlation where practical;
• establish continuous supplier and field-vulnerability monitoring;
• conduct regular crisis simulations and independent audits; and
• maintain regulatory watch for each target market and vehicle category.

14. Suggested management dashboard KPIs

KPI	Why it matters
Percentage of vehicle programs with approved item definition and TARA	Measures lifecycle deployment, not only policy creation
Open critical/high residual risks by program and gate	Highlights release risk
Percentage of safety-relevant ECUs with verified secure boot/authenticated flashing	Measures key preventive coverage
Hardware/software inventory and SBOM coverage	Enables fleet impact analysis
Mean time to triage and remediate critical vulnerabilities	Measures field responsiveness
Percentage of suppliers with accepted cybersecurity evidence	Exposes supply-chain readiness
Cybersecurity requirements verified before release	Confirms traceability and completion
Update/campaign completion rate for affected vehicles	Measures remaining field exposure
Unauthorized diagnostic attempts and anomalous fleet events	Supports detection and investigation
CSMS/SUMS audit findings overdue	Indicates governance weakness

15. AutoPDP conclusion

Automotive cybersecurity must be treated as an engineering and management discipline, not a late-stage test. The correct objective is not to promise an “unhackable vehicle.” It is to identify valuable assets, understand credible attack paths, reduce risk through layered architecture, detect and contain attacks, maintain safe vehicle behaviour and respond throughout the field life of the product.

For homologation teams, the most important practice is disciplined separation of four questions:

1. What is the technical risk? — answered through item definition, TARA, design and validation.
2. What process standard is being applied? — for example ISO/SAE 21434 or ISO 24089.
3. What regulation legally applies? — determined by jurisdiction, adoption, category, type and implementation date.
4. What approval evidence is required? — determined by the approval authority/technical service and the applicable regulation.

This separation prevents two common errors: treating voluntary engineering standards as automatically mandatory law, and treating the absence of a current category-specific regulation as permission to ignore a foreseeable safety or privacy risk.

Official reference links

1. ISO/SAE 21434:2021 — Road vehicles — Cybersecurity engineering
2. ISO 24089:2023 — Road vehicles — Software update engineering
3. UN Regulation No. 155 — Cyber security and cyber security management system
4. UN Regulation No. 156 — Software update and software update management system
5. NHTSA — Cybersecurity Best Practices for the Safety of Modern Vehicles, Updated 2022
6. NIST Cybersecurity Framework 2.0

Related articles

Engineering Deep DiveFunctional Safety (FuSa) in AutomotiveChapter 4Vehicle Architecture and System DesignChapter 8Homologation and Type Approval

Back to Engineering Deep Dives