Silicon is one of the few places the Cyber Resilience Act names explicitly, and the naming is finer than most people expect. Three adjacent product descriptions sit in three different tiers, and the tier decides whether you can sign your own declaration or must book a notified body.
The three tiers, as written
- Annex III Class I — microprocessors with security-related functionalities; microcontrollers with security-related functionalities; ASICs and FPGAs with security-related functionalities.
- Annex III Class II — tamper-resistant microprocessors; tamper-resistant microcontrollers. Per Implementing Regulation (EU) 2025/2392, these are parts designed for Common Criteria AVA_VAN level 2 or 3.
- Annex IV critical — smartcards and secure elements, including TPMs and eUICC/UICC, designed for AVA_VAN.4 or above; hardware devices with security boxes such as HSMs; smart-meter gateways.
Note what is not there: an FPGA without security-related functionality is not an Annex III product at all. It is a default product, and default products may self-assess (Art 32(1)). The phrase “with security-related functionalities” is doing all the work.
What the tier costs you
- Default — module A, internal control. You draw up the technical documentation, affix CE, issue the declaration. No third party (Art 32(1)).
- Class I — module A is still available, but only if you apply harmonised standards, common specifications, or an EUCC scheme at assurance level “substantial” or above covering the requirements. Applied in part, or not at all, and you must use module B+C or module H (Art 32(2)).
- Class II — always a notified-body route: B+C, H, or EUCC at ≥ substantial. No bare self-assessment (Art 32(3)).
- Critical — notified body in every case (Art 32(4)).
So the practical distance between an FPGA with security functions and a tamper-resistant microcontroller is not a paragraph of documentation. It is the difference between a decision you can make internally and one that depends on another organisation’s calendar.
The harmonised standards trap for Class I
Class I self-assessment is conditional, and the condition is not yet satisfiable in general: CRA harmonised standards are still being developed. Until references are published in the Official Journal, a Class I manufacturer either demonstrates conformity by other means and documents the solutions adopted (Annex VII §5), or takes the notified-body route.
Planning on “we will self-assess against the harmonised standard” is planning on a dependency you do not control, with a fallback that everyone else in your tier will reach for in the same quarter of 2027.
Classification is by core functionality, not by feature list
This is the rule that resolves most arguments. A product is classified by what it fundamentally does (Art 7(1), Implementing Reg 2025/2392) — not by every capability it contains. An embedded Class I component does not reclassify the host product. But two things still follow:
- The whole product must meet the Annex I essential requirements regardless of the tier of what is inside it.
- A component placed on the market separately carries its own classification and its own conformity route. Selling the module as a product, as well as building it into your own, means two obligations, not one.
What to do with this
Write down, per part number: does it have security-related functionality; is it tamper-resistant as the Implementing Regulation describes it; is it sold separately. Those three answers produce the tier, and the tier produces the route. Do it now rather than in 2027, because for anything above default the route has a lead time attached.
If it lands anywhere other than default, the follow-on question is which harmonised standards or EUCC scheme you intend to ride, and whether that is realistic on your timeline. We work through both with manufacturers, and we build the Annex I evidence so the conformity assessment reviews work already done rather than becoming a project of its own.
If you would rather run it yourself, the CRA Workbench carries the same classification logic and Annex I evidence structure as a workspace.