2026-05-04·12 min read·sota.io team

CRA Notified Body vs. Self-Declaration: What Developers Must Decide Before June 11, 2026

Post #818 in the sota.io EU Compliance Series

June 11, 2026 is the deadline for EU Member States to designate Notified Bodies under the EU Cyber Resilience Act (CRA). If your software product requires third-party conformity assessment—and some products do—those Notified Bodies need to exist before you can complete your compliance process.

The clock is running. If you haven't determined which conformity route applies to your product, you may find yourself in a queue behind everyone else who waited until June.

This guide walks through the CRA's conformity assessment framework: who can self-declare, who must involve a Notified Body, and what to do in each case.


The Core Question: Which Conformity Route Applies to You?

The CRA defines conformity assessment through a tiered classification system. Your product's classification determines whether you can self-assess or must use a third party.

Product ClassConformity RouteExample Products
Class I (Default)Self-assessment (Module A or Module H)Most commercial software, SaaS, APIs
Class IIThird-party Notified Body OR internal audited assessmentHypervisors, identity management software, password managers
Critical Products (Category 1)Third-party Notified Body mandatoryOS kernels, hardware security modules, smartcard OS
Critical Products (Category 2)European cybersecurity certification mandatorySpecific hardware/firmware listed in Annex III

Most SaaS developers writing business software fall into Class I. But the CRA's Annex III lists specific product categories where the stakes are higher and the conformity bar is stricter.


Class I: What Self-Declaration Actually Covers

If your product is Class I, you have two self-assessment paths:

Module A (Internal Production Control): The manufacturer conducts the conformity assessment internally, without any third-party involvement. You create a Technical File, implement the security requirements in Annex I, and issue an EU Declaration of Conformity (DoC). This is the default route for most software manufacturers.

Module H (Full Quality Assurance): An alternative for manufacturers with certified quality management systems (ISO 9001 or equivalent). Slightly more structured than Module A but still self-administered.

For Class I self-declaration, you need to produce and maintain:

  1. Technical File — Documentation of your product's intended purpose, security risk assessment, secure development lifecycle practices, software bill of materials (SBOM), and vulnerability handling procedures.

  2. EU Declaration of Conformity — A formal document stating that your product meets the CRA's essential requirements. This must reference the specific CRA provisions you're complying with.

  3. CE Marking — Applied to your product or its packaging/documentation once conformity is established.

The Technical File does not need to be submitted to any authority proactively. But market surveillance authorities can request it at any time, and you must provide it within 10 days of a request. Keep it current.


Class II: The Notified Body Decision

Class II products are those the European Commission has determined present elevated cybersecurity risk. The current list in Annex III includes:

If your product appears on this list, you have two options under Class II:

Option A: Third-party Notified Body assessment. A designated Notified Body audits your product against the CRA's Annex I requirements and issues a certificate. This is the most defensible route from a market surveillance perspective.

Option B: Internal assessment with quality system audit. Module H applied to Class II products still requires a Notified Body to approve your quality management system—but the Notified Body assesses your processes rather than auditing each product individually. Once your quality system is certified, you can issue conformity declarations for Class II products internally.

For most software manufacturers, Option A is more practical unless you have a large product portfolio that makes Option B economically efficient.


Why June 11 Matters Even If You're Class I

The June 11, 2026 deadline is specifically about Notified Body designation—Member States must designate which conformity assessment bodies are authorized to conduct CRA assessments. Until those bodies are designated, no CRA-specific conformity assessments can be officially conducted, even by bodies that do similar work under other regimes (like NIS2 or the EU Cybersecurity Act).

This matters for Class I developers because:

  1. You may want a voluntary third-party assessment even if it's not required. Many enterprise customers are already requiring CRA conformity evidence in procurement contracts. A Notified Body certificate carries more weight than a self-declaration in competitive procurement.

  2. Your product classification may change. The Commission can expand the Class II and Critical Product lists through delegated acts. If your product gets re-classified after June 11, the Notified Body ecosystem needs to exist for you to comply.

  3. Supply chain pressure. If you supply software to Class II or Critical Product manufacturers, they may require assurance that your components meet CRA requirements. A self-declaration may not satisfy their supply chain verification requirements.


What Developers Should Do Right Now

Step 1: Determine Your Product Classification (30 minutes)

Work through this classification checklist:

Does your product appear in CRA Annex III?

Is your product "free and open source software distributed as-is without commercial support"?

Does your product process authentication credentials or access control for third parties?

Step 2: Prepare Your Technical File (Before September 2026)

Whether Class I or II, the Technical File is your most critical deliverable. Start building it now:

Required Technical File Components:

ComponentWhat It Covers
Product DescriptionIntended purpose, foreseeable uses, software architecture overview
Security Risk AssessmentThreats, mitigations, residual risks under CRA Annex I Part II
Secure Development LifecycleSDL practices, code review, dependency management
SBOMComplete software bill of materials, updated with each release
Vulnerability Handling PolicyCVD process, 24h/72h ENISA reporting workflow
Test and Validation EvidenceSecurity testing results, penetration test findings
Known VulnerabilitiesDocumented known vulnerabilities and remediation status

Most SaaS development teams already have partial versions of most of these documents. The CRA requires you to formalize and maintain them.

Step 3: Issue Your EU Declaration of Conformity

Once your Technical File is complete and your product meets Annex I essential requirements, issue your EU Declaration of Conformity. The DoC must include:

The DoC is a formal legal document. Keep a copy for at least 10 years after the product is placed on the market.

Step 4: If You're Class II — Contact Notified Bodies Now

Notified Body designation is happening in the June 2026 window. After designation, these bodies will begin CRA assessment work. The problem: every Class II manufacturer in the EU is in the same queue.

If your product is Class II:

  1. Identify candidate Notified Bodies from the NANDO database (EU Commission's database of notified bodies) — look for bodies with cybersecurity or IT product experience under existing regimes
  2. Contact them before June 11 to understand their CRA readiness timeline
  3. Request preliminary discussions about your product scope and assessment timeline
  4. Budget 3-6 months for assessment from first engagement to certificate issuance

If no Notified Body has been designated in your Member State by June 11, contact the national market surveillance authority for interim guidance. The Commission has acknowledged this transitional gap.


The Intersection With ENISA's September 2026 Deadline

The CRA's first hard enforcement deadline is September 11, 2026: mandatory 24-hour vulnerability reporting and SBOM requirements kick in. This deadline does not depend on Notified Body designation—it's a direct obligation on manufacturers.

The conformity assessment (including Notified Body involvement for Class II) deadline aligns with the full enforcement date: September 11, 2028 (36 months after CRA entry into force on December 11, 2024). Class II manufacturers have until then to complete formal conformity assessment.

But "until 2028" is not the same as "start in 2027." Notified Body queues, Technical File preparation time, and the internal compliance work required mean that starting in late 2026 creates serious risk.


How EU Hosting Intersects With CRA Conformity

If your product is subject to CRA conformity assessment—particularly Class II—your infrastructure choices become part of your Technical File. Assessors will look at:

A SaaS product running on EU-sovereign infrastructure (no US-parent cloud provider) eliminates a significant class of third-party data access risk from your technical documentation. This simplifies the risk assessment section of your Technical File and removes the need to document US legal jurisdiction exposure as a residual risk.

sota.io runs on European infrastructure, fully under EU jurisdiction. If your conformity assessment requires clean infrastructure provenance, that's a differentiating factor worth documenting.


Key Dates Summary

DateEvent
June 11, 2026Member States must designate CRA Notified Bodies
September 11, 202624h vulnerability reporting + SBOM requirements mandatory
December 11, 2027Class I products must complete conformity assessment
December 11, 2028Class II products must complete Notified Body assessment

Checklist: CRA Conformity Assessment Readiness

Immediate (before June 11, 2026):

Short-term (before September 11, 2026):

Medium-term (before December 11, 2027):


The June 11 Notified Body designation deadline is a regulatory infrastructure event that many developers are not tracking. If your product is Class II, you cannot complete your conformity journey without a designated Notified Body—and after June 11, the queue starts forming.

For Class I developers, the work is yours to do internally. The Technical File, Declaration of Conformity, and CE marking are achievable without third-party involvement, but they require documentation discipline that takes months to build correctly.

Start the classification conversation now.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.