Choosing the CRA conformity route

Scope: one product portfolio, class test to signed declaration · Who: the officer who decides the route · Prerequisites: a dated product list and a named signatory · First result: one route decision

1. Why this exists (the failure mode it prevents)#

A conformity route is a decision with a lead time attached. Decided late, it stops being a decision and becomes whatever the calendar allows.

Five patterns end the same way. The route is settled on a call with a body that sells assessment. A management-system certificate is read as product conformity, so nothing product-specific is prepared. A class I product is assessed as a default product, because nobody ran the Annex III test. A harmonised standard is assumed to exist, and internal control chosen on that assumption. The declaration is signed by whoever was in the room.

Each surfaces against a named provision. The Regulation offers four procedures, and the product's class decides which are open ¹. Before placing, the manufacturer draws up technical documentation and carries out the chosen procedure, or has it carried out. The declaration and the CE marking follow ². The Regulation applies in general from 11 December 2027 ³.

One loop, not three silos. Which route a product takes is governance's decision, and so is naming who signs. Where a third-party route was open and self-assessment chosen, governance names who accepts that residual risk. The instrument the route rests on is risk's. That assessment is documented, kept current through the support period, and states how the Part I and Part II requirements apply ⁴. Compliance produces the assessment output and the file it leaves behind. Governance ensures protection, compliance demonstrates it, and both exist to manage risk.

2. Definitions (only the ones that cause disputes)#

Term	Working definition	Source
Product with digital elements	A software or hardware product with its remote data processing solutions, including components placed on the market separately.	Art. 3(1) 5
Manufacturer, placing on the market	Whoever develops or makes such a product, or has it made, and markets it under their own name or trademark, whether or not for payment. Placing on the market is the first making available on the Union market.	Art. 3(13), 3(21) and 3(22) 6
Substantial modification	A post-market change affecting compliance with the Part I requirements, or changing the intended purpose the product was assessed against.	Art. 3(30) 7
Default, important, critical	Annex III core functionality makes a product important, class I or class II; Annex IV makes it critical. Everything else is default, a word the guidance uses and the Regulation does not define.	Art. 7(1) and 8(1); Annexes III and IV 8. Guidance 6, point 137, footnote 22 9
Conformity assessment, module	Verifying that the Annex I requirements are met. The modules are the four Annex VIII procedures the Regulation makes available.	Art. 3(27), Art. 32(1) 10
Harmonised standard, presumption of conformity	A standard as defined in the standardisation Regulation. It counts only once its reference is published in the Official Journal; conformity is then presumed for the requirements it covers.	Art. 3(36), Art. 27(1) 11
Notified body	A conformity assessment body designated under the notification procedure. It is a third party, independent of the organisation and product it assesses, and takes on nothing that conflicts with its independence, consultancy in particular.	Art. 3(29), Art. 39(3) 12
EU declaration of conformity, CE marking	The signed statement in the Annex V structure, carrying what the chosen procedure specifies. The marking indicates conformity with the Annex I requirements.	Art. 28(2), Art. 3(31) 13
Product conformity assessment, management-system certification	Different objects. Here a product and its manufacturer's processes are assessed against Annex I. Certifying a management system is third-party conformity assessment of a system, under a standard spanning systems of every type.	ISO/IEC 17021-1:2015 clause 1 14

3. The method — numbered steps, each with input, activity, output and owner#

3.1 Inventory the products and their placing-on-the-market dates#

• Input: the release register, the versions still supplied, the support-period records.
• Activity: list every product with digital elements marketed under the organisation's own name, recording when each was first made available on the Union market. Products placed before 11 December 2027 take the substantive requirements only on a substantial modification from that date ¹⁵. A product designed earlier but placed afterwards need not be redesigned; the risk assessment decides, and the procedure still runs ¹⁶.
• Output: a dated inventory carrying the transitional status per row.
• Owner: product compliance, each date confirmed by the product manager.

Variants sharing architecture, security-relevant design, intended purpose and risks can take one risk assessment, one file and one assessment. Colour, form factor and memory size do not force a split; different interfaces, software stacks, update mechanisms or remote connectivity do ¹⁷.

3.2 Run the class test per product and record it#

• Input: the inventory, the intended purpose, the documentation of what the product does.
• Activity: determine core functionality, then test it against the Annex III and Annex IV categories. Core functionality means the main features and technical capabilities a product needs to serve its intended purpose ¹⁸. Those categories carry printed technical descriptions, set by Commission Implementing Regulation (EU) 2025/2392 under Article 7(4), published 1 December 2025 ¹⁹. Integrating a component with an Annex III core functionality does not by itself move the finished product into the important categories ²⁰. The class of the whole governs, even where an integrated component is itself critical ²¹.
• Output: a class decision per product, citing the annex point and technical description relied on.
• Owner: product compliance; risk supplies the functional analysis.

The scope test, the exclusions and the operator roles sit in CRA obligations by product class. Record the result, and who disagreed.

3.3 Read Article 32 for the class#

• Input: the class decision, and a written answer to which standards, specifications or schemes were applied, and how completely.
• Activity: map the class onto the procedures the Regulation opens, then delete the closed ones.
• Output: the permitted routes per product, with the reason each excluded route is excluded.
• Owner: the officer accountable for product compliance.

Class	Routes open	What closes a route
Default	Module A, module B with C, module H, or a European cybersecurity certification scheme where available	No route is closed 22
Important, class I	The same four, module A open only where relevant standards, common specifications or schemes at assurance level at least substantial were applied in full	Not applied, applied in part, or absent: those requirements go to B with C, or H 23
Important, class II	Module B with C, module H, or a scheme at assurance level at least substantial	Module A is not available 24
Critical, Annex IV	A scheme under Article 8(1), or any class II route where its conditions are not met	A delegated act can make a certificate compulsory 25
Open-source software in an Annex III category	Any Article 32(1) procedure, if the technical documentation is public at placing	The documentation is not made public 26

Two conditions keep module A open for a class I product. Every applicable requirement of a relevant harmonised standard has to be applied, and the standard has to cover at least the risks of the core functionality; measures for anything beyond it are documented. Third-party involvement stays mandatory for class II and critical products; the open-source relief reaches important products only ²⁷.

Presumption of conformity is narrower than route eligibility, and the two are routinely confused. A published standard carries the presumption only for the requirements it covers. A certificate at assurance level at least substantial removes the third-party obligation only for those requirements ²⁸. Functionality outside a standard's scope carries none ²⁹.

What exists today, and what does not. The Commission's listing of legislation with published harmonised-standards references does not name this Regulation ³⁰. The standardisation request is M/606, covering 41 standards, the work led by the European standardisation organisations ³¹. On 5 September 2026 the Commission's milestone list put first deliverables in the third quarter of 2026, further ones on 30 October 2027 ³². Plan on the Official Journal as it stands at placing, not on a draft.

3.4 Decide the route, with the decision rights written down#

• Input: the permitted routes, the standardisation position, the lead times.
• Activity: decide in a forum with the authority to decide, recording who decided, who signs, which route was chosen and why the others were not. Where a third-party route was open and self-assessment was chosen, record the residual risk and the role accepting it. The signature is not clerical: drawing up the declaration is how the manufacturer assumes responsibility for compliance ³³.
• Output: a route decision record per product, dated and minuted.
• Owner: governance, through the forum that already carries release decisions.

Where that forum sits is set out in governing security in the product organisation.

Governance owns the choice of procedure and the signatory, risk owns the documented assessment beneath it, and compliance later shows the evidence trail the route leaves.

3.5 Know what the chosen route produces#

• Input: the route decision.
• Activity: turn the module into a named artefact list, taken from Annex VIII rather than a body's proposal document.
• Output: an evidence list per product, each item with an owner and a date.
• Owner: product compliance.

Module A, internal control. The manufacturer draws up the Annex VII documentation and takes the measures that make design, development, production and vulnerability handling deliver compliance. The CE marking is affixed and a written declaration drawn up per product. Both stay available to national authorities for ten years after placing, or for the support period if longer ³⁴.

Module B, EU-type examination. One application goes to a single notified body of the manufacturer's choice, with a written declaration that it is not lodged elsewhere. It carries the technical documentation, with an adequate analysis and assessment of the risks. Supporting evidence names any documents used, in particular where standards were not applied in full ³⁵. The body examines, verifies specimens, tests, reports and issues the certificate, then audits the vulnerability handling processes periodically. A modification affecting conformity needs an addition to that certificate ³⁶.

Module C, conformity to type. Module B is completed by module C. Production keeps units conforming to the approved type; the marking is affixed and a declaration drawn up per model ³⁷.

Module H, full quality assurance. An approved quality system covers design, development, final inspection and testing, and vulnerability handling. It stays effective through the support period under surveillance, documented as policies, procedures and instructions ³⁸. Assessment includes a visit where premises exist. The auditing team carries assessor experience in the product field concerned. Changes are notified and periodic audits produce a report. The body's identification number joins the CE marking ³⁹.

Every route ends at the same two artefacts. Technical documentation is drawn up before placing and kept current through the support period ⁴⁰. Its Annex VII elements include the risk assessment and how the Part I requirements apply ⁴¹. They also include what set the support period, the standards applied with their parts identified, and the test reports ⁴². The declaration follows the Annex V model, naming the body and certificate where there is one ⁴³.

That engineering is not invented here. A documented and enforced development process, with configuration management, requirements traceability, repeatable verification and validation, and review of development records, is IEC 62443-4-1:2018 SM-1 Development process ⁴⁴. ISO/SAE 21434:2021 supplies the vocabulary: the cybersecurity case is the argument its work products support ⁴⁵.

3.6 Choose and engage a notified body#

• Input: the route decision, the product's class and technology, the assessment window.
• Activity: confirm notification status and notified scope, then agree timing and the evidence due at each date.
• Output: an engagement plan naming the module, the scope and the dates.
• Owner: product compliance; procurement follows the decision.

Notification is a published fact, not a claim. Chapter IV has applied since 11 June 2026, which is what allows bodies to be notified at all ³. The Commission assigns an identification number and publishes the list with the activities notified. A body may act only where no objection is raised: two weeks with an accreditation certificate, two months without ⁴⁶.

Three provisions repay attention before the first meeting. The body is a third party, independent of the organisation and the product it assesses. Its people are not involved in designing or maintaining what they assess, and consultancy is named alongside ⁴⁷. Subcontracting, or use of a subsidiary, needs the manufacturer's agreement ⁴⁸. Assessment is proportionate without lowering the required rigour. Where the Annex I requirements are unmet, the body demands corrective measures and issues no certificate ⁴⁹.

Hosting a third party has a rhythm, set out in running the external audit. What differs is the object. A management-system certification body audits a management system, and its standard reaches systems of every type ¹⁴. A notified body examines a product's technical design and development, and the manufacturer's vulnerability handling processes ⁵⁰. Reuse the audit muscle; not the certificate.

3.7 Set the re-assessment triggers#

• Input: the change process, the release plan, the route decision record.
• Activity: write the test that turns a change into a conformity event, and put it in the release gate.
• Output: a change-to-conformity rule, naming the assessment for each outcome.
• Owner: release engineering, with product compliance adjudicating.

A substantial modification is a post-market change affecting Part I compliance, or changing the assessed intended purpose ⁷. Where one occurs and the modified product is made available, the guidance treats that as a new product newly placed on the market ⁵¹.

For software the test turns on risk, not release numbering. A change is substantial where it alters the level of cybersecurity risk and that altered risk was not already assessed. New functionality changing the intended purpose will generally qualify; functionality already anticipated and mitigated generally will not ⁵².

Consequences differ by who made the change. The original manufacturer stays the manufacturer and may reuse documentation and tests for parts not affected. The assessment concentrates on the modified parts, as a third-party body is expected to do ⁵³. Anyone other than the importer or distributor who modifies and makes available becomes the manufacturer. Articles 13 and 14 then apply to the affected part, or to the whole product where the change reaches it ⁵⁴.

Existing certificates buy time, not exemption. EU type-examination certificates and approval decisions issued for cybersecurity requirements under other Union harmonisation legislation stay valid until 11 June 2028, unless they expire sooner ⁵⁵. The guidance reads those as evidence limited to the risks that legislation covered ⁵⁶. The risk assessment obligation, and any risk it leaves uncovered, stay with the manufacturer.

3.8 Build the calendar backwards from 11 December 2027#

• Input: the route decisions, the engagement plan, the release plan.
• Activity: put every dated obligation on one calendar, working backwards from the assessment window.
• Output: a conformity calendar, one named owner per milestone.
• Owner: governance, reviewed at the forum that took the route decision.

Date	What it fixes	Source
1 December 2025	Technical descriptions of the important and critical categories are published	57
11 June 2026	Chapter IV applies; conformity assessment bodies can be notified	3
11 September 2026	Article 14 applies; reporting duties reach products already placed	58
11 December 2026	Member States strive to have enough notified bodies, avoiding market-entry bottlenecks	59
11 December 2027	General application; earlier products reached only on substantial modification	60
11 June 2028	Certificates and approval decisions under other Union legislation lapse, unless that legislation says otherwise	55

The reporting duty runs on its own clock. Its readiness plan is at /radar#cra-reporting-obligations; the guidance at /radar#cra-commission-guidance.

3.9 Measure the four things that move#

• Input: the inventory, the class, route and engagement records.
• Activity: report four counts monthly, each with its denominator.
• Output: a one-page conformity position.
• Owner: product compliance.

Products classed, annex point cited. Routes decided, signatory named. Technical files complete against the Annex VII element list. Bodies engaged, window contracted. A programme that cannot state those four is not behind; it does not know where it is.

4. Deliverables#

Deliverable	Format	Template	Retention
Product inventory with class and route	xlsx	pending	Life of the product plus the support period
Class and route decision record, with signatory and accepted residual risk	markdown	/templates/risk-acceptance-record	Ten years after placing on the market
Technical documentation per Annex VII	mixed	pending	Placing plus ten years, or the support period
Notified-body engagement plan	markdown	pending	Life of the certificate
Calendar	markdown	pending	Current plus one version
Change-to-conformity rule in the release gate	markdown	pending	Current version

Self-assessment where a third-party route was open is an accepted risk, not a preference.

5. What the notified body or market surveillance authority will ask#

• "Show the class decision for this product, and the technical description you tested its core functionality against." — evidence: the class decision record, citing the annex point and the implementing act.
• "Which harmonised standards did you apply, in full or in part, and which parts?" — evidence: the Annex VII element listing the standards, with the parts identified and the alternatives adopted.
• "Show the risk assessment, and where it says which Part I requirements apply and how." — evidence: the dated risk assessment inside the technical file.
• "Who signed the declaration, and under what authority?" — evidence: the route decision record and the signed declaration.
• "This release changed the update mechanism. Why was that not a substantial modification?" — evidence: the change-to-conformity assessment and its risk comparison.
• "Which risks does the certificate you rely on actually cover?" — evidence: that certificate's scope mapped to the Annex I requirements.

6. Failure modes and how they surface#

• The route follows the calendar rather than the class. Self-assessment is chosen because the window closed. Surfaces as a procedure mismatch: a class I product on module A with no standard applied in full. Smallest fix: put the assessment window on the release plan at design freeze.
• A management-system certificate stands in for product conformity. Surfaces as a declaration with no Annex VII documentation behind it. Smallest fix: name the object of every certificate held.
• The class test is run against the product name, not its core functionality. Surfaces as a class decision citing no annex point. Smallest fix: require the annex point and the technical description in the record.
• Presumption of conformity is claimed for the whole product. A standard covering core functionality is treated as covering everything. Surfaces as unaddressed risk in ancillary functions. Smallest fix: list what the standard does not reach, and what covers it.
• Substantial modification is decided by release numbering. Surfaces as a modified product on the market behind an unchanged technical file. Smallest fix: make the risk comparison the gate question.
• Nobody owns the signature. Surfaces when a declaration is needed and no role holds the authority. Smallest fix: name the signatory in the route decision, before assessment starts.

7. Mapping to instruments and standards#

Step	CRA article or annex	Guidance	Standard analogue	Evidence
3.1 Inventory and dates	Art. 3(21), Art. 69(2) 61	2.7, 7.4	ISO/IEC 27001:2022 clause 8.1 Operational planning and control 62	Inventory
3.2 Class test	Art. 7(1), Art. 8(1), Annexes III and IV 8	6.1	IEC 62443-4-1:2018 SM-3 Identification of applicability 63	Class decision
3.3 Route options	Art. 32, Art. 27 64	6.2, 6.3	ISO/IEC 27002:2022 control 8.25 Secure development life cycle 65	Route list
3.4 Route decision	Art. 28(4) 33	—	ISO/IEC 27001:2022 clause 5.3 Organizational roles, responsibilities and authorities 66	Decision minute
3.5 Module outputs	Annex VIII, Annex VII 67	—	IEC 62443-4-1:2018 Practice 5 Security verification and validation testing 68	Technical file
3.6 Notified body	Art. 39, 41, 43, 44, 47 69	—	ISO/IEC 17021-1:2015 clause 1, for the contrast 14	Engagement plan
3.7 Re-assessment	Art. 3(30), Art. 22, Art. 69(1) 70	4.3, 4.4, 9.3.2	ISO/IEC 27002:2022 control 8.32 Change management 71	Change decisions
3.8 Calendar	Art. 71(2), Art. 35(2) 72	—	ISO/SAE 21434:2021 clause 6.4.2 Cybersecurity planning 73	Conformity calendar

Neither certification nor a clause mapping demonstrates product conformity.

8. Checklist#

• Every product marketed under the organisation's name is in the inventory, with its date of placing and whether that was before 11 December 2027.
• Variants grouped under one assessment carry a written statement of why their security properties do not differ.
• Each product has a class decision naming the annex point, or recording that no category matches, and citing the technical description in the implementing act.
• The permitted routes are listed per product, with the reason each exclusion holds.
• Every class I product on module A names the standard applied, confirms it was applied in full, and states which risks it leaves uncovered.
• The route decision record names who decided and who signs, and where self-assessment was chosen over an open third-party route, who accepted the residual risk.
• Documentation exists against every Annex VII element, with a location, and the risk assessment in it is dated.
• A declaration in the Annex V structure exists in draft, signatory block filled, and the body's notification scope has been checked against the module and product.
• The release gate carries the change-to-conformity question, answered per release.
• Reliance on a certificate under other Union legislation is mapped to the Annex I requirements it covers.
• The conformity calendar carries every dated milestone, each with an owner.

Related#

• CRA obligations by product class — the scope and class test this playbook starts from.
• Product CSMS as a management system — the operating system behind the evidence.
• Product cybersecurity under R155, ISO 21434 and the CRA — one evidence set, three instruments.
• Governing security in the product organisation — where the route decision is taken.
• Running the external audit — the rhythm of hosting a third party.
• /radar#cra-reporting-obligations and /radar#cra-commission-guidance — the dated entries behind these clocks.

References#

1. European Parliament and Council. Regulation (EU) 2024/2847 (Cyber Resilience Act). OJ L, 2024/2847, 20.11.2024. https://publications.europa.eu/resource/celex/32024R2847 ⁷⁴
2. European Commission. Commission Implementing Regulation (EU) 2025/2392, technical description of the important and critical categories. OJ L, 2025/2392, 1.12.2025. https://publications.europa.eu/resource/celex/32025R2392 ⁷⁵
3. European Commission. Commission guidance on the application of the Cyber Resilience Act, annex to C(2026) 5252, 27.7.2026. https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation ⁷⁶
4. Cyber Resilience Act — Standardisation, European Commission. https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation ³¹
5. Cyber Resilience Act — Implementation, European Commission. https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation ³²
6. Harmonised Standards, European Commission. https://single-market-economy.ec.europa.eu/single-market/goods/european-standards/harmonised-standards_en ³⁰
7. ISO/IEC 17021-1:2015. https://www.iso.org/standard/61651.html ¹⁴
8. IEC 62443-4-1:2018. https://webstore.iec.ch/en/publication/33615 ⁴⁴
9. ISO/SAE 21434:2021. https://www.iso.org/standard/70918.html ⁴⁵
10. ISO/IEC 27002:2022. https://www.iso.org/standard/75652.html ⁶⁵
11. ISO/IEC 27001:2022. https://www.iso.org/standard/27001 ⁶²
12. Regulation (EU) 2019/881 (Cybersecurity Act). OJ L 151, 7.6.2019, p. 15. https://eur-lex.europa.eu/eli/reg/2019/881/oj/eng ⁷⁷