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 Class | Conformity Route | Example Products |
|---|---|---|
| Class I (Default) | Self-assessment (Module A or Module H) | Most commercial software, SaaS, APIs |
| Class II | Third-party Notified Body OR internal audited assessment | Hypervisors, identity management software, password managers |
| Critical Products (Category 1) | Third-party Notified Body mandatory | OS kernels, hardware security modules, smartcard OS |
| Critical Products (Category 2) | European cybersecurity certification mandatory | Specific 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:
-
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.
-
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.
-
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:
- Hypervisors and container runtime environments (if used in critical infrastructure contexts)
- Firewalls, intrusion detection and prevention systems
- Tamper-resistant microprocessors
- Identity management systems and privileged access management software
- Password managers
- Secure elements
- Network interfaces specifically designed for critical infrastructure
- Smart meters
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:
-
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.
-
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.
-
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?
- Check the Annex III list against your product's primary function
- If yes: proceed to Class II or Critical Product assessment
- If no: you are Class I (default)
Is your product "free and open source software distributed as-is without commercial support"?
- If yes: you may be partially or fully out of scope
- If no: you are in scope as a manufacturer
Does your product process authentication credentials or access control for third parties?
- Password managers, identity providers, SSO systems: likely Class II
- API keys your own service issues to your own customers: likely Class I
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:
| Component | What It Covers |
|---|---|
| Product Description | Intended purpose, foreseeable uses, software architecture overview |
| Security Risk Assessment | Threats, mitigations, residual risks under CRA Annex I Part II |
| Secure Development Lifecycle | SDL practices, code review, dependency management |
| SBOM | Complete software bill of materials, updated with each release |
| Vulnerability Handling Policy | CVD process, 24h/72h ENISA reporting workflow |
| Test and Validation Evidence | Security testing results, penetration test findings |
| Known Vulnerabilities | Documented 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:
- Name and address of the manufacturer
- Product name and version(s) covered
- Statement that the product meets the CRA's essential requirements (reference specific articles)
- Conformity assessment module used (Module A for most Class I)
- Place and date of issue
- Authorized signatory name and signature
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:
- 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
- Contact them before June 11 to understand their CRA readiness timeline
- Request preliminary discussions about your product scope and assessment timeline
- 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:
- Where data is processed and stored
- Whether your infrastructure provider has documented security practices (relevant for your risk assessment)
- CLOUD Act exposure if US-parent providers are involved
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
| Date | Event |
|---|---|
| June 11, 2026 | Member States must designate CRA Notified Bodies |
| September 11, 2026 | 24h vulnerability reporting + SBOM requirements mandatory |
| December 11, 2027 | Class I products must complete conformity assessment |
| December 11, 2028 | Class II products must complete Notified Body assessment |
Checklist: CRA Conformity Assessment Readiness
Immediate (before June 11, 2026):
- Determine product classification (Class I vs. Class II vs. Critical)
- Review Annex III for specific product mentions
- Identify applicable conformity route (Module A vs. Notified Body)
- If Class II: contact Notified Bodies to understand timeline
Short-term (before September 11, 2026):
- Start building Technical File documentation
- Implement or formalize SBOM generation
- Establish ENISA vulnerability reporting workflow
- Draft EU Declaration of Conformity template
Medium-term (before December 11, 2027):
- Complete Technical File for all in-scope products
- Issue EU Declaration of Conformity
- Implement CE marking on product documentation
- If Class II: complete Notified Body assessment
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.