OBC Cybersecurity Requirements for Vehicle Programmes

Under UNECE R155, the vehicle manufacturer remains responsible for managing cybersecurity across the vehicle lifecycle, including risks introduced by the OBC, DC charging path, AC charging interface and supplier software. An OBC supplier must therefore provide traceable security evidence, defined interfaces, vulnerability support and test results that the OEM can incorporate into its Cyber Security Management System and vehicle type-approval case.

What does UNECE R155 require from an OBC programme?

UNECE R155 places the approval responsibility on the vehicle manufacturer. The manufacturer must demonstrate that its Cyber Security Management System covers development, production and post-production activities, including risk identification, treatment, verification, testing and maintenance of the risk assessment.[1] The regulation also requires management of cybersecurity dependencies involving contracted suppliers and service providers.[6]

For an OBC programme, this means the component cannot be assessed only for electrical safety, functional performance or communication compatibility. Its interfaces, embedded software, diagnostics, update mechanisms and manufacturing controls must be considered within the vehicle’s cybersecurity architecture and risk assessment. The OBC supplier supports the evidence package, but the OEM retains responsibility for the vehicle type and its approval submission.

The exact deliverables should be agreed in the sourcing and requirements phase. They normally include an item definition, cybersecurity assumptions, interface descriptions, threat analysis inputs, security requirements, verification records, vulnerability-management arrangements and change-control procedures. The required depth depends on the OBC’s connectivity, privileges and role in the vehicle architecture.

Which OBC interfaces should the vehicle TARA examine?

The charging interface is an external attack boundary whenever a vehicle connects to AC or DC charging equipment. The assessment should examine the physical connector, pilot or control signaling, communication protocols, isolation between high-voltage and low-voltage domains, and the possibility of malformed, unexpected or repeated messages. The analysis should also consider charging stations, cables, adapters, service equipment and fleet energy-management systems as external or partially trusted entities.

Within the vehicle, the OBC may exchange commands and status information with the vehicle control network, battery-management system, gateway, thermal controller, instrument cluster and telematics or diagnostic functions. Relevant questions include which nodes can command charging, change limits, clear faults, initiate calibration or request firmware actions. A message that is harmless in one architecture may create a safety, availability or battery-abuse risk in another.

Diagnostic and maintenance paths deserve separate treatment. Engineering tools, production testers and workshop equipment may have privileges that are not available during normal driving. The programme should define authentication, authorization, session control, logging, timeout behavior and recovery procedures. Do not assume that physical access makes a function trusted; workshop and fleet environments can also expose the vehicle to compromised tools or unauthorized personnel.

How should OBC communications be controlled?

Start with an interface inventory that distinguishes safety-critical, security-critical, diagnostic, calibration and informational data. Document the direction of each message, its sender and receiver, acceptable range, timing expectations, failure response and required authorization. This makes it possible to identify whether the OBC can only report status or can also influence charging current, voltage, contactor behavior, thermal limits or energy transfer.

Security controls should be proportionate to the identified risk. Depending on the architecture, controls may include network segmentation, gateway filtering, message validation, replay protection, secure diagnostics, authenticated commands, protected boot, signed software and controlled debug access. The appropriate mechanism cannot be selected from the component name alone; it must follow the vehicle TARA and the OEM’s platform requirements.

Charging communications also require defined fail-safe behavior. The OBC should reject invalid or inconsistent inputs, limit the effect of communication loss and avoid leaving hazardous or unavailable states after reset. Test cases should cover unexpected sequences, malformed data, repeated commands, interrupted charging, power cycling, clock or timeout anomalies, communication loss and recovery from a failed update.

For high-volume vehicle programmes, the interface specification should be configuration-controlled. Variants by region, vehicle platform, voltage class, charging standard or software package should be traceable. A change to a communication signal, diagnostic routine or update method may require renewed cybersecurity analysis even when the electrical hardware is unchanged.

What evidence should an OEM request from the OBC supplier?

The OEM should request evidence that maps directly to its cybersecurity requirements rather than a general statement that the product is secure. Useful evidence includes the supplier’s cybersecurity process description, assigned roles, item definition, threat analysis, cybersecurity goals, requirements traceability, design decisions, verification results and residual-risk treatment. ISO/SAE 21434 can provide a process reference, but the OEM should define the contractual deliverables and acceptance criteria.

Testing evidence should identify scope, configuration, tools, assumptions, limitations and unresolved findings. Depending on the assessed risk, it may include interface robustness testing, penetration testing, diagnostic-access testing, secure-boot and update verification, vulnerability scanning, code-analysis outputs and integration testing with the vehicle network. Test reports should be version-specific and linked to the software and hardware configuration delivered to the programme.

Software transparency is also important. Request a software bill of materials or equivalent component inventory where required by the OEM process, together with third-party component tracking, license information, known-vulnerability monitoring and patch or mitigation procedures. The supplier should explain how security-relevant changes are identified, assessed, approved, tested and communicated.

The evidence package should remain usable by the OEM’s technical service and internal cybersecurity assessors. A certificate or process declaration alone does not replace product-specific evidence. The supplier should be prepared to explain assumptions, dependencies, residual risks and any function that is intentionally excluded from the security scope.

How should supplier responsibilities be written into the contract?

Contract language should identify the OBC item, supported vehicle interfaces, software baselines, cybersecurity goals and required evidence. It should define who owns the vehicle-level TARA, who owns component-level analysis, who approves security requirements and who accepts residual risk. It should also state the conditions under which the supplier must notify the OEM of a vulnerability, security incident, failed test, supply-chain issue or material design change.

Lifecycle duties are essential. UNECE R155 expects cybersecurity management across post-production activities, including monitoring, response and keeping risk treatment effective when new threats or vulnerabilities appear.[1][6] The supplier agreement should therefore cover vulnerability intake, triage, coordinated disclosure, security patches, workarounds, end-of-support planning and evidence retention. Response time targets may be set by the OEM programme; they should not be assumed from a generic supplier policy.

Manufacturing and logistics controls should also be addressed. Relevant topics include programming authorization, key or certificate handling, debug-state management, production traceability, secure configuration, rejected units, service replacement units and protection of software packages. The objective is to prevent a secure design from being weakened during manufacturing, warehousing, vehicle assembly or after-sales service.

How should the OBC be verified before vehicle approval?

Verification should occur at component, subsystem and vehicle-integration levels. Component testing checks the OBC’s own functions and interfaces. Subsystem testing examines interactions with the battery-management system, gateway, charging connector and thermal systems. Vehicle testing evaluates the complete attack path, including external charging equipment, diagnostics, network routing, update infrastructure and relevant operational states.

Test planning should be risk-led and traceable to the TARA and cybersecurity requirements. Include negative tests, boundary conditions, reset and recovery behavior, communication loss, malformed inputs, unauthorized diagnostic requests, update failures and variant-specific configurations. Where an issue is accepted rather than fixed, record the rationale, compensating control, owner and review condition.

The OEM should retain enough evidence to demonstrate that identified risks are appropriately managed and that the vehicle cybersecurity measures remain effective. R155 requires appropriate and sufficient testing before type approval, while the manufacturer must also maintain the risk process over the vehicle lifecycle.[2] Supplier evidence should therefore be delivered in a form that can be updated when software, hardware, charging standards or vehicle architecture changes.

What should buyers put in an OBC cybersecurity request for quotation?

An RFQ should ask suppliers to respond against a defined cybersecurity work package, not just provide a compliance declaration. Include the intended charging functions, vehicle-network interfaces, diagnostic and update expectations, supported variants, production locations, lifecycle assumptions and required integration milestones. Ask for a preliminary scope statement and known dependencies before commercial selection.

Request a deliverables schedule covering the cybersecurity plan, item definition, TARA inputs, requirements, architecture, verification plan, test reports, software inventory, vulnerability process, incident contacts and production-security controls. Require version and configuration identifiers for every technical document. If the OEM uses a specific template or work-product classification, provide it at the start of the programme.

Finally, define acceptance gates. A supplier may be technically capable but unable to support the OEM’s approval timing if evidence is late, incomplete or not traceable to the supplied configuration. Review cybersecurity maturity during supplier selection, then repeat the review at design freeze, validation, production launch, major software release and post-production monitoring. Check the datasheet and programme-specific security specification for product limits and supported functions; do not infer cybersecurity performance from a general OBC rating.