Article 2(2)(c) Exempts Your Vehicle From the EU Cyber Resilience Act. It Doesn't Exempt What You Bolted to It

On 11 September 2026, the notification obligations under the EU Cyber Resilience Act (Regulation (EU) 2024/2847) go live. A 24-hour early warning, a 72-hour notification, a final report to ENISA and the relevant national CSIRT within 14 days. Since the date landed, most of the automotive cybersecurity conversation has treated it as a new clock bolted onto the existing CSMS process built for UN R155. It isn't. For the vehicle itself, in most cases, the CRA doesn't apply at all.

Article 2(2)(c) of the CRA excludes products already covered by sector-specific EU legislation that delivers an equivalent level of cybersecurity assurance. Motor vehicles and their trailers type-approved under Regulation (EU) 2019/2144, the framework that makes UN R155 and R156 mandatory for EU type approval, fall under that exclusion. The CRA is a horizontal regulation for products with digital elements. R155 is a vertical, audit-based regime for the vehicle. Where the vehicle is already regulated end to end, the CRA steps back.

That distinction matters more than the September date does. It changes where the obligation actually lands, and for commercial vehicle manufacturers, it lands in more places than most compliance teams have mapped.

Where the Exemption Actually Ends

The exemption covers the type-approved vehicle as placed on the market by the OEM. It does not extend automatically to everything that touches the vehicle afterward.

Components and software sold separately from the type approval fall outside it immediately. A telematics gateway, a fleet management box installed post-registration, a licensed software product, none of it inherits the vehicle's exemption just because it eventually plugs into a CAN bus that was itself assessed under Annex 5.

Connected accessories and retrofit hardware are where the category actually gets large for truck and bus OEMs. Route optimization units. Driver behavior monitors. Refrigeration telemetry bolted onto a reefer trailer months after the chassis left the plant, sold through a completely different commercial channel than the vehicle itself, often by a company that has never read Annex 5 and has no particular reason to.

Then EV charging equipment and standalone diagnostic tooling, outside 2019/2144 scope entirely, never a candidate for the R155 exemption to begin with. Who in your organization tracks that boundary today, the vehicle security team or whoever owns the charging product line?

The Commercial Vehicle Version of the Problem

This is where the Annex 5 argument extends naturally. Annex 5's threat catalog assumes a single-stage passenger vehicle boundary. Multistage commercial vehicle builds break that assumption because the E/E architecture crosses manufacturer boundaries mid-build. The CRA/R155 boundary breaks a related assumption: that "the vehicle's cybersecurity file" is one file.

A base vehicle manufacturer, a body builder, and a telematics supplier can each hold a different piece of the same physical truck's digital footprint, and only one of those pieces sits inside the 2019/2144 exemption. ITxPT-compliant fleet systems, common in bus and coach applications, routinely combine an exempted vehicle platform with a non-exempted, separately procured onboard IT stack.

The practical test that ends up doing the work inside most OEMs is simpler than the regulation text suggests. If the item is fitted as part of the vehicle's type-approved configuration, covered by the same CSMS file that got the vehicle through R155, it stays out of CRA scope. If it is sold as its own product, outside that configuration, on its own invoice line, CRA applies regardless of how tightly it ends up integrated with the vehicle in the field. The boundary isn't how deeply the component is wired into the truck. It's which type-approval file it was assessed under when it left the factory gate.

The Clock, Scoped Correctly

For the products that do fall inside CRA scope, the notification chain is real and starts now. An actively exploited vulnerability triggers a 24-hour early warning to ENISA, a 72-hour vulnerability notification with initial assessment and, where relevant, corrective measures, and a final report within 14 days of a corrective measure being available. Reporting obligations under the CRA take effect from September 2026; full compliance obligations for the products in scope phase in through December 2027.

Most automotive cybersecurity organizations built their incident response muscle around CSMS and R155's audit cadence, periodic, documentation-heavy, reviewed on a schedule. CRA notification runs on a different clock, event-driven and fast, and a telematics vulnerability found on a Friday afternoon does not wait for the next scheduled security review.

Who Owns the 24 Hours

This is the question that doesn't have a clean organizational answer yet in most commercial vehicle manufacturers. Product security teams built around R155 typically sit close to vehicle engineering and think in type-approval cycles. The products now carrying CRA exposure, telematics, fleet software, charging hardware, often sit in different business units entirely, sometimes with their own supplier relationships and their own incident channels that were never wired into the vehicle CSMS process.

Worth asking inside any commercial vehicle cybersecurity organization before the next incident, not after.

Does the vulnerability intake process distinguish a finding on the type-approved vehicle from a finding on a product sold alongside it, or does everything land in the same queue by default.

Who actually has the authority to start the 24-hour clock when the affected product sits with a supplier, or with an internal business unit that has never once spoken to product security.

And the one nobody wants to answer out loud: how much of what the organization currently sells has quietly become CRA scope without the incident response plan being updated to reflect it.