The European Union — technology neutral by accident, and the only working multi-root trust list in the world.

The Commission adopted a C-ITS Delegated Regulation on 13 March 2019. It never entered into force: the Council of the European Union objected in July 2019, principally on the grounds that the text favoured ITS-G5 over C-V2X. The Parliament's TRAN committee had earlier declined to object; the Council's objection was decisive.

No replacement C-ITS delegated act has been adopted as of August 2026.

Commission Implementing Decision (EU) 2020/1426 of 7 October 2020 extended the ITS band from 5875–5905 MHz to 5875–5935 MHz, with member states required to designate it no later than 30 June 2021. The 60 MHz figure is the band; it is not what road ITS gets, and the difference is where most summaries go wrong.

• Article 3(1) requires 5925–5935 MHz to be limited to urban rail ITS. Road ITS therefore has 5875–5925 MHz — 50 MHz.
• Article 3(2) gives road ITS priority below 5915 MHz and urban rail ITS priority above it, so that whichever has priority is protected.
• Article 3(3) limits road ITS access to 5915–5925 MHz to infrastructure-to-vehicle connectivity only, coordinated with urban rail ITS where appropriate.
• Article 3(4) makes urban rail access to 5925–5935 MHz shared and subject to national circumstances, including coordination with the fixed service.

The Decision is written technology-neutrally, explicitly acknowledging both ITS-G5 and LTE-V2X, and noting ETSI work on co-channel and adjacent-channel coexistence.

Its Annex was replaced in full on 24 July 2026 by Commission Implementing Decision (EU) 2026/1800, published in the Official Journal on 28 July 2026 and notified as C(2026) 5125. The change: two adjacent 10 MHz blocks may now be combined into one contiguous 20 MHz channel for road ITS. The condition attached: the 20 MHz channel formed within 5905–5925 MHz shall be limited to infrastructure-to-vehicle communications, because its upper half falls inside the 5915–5925 MHz range Article 3(3) already restricts. Recital 6 records that this stands pending solutions that protect urban rail ITS in that range, following CEPT Report 91 of 7 November 2025. The replaced Annex also adds an unwanted-emissions limit above 5925 MHz of −30 dBm/MHz EIRP for road ITS, and restates transmit power control as an ability to reduce total power from maximum to 3 dBm EIRP rather than as a 30 dB range. The channel conditions in detail →

A Union designation is still not a national permission. Member states implement it through their own instruments, and those can be narrower: Germany's general assignment opens 5875–5915 MHz, requires an individual assignment above that, carries no 20 MHz pairing provision and expires on 31 December 2026.

The other live spectrum file in 2026 is adjacent-band coexistence: Commission Implementing Decision (EU) 2025/913 of 20 May 2025 relaxed very-low-power out-of-band emissions below 5935 MHz from −45 to −37 dBm/MHz, conditional on frequency-selection mechanisms prioritising blocks above 6105 MHz, expressly to protect urban rail ITS in 5905–5935 MHz. All jurisdictions compared →

ETSI ITS Release 2 is the current baseline and is actively maintained into 2026: TS 103 300-3 V2.3.1 (December 2025) for VRU awareness, TS 103 301 V2.3.1 (April 2026) for infrastructure services, TS 103 900 V2.3.1 (May 2026) for cooperative awareness, TS 103 097 V2.2.1 (March 2026) for security, and TS 103 759 V2.2.1 (January 2026) for misbehaviour reporting. Release 2 adds collective perception, VRU awareness, manoeuvre coordination and multi-channel operation over Release 1's CAM and DENM core. The message set →

UNECE R155 and R156 both entered into force January 2021. Under EU Regulation 2019/2144, R155 became mandatory for new whole-vehicle type approvals in July 2022 and extended to all new vehicles registered in the EU in July 2024. R155 requires a certified Cybersecurity Management System; R156 requires a Software Update Management System and provides the legal basis for OTA updates. They apply across the 1958 Agreement contracting parties, including the UK, Japan and South Korea. An on-board unit sits squarely inside both. What that means for the device →

What applies when. Article 71 sets three dates. Chapter IV, on the notification of conformity assessment bodies (Articles 35 to 51), has applied since 11 June 2026. Article 14, the manufacturer's reporting obligations, has applied since 11 September 2026. Everything else — the essential requirements, conformity assessment, CE marking — applies from 11 December 2027. Article 69(3) makes the reporting duty reach products already on the market before that date: a manufacturer of an in-scope product placed on the EU market in 2024 is under Article 14 today, even though the product never had to meet the essential requirements.

The two clocks. Article 14 creates two parallel three-stage notification tracks, one for an actively exploited vulnerability and one for a severe incident having an impact on the security of the product. Both start when the manufacturer becomes aware. Each stage is due only where the relevant information has not already been provided, and the CSIRT that first receives a notification may ask for an intermediate status report in between.

An incident is severe under Article 14(5) when it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led or could lead to the execution of malicious code in the product or in a user's network and information systems. Neither track collapses into a single “report everything within 72 hours” rule: the early warning and the notification have different content, and the two final-report deadlines run from different events.

The platform. Article 16 requires ENISA to establish and operate a single reporting platform with national electronic notification end-points, so that a manufacturer submits once and the coordinating CSIRT disseminates. ENISA announced the CRA Single Reporting Platform as operational on 11 September 2026, describing the launch as its initial operating capability; the platform's own FAQ records the same date. Commission Delegated Regulation (EU) 2026/881 supplies the cybersecurity-related grounds on which dissemination of a notification may be delayed, under Article 14(9). No implementing act on the format and procedure of notifications under Article 14(10) had been located on the Commission's implementation pages at the date of this review.

Where automotive and V2X products stand

The CRA is not a blanket exclusion of “automotive”. Article 2(2)(c) removes from its scope products with digital elements to which Regulation (EU) 2019/2144 — the General Safety Regulation for vehicle type approval — applies; the recital explains this by the cybersecurity requirements that regulation already imposes through UN Regulation No. 155 and the type-approval conformity procedures. Regulation 2019/2144 applies to vehicles of categories M, N and O and to systems, components and separate technical units designed and constructed for them. Commission Delegated Regulation (EU) 2025/1535 extended the exclusion to products within Regulation (EU) No 168/2013 — L-category vehicles — except pedal-assist L1e cycles. Article 2(6) separately exempts spare parts that replace identical components and are made to the same specification.

The Regulation says nothing about how the vehicle exclusion applies to a component sold on its own. The Commission's guidance of 27 July 2026, C(2026) 5252, addresses exactly that point in its section on vehicles. In its reading, a component is outside the CRA only where it is exclusively designed and constructed for integration into vehicles covered by those regulations, and clearly intended and suitable only for that integration; it makes no difference whether it is sold to the vehicle manufacturer or to another operator in the automotive supply chain. A generic component that can be integrated into other kinds of product is in scope. And the guidance treats the sales channel as objective evidence: a component offered through channels open to customers outside the automotive supply chain — general retail, or online ordering by the public — is in scope irrespective of any statements concerning its intended use, while restricted business-to-business distribution within the automotive supply chain may indicate exclusivity. On spare parts, the guidance adds that a replacement differing in security-relevant characteristics such as algorithms, protocols, cryptographic mechanisms or access control is not “identical” and is a product with digital elements in its own right.

The honest summary is the one the primary texts support: whether a specific automotive or V2X product falls within the CRA depends on how it is placed on the EU market and whether it is already covered by the applicable sector-specific vehicle type-approval regime. The Commission's guidance is interpretive rather than binding, and the aftermarket boundary is genuinely open. This page does not state that every V2X device is in scope, and it does not state that being “automotive” takes a device out.

Why it matters to a V2X engineering team either way

A 24-hour clock that starts on becoming aware is not met by a reporting form; it is met by an organisation that already knows what it ships, where, and with which components, and that can tell an exploited vulnerability from a rumour inside a working day. For a connected-product team the operational content is the same whether the CRA, UN R155 or a customer contract is the driver:

• a vulnerability intake route that is published and monitored, and a product security incident response function behind it;
• a product and software inventory, with dependency and SBOM visibility, so that a disclosed component flaw can be mapped to affected units in hours;
• triage criteria that distinguish an actively exploited vulnerability and a severe incident from the rest;
• supplier escalation paths for silicon, module and stack components, with agreed response times;
• preservation of incident evidence in a form that survives the final report;
• a remediation workflow that reaches deployed units — which is where a secure update architecture stops being a feature and becomes the mechanism by which a final report can ever be filed;
• a coordinated-disclosure position, and regulatory-reporting readiness rehearsed against the clock rather than read about after it starts.

None of this is part of any V2X standard. The V2X-specific material on this site — the documented attacks, misbehaviour reporting, key protection — is the technical layer; the CRA is the organisational one. It is also a different regulatory system in a different jurisdiction from India's Draft AIS-230, which is a vehicle type-approval standard for on-board units and carries no vulnerability-reporting regime of this kind; nothing in this section is part of AIS-230 compliance. Draft AIS-230, explained →

Sources. Regulation (EU) 2024/2847, Articles 2, 3, 14, 16, 69 and 71, and recitals 27, 29, 65 and 69 · Commission Delegated Regulation (EU) 2025/1535 · Commission Delegated Regulation (EU) 2026/881 · Commission guidance C(2026) 5252, 27 July 2026, sections 4.2 and 9.3.1 · Commission, CRA reporting obligations · Commission, CRA implementation FAQ · ENISA, 11 September 2026 · ENISA, Single Reporting Platform. Retrieved 17 September 2026.