CRA Guidance July 2026: The Edge Cases, Worked Through

Your vending machine has a SIM card in it. That cellular modem sits in a product category the CRA singles out for stricter conformity assessment. The machine around it stays in the default category.

That gap decides whether you can run the assessment yourself or have to pay a Notified Body to run it. You sign the declaration either way. It turns on a single sentence most manufacturers have never read.

The European Commission published CRA implementation guidance on 27 July 2026. It runs to 84 pages with 67 worked examples. This post covers five of them that change the answer in practice, with a case worked through for each one.

A regulated part inside does not reclassify the machine

Your conformity assessment route is decided by one thing: your product's core functionality. Get that wrong and you either overpay a Notified Body or ship without an assessment you legally needed.

The CRA never defines core functionality. The guidance does.

A vending machine, a cellular modem, and EUR 25,000

This scenario is hypothetical.

You build vending machines. Yours does three things:

• Takes card payments
• Tracks stock with weight sensors
• Carries a cellular modem, so head office can pull sales data overnight and push price changes

The modem is what creates the question. Routers and modems intended for internet connection are listed as important products under the CRA, in class I. Your machine contains one.

On the illustrative figures above, and assuming the internal control route would not have been open to you, that single line is worth roughly EUR 25,000. Actual costs vary by product and body. Class I products can still self-assess where a relevant harmonised standard is fully applied, though the guidance attaches a second condition to that, covered below.

What you still owe for that modem

The modem leaves the classification question. It does not leave your obligations.

• Risk assessment: the modem is an integrated component and belongs in your product risk assessment, including the interfaces it exposes and the data flows it carries.
• Due diligence: you must take appropriate measures to confirm the component does not undermine your product's compliance. Vendor technical documentation and security documentation can serve as that evidence.
• The network is not yours: the cellular network your modem connects to is a communication channel, not part of your product. You owe no due diligence toward the mobile operator.

Here is the split in full, because teams routinely get one half right and the other half wrong.

The last row catches integrators. Buying a certified module and soldering it in is a supply chain question. Writing the firmware that runs on it can make you the manufacturer of what you place on the market, and whether that reaches the modem itself depends on how it is supplied and what you changed.

For how the categories work in detail, see our product classification guide. For modems as products in their own right, see routers and modems.

Two gaps you are carrying without being told

• Core functionality is defined only in guidance: the regulation itself never defines the term that decides your conformity route. The definition you are working from is the Commission's reading, and it binds nobody.
• The self-assessment gate has quietly grown a second condition: the law makes third-party assessment necessary for an Important Class I product where the manufacturer has not fully applied the relevant harmonized standards. That is one test. The guidance adds another, that the standard's scope must also cover every cybersecurity risk tied to your core functionality. That second test is not written out in those terms in the law. The Commission derives it from how applicable requirements and presumption of conformity fit together, so it narrows who can self-assess by interpretation rather than by text.

Selling a module separately changes what it is

Where you offer the modules of a suite for separate purchase, licensing, or subscription, each one becomes a product in its own right. Each is then classified on its own core functionality, not on the suite's.

The Commission works this through a security suite split into parts, and the parts land in different regimes.

One line on a price list moves a module into a stricter regime

This scenario is hypothetical.

You sell proprietary software to industrial operators. It does four things:

• Collects data from production lines
• Shows dashboards
• Raises alerts
• Includes an intrusion detection module for the OT network

Sold as one platform, the core functionality is production monitoring. That is a default-category product. You self-assess, you sign the declaration, you ship.

Then sales asks for the intrusion detection module to be available on its own, because three prospects want it without the rest. You add a line to the price list.

That module is now a separate product, and it is classified on its own core functionality, which is intrusion detection. Intrusion detection and prevention systems are an Important Class II category.

Class II requires third-party conformity assessment. That requirement is not optional and does not depend on standards. Products that qualify as free and open-source software have their own route.

Nothing in the code changed. A commercial decision moved one module into a stricter regime, and on typical figures that means a materially larger assessment cost and a longer path to release.

Nobody has defined what separately available means

The guidance names separate purchase, licensing and subscription, and it excludes modules supplied only as part of an integrated product. That leaves one case genuinely open. Four situations, three answered:

• A separate SKU on a price list. Answered. Separate purchase is named explicitly, so this is caught.
• A feature flag your sales team can license independently. Answered. Licensing and subscription are named alongside purchase, so a separate SKU is not required.
• An add-on sold only to existing platform customers. Open. You cannot buy it alone, but you can buy it separately from the rest of the suite. The guidance does not reach this case.
• A module that is technically separable but never offered alone. Answered. Modules supplied only as part of an integrated product are excluded, and classification stays at the level of the whole product.

So the test follows commercial reality rather than packaging labels, and a licensable feature flag counts even without a SKU. The one that remains open is the customer-gated add-on, and the answer there changes what you pay.

It matters more than it looks. Product managers change packaging every quarter and never think of it as a regulatory event. Put a check into that decision now, because the alternative is discovering it after a customer has already been quoted.

See conformity assessment routes for what each module involves and what it costs.

A big update does not restart your support clock

A substantial modification forces you to reassess the support period. It does not automatically reset it. It does not automatically extend it either.

The question is narrower than most teams assume. Did the modification change the factors that set the expected use time in the first place?

The Commission gives two cases: a software change that leaves the original end date standing, and a hardware change that forces recalculation.

The same controller, two changes, two different answers

This scenario is hypothetical.

You place a programmable logic controller on the market in 2028. Expected use time is twelve years, based on the durability of the hardware and what industrial customers reasonably expect from that class of equipment. You declare a support period ending in 2040.

2031. You ship firmware adding remote diagnostics. Assume the new interfaces and data flows change how the product meets the essential requirements, so on these facts it counts as a substantial modification. That triggers a fresh conformity assessment and an updated technical file. New interfaces on their own would not settle it.

It does not move the support date. Hardware durability has not changed. Customer expectations have not changed. Support still ends in 2040, and the fact that fewer than five years remain at some later point does not extend it.

2033. You replace the compute module with a newer generation designed for a longer operational life, and you market the machine on that basis. Now the factors have changed. Customers can reasonably expect more years of service from it. You recalculate the support period upward.

Shortening a support period is unaddressed

The worked cases show the period staying the same and the period extending. The rule itself says to recalculate against the criteria when the determining factors change, without saying the result can only go up.

If a modification narrows a product's realistic service life, say by dropping support for the hardware platform it runs on, no worked case tells you whether the declared period can follow it down. We would not shorten a period already communicated to customers, but the guidance does not settle it.

More on setting the period in the first place: support period basics.

A spare part may stop being a spare part when its security changes

Spare parts that replace identical components sit outside the CRA. The word doing the work is "identical," and the guidance defines it more narrowly than most obsolescence processes assume.

Identical is judged on the part's functional role together with its cybersecurity-relevant characteristics, and the guidance says a case-by-case assessment is always needed. The Commission's list of relevant characteristics includes algorithms, protocols, cryptographic mechanisms, and access control features, and it does not close the list.

The Commission contrasts two end-of-life replacements. One changes the cryptographic implementation and the secure boot mechanism, and loses the exemption. One changes the chipset but keeps the same protocols and security mechanisms, and keeps it.

Two replacement modules, one of them a new product

This scenario is hypothetical.

You installed access control panels across a corporate estate in 2029. In 2033 the wireless module inside them reaches end of life and your supplier offers two replacements.

Replacement A. Different chipset, different manufacturer, same radio protocols, same key storage, same secure boot chain. On these facts it should still qualify as a spare part, outside the CRA, shipped through your service channel.

Replacement B. Same radio, but a newer secure element with a different key hierarchy and a different boot verification sequence. Those differences go to the cybersecurity characteristics, so on these facts it is not identical. It becomes a product with digital elements in its own right, needing its own conformity assessment, technical documentation and CE marking.

Same part number on your BOM. Same physical footprint. Two completely different compliance outcomes.

The consequence nobody has built for

Your obsolescence process almost certainly compares datasheets. Pin compatibility, voltage, footprint, temperature range, RF performance.

None of that answers the question the CRA asks. You need a security-characteristics comparison sitting alongside the electrical one. These are the fields it has to carry.

Secure boot and key storage are worth checking early, because a change in either is easy to miss on a datasheet comparison. The guidance does not rank the characteristics, so none of them can be skipped.

Most teams do not have this document. Building it is modest work now against a blocked shipment and an emergency conformity assessment later.

One more condition that catches people: being technically swappable is not enough on its own. The repair purpose has to be evident in how the part is supplied, through the identification of the product in the order or the commercial offer, or through supply via after-sales channels. A component sold as a general-purpose standalone product does not get the exemption just because it happens to fit.

Access control readers and biometric terminals sit in the same category and are treated the same way.

The list of security characteristics is left open

The list of security-relevant characteristics is open. Whether a firmware version bump inside an otherwise identical module counts is not addressed anywhere.

Changing an old product does not drag the whole thing into scope

The CRA applies in full from 11 December 2027. From 11 September 2026 the reporting duty will also cover products placed on the market before then, but those products pick up the rest of the regime only if they are substantially modified afterward.

The fear this creates is reasonable: touch a fifteen-year-old machine once and the entire thing needs bringing up to a standard that did not exist when you designed it.

That is not what happens. Where the original manufacturer makes the modification, obligations attach to the modified part. The whole product follows only where the change damages the security of the product as a whole.

What you owe on a 2026 machine you changed in 2029

This scenario is hypothetical.

You shipped an industrial packaging line in 2026 with a twenty-year service life. In 2029 you release a firmware change to the labeling subsystem that adds a network interface for print job management. That is a substantial modification.

What you owe: conformity for the labeling subsystem, a current risk assessment covering it, and updated technical documentation for what changed.

What you do not owe: retrofitting the motion controllers, the safety interlocks, or the operator terminal. And you are not required to reconstruct design and test records from 2025 that never existed in this form. The guidance is direct about this. Products designed before the CRA applied need no redesign where a current risk assessment shows the existing measures address the risks, and recreating historical documentation would not make the product safer.

The asymmetry nobody mentions

The narrow scoping applies to the original manufacturer, and to an unrelated third party who both makes the modification and puts the modified product on the market. It does not apply to importers and distributors, who are handled by a separate rule with no such limit.

Read those rows again. A contract engineering firm that modifies a machine and places it on the market gets the narrow scope, as long as the change leaves the cybersecurity of the whole product alone. An importer performing the identical modification gets the wide one. The act is the same. The exposure is not.

The regulation treats the two cases differently on its face. The practical effect is that importers who modify carry more than third parties who modify.

For the full timeline and what applies when, see our CRA implementation timeline.

The phrase that decides it is defined nowhere

The relief depends on whether the modification "negatively affects the cybersecurity of the product as a whole." That phrase decides whether you update one subsystem or all of them, and it is defined nowhere.

Expect that sentence to be the one you argue about with a Notified Body.

How this fits with the March draft

The Commission ran a public consultation on a draft of this guidance between 3 March and 13 April 2026. We covered that draft when it appeared, in what the March 2026 draft means.

The July document is the outcome of that consultation. It does not cover the CRA in full, and the Commission says so directly.

Paragraph 9 says the Commission may consider further guidance under Article 26. It gives the CRA's interplay with the AI Act and DORA as examples of what that guidance could address. That is a possibility, not a commitment to another publication.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.