On June 11, 2026, EU Member States must have completed the formal designation of notified bodies under CRA Chapter IV. This deadline sounds like an administrative milestone — but for software developers building products that fall under CRA Annex III, it triggers a critical question: does your product require a notified body assessment, or can you self-declare conformity?

The answer determines your compliance timeline, your budget, and whether you need to start engaging a third-party conformity assessment body right now. Most CRA guides gloss over this distinction. This one does not.

The Three-Tier CRA Product Classification

The CRA creates three categories of products based on their cybersecurity risk profile. Your conformity assessment path depends entirely on which category your software product falls into.

Tier 1: Default Products — Self-Declaration Available

The vast majority of software products fall here: everything not listed in CRA Annex III. This includes typical SaaS tools, mobile apps, productivity software, developer tooling, and consumer-facing applications.

Conformity assessment required: Module A (Internal Production Control)

Module A means no notified body. You:

1. Perform a conformity assessment yourself
2. Draw up technical documentation (Annex V)
3. Draw up an EU Declaration of Conformity (DoC)
4. Affix the CE marking

The entire process is internal. You are declaring to the EU that your product meets CRA Annex I essential requirements based on your own assessment. No third-party audit. No external review.

This is the path for the overwhelming majority of software developers.

Tier 2: Important Products — Class I (Self-Declaration Option Available)

CRA Annex III lists 13 product categories as "important products with digital elements." Class I products have a choice of conformity assessment procedures.

Products in Class I include:

Conformity assessment options for Class I:

• Module A (self-declaration) — if EU harmonised standards exist covering the essential requirements you rely on, and you apply them fully, you may self-declare using those standards
• Module B + C — EU Type-Examination by a notified body followed by manufacturer's conformity declaration to type
• Module H — Full Quality Assurance assessed by a notified body

The catch: For Class I, Module A is only straightforward if the relevant harmonised standards exist and have been published in the Official Journal. As of 2026, the CRA harmonised standards are still in development (ETSI EN 18031 is the leading candidate, not yet OJ-referenced for CRA). Without harmonised standards, you must demonstrate conformity through a Common Specification or direct Annex I compliance assessment — which adds significant documentation burden to Module A and makes Module B an attractive alternative for Class I products.

Tier 3: Important Products — Class II (Notified Body Mandatory)

Class II products carry higher cybersecurity risk. CRA Art.25 requires notified body involvement for all Class II products. Self-declaration is not available.

Products in Class II include:

Conformity assessment required: Module B + C, or Module H

• Module B: A notified body examines your technical documentation and a representative sample of your product and issues an EU Type-Examination Certificate.
• Module C: You declare that your manufactured product conforms to the approved type (follows Module B).
• Module H: A notified body approves your Quality Management System and issues QMS approval. Individual product certification follows from QMS governance.

Module H is typically chosen by high-volume manufacturers who want a single QMS approval covering multiple products over multiple years, rather than repeating Module B per product.

The June 11 Deadline and What It Actually Means

CRA Chapter IV (Articles 26–31) sets out the requirements for notified body designation. The June 11, 2026 deadline is when Member States must have submitted their notifications to the European Commission.

What this means in practice:

1. Member States designate national conformity assessment bodies as CRA notified bodies
2. The Commission publishes these designations in NANDO (the New Approach Notified and Designated Organisations database)
3. Manufacturers can then formally engage designated notified bodies for Module B/H assessments

The bottleneck risk: CRA is new. Notified bodies with CRA scope are expected to be very few in number immediately after designation. Bodies already operating in cybersecurity product certification (EUCC scheme under ENISA) are the most likely candidates, but CRA adds a broader regulatory scope. Expect:

• Fewer than a dozen EU-wide notified bodies with full CRA scope in H2 2026
• Long booking queues for Class II products seeking Module B certificates
• Lead times of 6–12 months from engagement to certificate for complex products

If you build Class II products: The June 11 designation date is your signal to start identifying notified bodies and initiating preliminary contact — not to wait for the NANDO list to populate and then queue.

The Complete Decision Tree

Use this flow to determine your conformity assessment path:

Step 1: Is your product covered by CRA Art.2 scope?
  - Is it a "product with digital elements" (hardware/software with network connectivity)?
  - If YES → continue to Step 2
  - If NO (pure B2B service, open-source component without commercial activity) → CRA may not apply directly

Step 2: Is your product in CRA Annex III?
  - Check the 13 product categories in Annex III
  - If NO → Default product → Module A (self-declaration) → DONE
  - If YES → continue to Step 3

Step 3: Is your product Class I or Class II in Annex III?
  - Class I → Step 4
  - Class II → Step 5

Step 4: CLASS I — Choose your Module
  - Are fully harmonised CRA standards available for your essential requirements?
    - YES → Module A (self-declaration) is straightforward
    - NO (2026 reality) → Module A requires direct Annex I compliance evidence
                           → Module B + C (notified body type-examination) is often simpler
  - Decision: Do you have the internal compliance documentation capacity?
    - YES → Module A (self-declaration)
    - NO → Engage a notified body, proceed with Module B + C

Step 5: CLASS II — Notified Body is Mandatory
  - Module B + C: Type examination per product line
  - Module H: QMS approval covering multiple products
  - Decision: Single product / small volume → Module B + C
               Multiple products / high volume → Module H
  - Action NOW: Identify designated notified bodies via NANDO post June 11
               Initiate pre-assessment contact immediately

Annex III Classification Checklist

Run through this before concluding you are a "default" (self-declaration) product:

Identity & Access:

• Does your product manage user identities or access privileges (PAM, SSO, AD-like systems)?
• Does your product store or manage passwords as a primary function?

Network & Security Infrastructure:

• Is your product a network management tool (monitoring, configuration, SNMP)?
• Is your product a SIEM or security event aggregator?
• Is your product a VPN or remote access gateway?
• Is your product an IDS/IPS solution?
• Is your product a browser (standalone or embedded, consumer or enterprise)?

Hardware/Firmware:

• Does your product run on or is it a microcontroller/microprocessor used in an important application?
• Is your product a smart meter, smart grid controller, or similar utility device?
• Is your product an HSM, smart card, or tamper-resistant security element? (→ Class II)
• Is your product a hypervisor or container runtime? (→ Class II)
• Is your product an industrial control system, PLC, or DCS? (→ Class II)
• Is your product a general-purpose operating system? (→ Class II)
• Is your product an enterprise/industrial firewall? (→ Class II)

If you check none of the above: you are a default product. Module A applies. If you check one or more: read the exact Annex III category text and consult the CRA Annex III official description — the exact scope matters.

What Self-Declaration (Module A) Actually Requires

Even if you are a default product (or a Class I product choosing Module A), the self-declaration process is not trivial. CRA Art.25 in combination with Annex VIII Module A requires:

1. Technical Documentation (Annex V)

You must draw up and maintain technical documentation covering:

• General description of the product (design, architecture, data flows)
• Cybersecurity risk assessment
• Evidence of essential requirements compliance (Annex I, Part I and Part II)
• List of harmonised standards applied (or alternative compliance methods)
• Vulnerability handling procedures
• SBOM at the point of placing on market

2. EU Declaration of Conformity (Annex VI)

A formal document stating:

• Your company identity and contact
• Product identifier (name, model, version)
• That the product conforms to CRA essential requirements
• Reference to harmonised standards applied (if any)
• Your signature and date

3. CE Marking

The CE marking must be affixed to the product (or, for software, to the documentation and packaging). It must be visible, legible, and indelible. For purely digital products, the CE marking appears on the product's official download page, documentation, and user interface.

4. Economic Operator Obligations

Under CRA Art.13, you must also have in place (before the DoC is valid):

• A vulnerability handling process
• Security update provision capability (throughout the support period)
• Coordinated Vulnerability Disclosure (CVD) policy (Art.15)

The DoC is invalid if these operational requirements are not met.

The Harmonised Standards Problem in 2026

The CRA's Module A route assumes harmonised standards published in the EU Official Journal. These standards allow manufacturers to use a "presumption of conformity" — if you fully apply the standard, you are presumed to meet the corresponding essential requirements.

Current reality (May 2026):

In practice: No fully CRA-harmonised standard with OJ reference exists as of May 2026. Module A self-declaration therefore requires direct Annex I compliance assessment without harmonised standard presumption — a higher documentation burden.

Pragmatic approach for Class I manufacturers choosing Module A:

• Apply ETSI EN 303 645 (if IoT) or EN 18031 (if network-connected product) as a technical baseline, document coverage and gaps
• Reference NIST SP 800-218 (SSDF) for secure development lifecycle evidence
• Use the ENISA Security by Design Playbook v0.4 principles as gap analysis framework
• Document why each Annex I essential requirement is met, even absent an OJ-referenced standard

Action Plan by Product Class

Default Product Developer (Module A)

Before September 11, 2026 (CRA Art.14 vulnerability reporting starts):

1. Classify your product against Annex III — confirm you are not Class I or II
2. Draft technical documentation per Annex V
3. Implement a CVD policy (Art.15)
4. Implement a security update process (Art.13)
5. Draft EU Declaration of Conformity (Annex VI)
6. Affix CE marking (digitally, as appropriate)

Timeline: 3–4 months for a prepared team. Start no later than July 2026.

Class I Developer (Choosing Module A)

Additional burden above default:

• Your product is on the Annex III list → regulators and market surveillance authorities will apply higher scrutiny to your self-declaration
• Without harmonised standards, every essential requirement needs direct evidentiary coverage
• Consider engaging a legal/technical consultancy to peer-review your DoC before finalisation
• Budget: €15,000–€50,000 depending on product complexity

Alternative: Module B + C via a notified body. More expensive upfront (€20,000–€80,000 for assessment fee + preparation) but the certificate provides a stronger compliance position and reduces regulatory risk.

Class II Developer (Module B or H — Mandatory)

Immediate actions (before June 11, 2026):

1. Monitor NANDO for CRA-scope notified body designations as they are published
2. Prepare pre-assessment package: technical architecture, existing certifications (Common Criteria, EUCC), SBOM, risk assessment
3. Issue RFQs to candidate conformity assessment bodies with CRA scope
4. Budget €50,000–€200,000+ for Module B type-examination, depending on product complexity

Timeline risk: If you wait until post-June 11 to begin, you may face 12+ month queues at overbooked notified bodies. Class II products cannot place on the EU market without a valid notified body certificate under CRA. This is a hard block.

Module H consideration: If you manufacture multiple Class II products (e.g., an industrial OS vendor with five variants), Module H (QMS approval) may be more cost-efficient over a 5-year horizon than per-product Module B certificates. Engage a notified body for a preliminary QMS gap assessment now.

Key Dates

Note: the December 11, 2027 full CRA application date means that the window for completing conformity assessment (notified body or self-declaration) is roughly 18 months from today. For Class II products with 12+ month assessment lead times, that leaves less than 6 months of buffer.

Common Misconceptions

"My SaaS product is not in scope because it's a service, not a product."

If your SaaS product includes a component that is downloaded, installed, or runs locally (desktop app, mobile app, browser extension, on-premise agent), that component is "software placed on the market" under CRA Art.2. The cloud backend may be out of scope; the client component is not.

"Open source is exempt."

CRA Art.8 creates an open-source steward category with reduced obligations, but only for non-commercial open-source distribution. If you commercially distribute an open-source product (even under an open-source licence), the normal CRA manufacturer obligations apply.

"I can wait until 2027 to start the conformity assessment."

For Class II products with mandatory notified body involvement, 2027 is too late. Assessment timelines for complex products can exceed one year. If you begin in 2027 and the December 2027 deadline arrives without a certificate, you cannot legally place or continue placing your product on the EU market.

"Self-declaration is just signing a form."

Module A requires the underlying technical documentation, risk assessment, CVD policy, and update process to exist and be accurate. The DoC is the declaration that you have done this work — not the work itself. Signing a DoC without the substantive compliance in place is regulatory fraud.

See Also

Related CRA posts on this blog:

• CRA Art.25: Conformity Assessment Procedures — Annex VIII Modules Explained
• CRA Art.26: Notified Body Requirements and the Notification Procedure
• CRA Art.13: Manufacturer Obligations — Security by Design and Update Support
• CRA Harmonised Standards Gap 2026: Self-Assessment Before Standards Arrive
• ENISA Security by Design Playbook v0.4: CRA Annex I Developer Guide
• ENISA Secure Package Manager Advisory: CRA Supply-Chain Compliance
• CRA Art.22: Technical Documentation Requirements — Annex V and VI