A robust CRA classification record should contain the product functionality, Annex category, class, technical-description reference, legal version and conformity consequence. When a delegated or implementing act changes that framework, the company can then identify affected product families quickly instead of repeating the classification exercise from memory.
Annex III Is Designed to Be Updateable
Article 7(3) empowers the Commission to amend Annex III. A new product category can be added within class I or class II, a category can be moved from one class to the other or an existing category can be withdrawn. The Commission must assess the cybersecurity-related functionality and risk criteria specified in Article 7 when deciding whether the list should change.
- Add a category.
- Move a category between classes.
- Withdraw a category.
- Apply Article 7 cybersecurity-function and risk criteria.
A Class Change Can Alter the Conformity Assessment Route
Class I and class II important products are subject to different Article 32 conformity-assessment consequences depending on standards, common specifications and certification routes. A product-category move between classes is therefore not merely a taxonomy update. Manufacturers should reassess conformity planning, notified-body needs where applicable, technical documentation and market-release timing.
- Reassess Article 32 route.
- Review third-party assessment needs.
- Update technical documentation.
- Review release and transition plans.
Article 7 Provides Transition Time for Important-Product Category Changes
Article 7 states that delegated acts amending Annex III should, where appropriate, provide a minimum transitional period of 12 months when adding a new important-product category or moving a category from class I to class II, unless a shorter period is justified on imperative grounds of urgency. Companies should use the transition period for product inventory, evidence and conformity-route changes rather than wait until the final application date.
- Record transition start and end.
- Identify affected products.
- Plan assessment capacity.
- Update release gates before the new route applies.
Annex IV Critical-Product Categories Can Also Change
Article 8 empowers the Commission to amend Annex IV by adding or withdrawing critical-product categories based on the statutory criteria. It also allows delegated measures determining which products with the core functionality of an Annex IV category must obtain a European cybersecurity certificate at an assurance level proportionate to risk when the required certification scheme is available.
- Monitor Annex IV amendments.
- Monitor certification measures.
- Check scheme availability.
- Assess required assurance level.
Technical Descriptions Clarify Categories Without Replacing the Annexes
Article 7(4) required technical descriptions for the Annex III and Annex IV categories, now provided through Commission Implementing Regulation (EU) 2025/2392. These descriptions support consistent interpretation of category boundaries. They should be used with the Annex category and product core functionality rather than treated as a separate replacement classification system.
- Use current technical descriptions.
- Map them to Annex categories.
- Focus on core functionality.
- Track amendments to the implementing regulation.
Classification Should Be Reassessed When the Product Changes Too
Regulatory updates are not the only reason to revisit classification. A product can gain new core functionality, be substantially modified or move into a different product family. The classification register should therefore have both regulatory and product-change triggers so an old conclusion is not carried forward automatically after a major release.
- New core functionality.
- Substantial modification.
- New product variant.
- New Annex or technical-description rule.
Maintain a Versioned Classification Record
The classification record should identify the product version, core functionality, Annex category, class or critical status, technical-description source, legal version, reviewer and conformity consequence. Versioning makes it possible to explain why an older product release followed one route while a later release is assessed under a changed classification framework.
- Product and version.
- Core functionality.
- Annex category and class.
- Technical description.
- Legal source version.
- Conformity consequence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.