CRA Notified Bodies 2026: The Developer's Complete Guide to Third-Party Conformity Assessment

Post #1167 in the sota.io EU Cyber Compliance Series

The EU Cyber Resilience Act (Regulation 2024/2847) marks the most significant change to software product liability in European history. Full application arrives 11 September 2027 — but a critical intermediate milestone lands on 11 June 2026: the date by which EU Member States must have designated and notified their CRA Notified Bodies to the European Commission.

After 11 June 2026, manufacturers of Class I and Class II products with digital elements will know exactly which third-party assessors they must engage. If you haven't determined your product's classification, reviewed your conformity assessment path, and started documentation, you're already behind.

This guide covers everything developers need to know: what notified bodies are, which products require third-party assessment, how to find an accredited body, what they actually check, and why EU-native hosting reduces your compliance surface area.

What Is a CRA Notified Body?

A Notified Body under the CRA is a conformity assessment organisation that has been:

1. Accredited by a national accreditation body (e.g., DAkkS in Germany, COFRAC in France, UKAS in the UK) against ISO 17065 (product certification) or ISO 17020 (inspection)
2. Designated by its Member State authority as competent to perform CRA assessments
3. Notified to the European Commission and published in the NANDO database (New Approach Notified and Designated Organisations)

Until 11 June 2026, this infrastructure is being built. After that date, NANDO will list which bodies are authorised for which product categories. This is the date you should care about as a developer — it's when you can actually engage a body and begin the assessment clock.

The Commission monitors notified bodies centrally. If a body is found non-compliant, it loses its notification and its certificates become invalid. This is why NANDO-listed bodies carry far more legal weight than self-declared "CRA-ready" assessors.

The CRA Product Classification Recap

Your conformity assessment path is entirely determined by your product classification. The CRA divides products with digital elements into three tiers:

The practical implication: if your SaaS runs on or integrates with Class I or Class II components — or if you ship software that is a Class I product — you need to understand notified body procedures now.

Detailed classification analysis is in our earlier post: CRA Product Classification: Class I, Class II, and Annex IV Explained.

Why 11 June 2026 Matters

The CRA entered into force on 11 December 2024. Article 71 establishes a layered application timeline:

The 11 June 2026 milestone is specifically about the infrastructure readiness deadline: Member States that have not notified their bodies by this date cannot certify products during the remaining transition window. Bodies must be listed in NANDO before they can issue valid assessments.

For manufacturers of Class II products, this date starts the countdown: you need to engage a notified body, submit your technical documentation, pass the assessment, and affix the CE mark — all before 11 December 2027. With assessment timelines of 3–12 months for complex products, engagement should begin immediately after 11 June 2026.

What Notified Bodies Actually Assess

When you engage a CRA Notified Body, they will conduct one or more of the following assessment modules (defined in Annex VIII):

Module B — EU-Type Examination

The notified body examines your product's design and construction to verify compliance with CRA essential requirements (Annex I). They check:

• Vulnerability handling processes (Art. 13)
• Security documentation completeness (Art. 27 — SBOM, security advisories)
• Incident reporting capability (Art. 14)
• Software bill of materials integrity
• Access control and privilege minimisation mechanisms
• Encryption implementation and key management

Output: EU-type examination certificate — the basis for ongoing production conformity (Module C2 or D).

Module C2 — Conformity to Type Based on Internal Production Control + Supervised Product Checks

After Module B, the notified body monitors your ongoing production process through surprise product samples or annual audits. This is the most common path for software products.

Module D — Quality Assurance of Production Process

The notified body audits your entire development and production quality system (typically ISO 9001 or IEC 62443-4-1 aligned). Higher overhead but less per-product friction once established.

Module H — Full Quality Assurance

The notified body takes over the entire conformity assessment function against your quality management system. Highest upfront investment, but appropriate for manufacturers placing many products on the market.

Most SME software manufacturers will use Module B + C2: one-time type examination followed by periodic spot checks.

What Documentation You Must Provide

Before engaging a notified body, your technical documentation must be complete. Article 27 and Annex VII define the mandatory content:

Product documentation (must exist before assessment):

• General description of the product and its intended purpose
• Design and manufacturing drawings, schematics, system architecture
• Full Software Bill of Materials (SBOM) in machine-readable format (SPDX or CycloneDX)
• Risk assessment and threat model (aligned with Annex I, Part I, § 1)
• Vulnerability disclosure policy (URL must be live)
• Security testing results and penetration test reports
• Description of secure development lifecycle (SDL/SSDLC)
• List of applied harmonised standards (EN 18045 or equivalent)
• Declaration of conformity draft

Ongoing obligations (must be operational before CE marking):

• PSIRT (Product Security Incident Response Team) with documented escalation path
• ENISA reporting integration for actively exploited vulnerabilities (active after 11 September 2026)
• End-of-life policy stating minimum security support period

The documentation burden is substantial. Teams that start after June 2026 will struggle to meet the December 2027 deadline for complex products.

Finding a CRA Notified Body

After 11 June 2026, use the NANDO database (ec.europa.eu/growth/tools-databases/nando/) to find bodies designated for CRA. Filter by:

• Regulation: Cyber Resilience Act
• Country of accreditation (Germany, Netherlands, France, etc.)
• Product category matching your Annex III or Annex IV scope

Pre-designation, several existing bodies under the Radio Equipment Directive (RED), ATEX, and machinery legislation have announced CRA readiness programs. Expected first movers:

None of these have issued CRA certificates yet — the standard doesn't allow it until the regulation's assessment modules officially apply. But relationships established now mean priority access to assessment slots after June 2026.

The CLOUD Act Problem for Notified Body Assessment

Here is what most CRA guides skip: your hosting jurisdiction directly impacts your notified body assessment scope.

A CRA notified body assessing a product's conformity will examine your entire data processing chain. If your product:

• Stores logs or vulnerability data on US-jurisdiction servers (AWS, Azure, GCP us-east, etc.)
• Uses a SaaS CI/CD tool governed by a US parent company (GitHub Actions, CircleCI)
• Runs security monitoring via a CLOUD Act-exposed vendor (Datadog, Splunk, Crowdstrike)

...then the notified body must document each transfer, verify adequacy mechanisms, and assess whether CLOUD Act requests to your US-parent vendors could compromise the product's security posture — because a forced disclosure of your vulnerability data to a foreign intelligence service is itself a security event under CRA Article 14.

This is not hypothetical. The CRA's essential requirements (Annex I, Part I, §2(5)) require manufacturers to "protect the confidentiality of stored, transmitted or otherwise processed data." A confidential vulnerability report exfiltrated under a CLOUD Act order violates this requirement.

EU-native infrastructure eliminates this assessment complication entirely:

The practical implication: developers who migrate to EU-native infrastructure before engaging a notified body will have a significantly simpler, faster, and cheaper assessment.

Class I Self-Assessment vs. Notified Body: The Decision

For Class I products, the CRA gives manufacturers a choice. Here is the decision framework:

Choose self-assessment (Module A) when:

• You have a mature SSDLC with documented evidence
• You have in-house security expertise to produce compliant technical documentation
• Your product category is unambiguous (clearly Class I, not borderline Class II)
• You can maintain the Declaration of Conformity and update it for each product change

Choose notified body (Module B+C2) when:

• Your product is borderline between Class I and Class II
• You're selling into regulated sectors (healthcare, finance, critical infrastructure) where customers demand third-party certification
• You want the competitive signal of an EU-type examination certificate
• Your SSDLC documentation is incomplete and you want structured external guidance

The notified body route costs €15,000–€80,000 for a full Module B examination depending on product complexity. Self-assessment costs are internal (documentation effort, auditor time) — typically €10,000–€40,000 in engineering time if starting from zero.

Practical Timeline for Class II Manufacturers

If you ship a Class II product (or are uncertain), here is the minimum viable timeline:

Now – June 2026        Build SBOM tooling. Document SSDLC. 
                        Conduct threat model. Prepare technical file.
                        Establish vulnerability disclosure policy.

June 2026              NANDO publishes CRA-designated bodies.
                        Identify and contact 2-3 bodies. Request quotes.

July – September 2026  Submit technical documentation to chosen body.
                        Begin Module B type examination.
                        ENISA vulnerability reporting goes live (Art.14).

October – March 2027   Assessment in progress. Address findings.
                        Module C2 production monitoring agreement.

April – August 2027    Receive EU-type examination certificate.
                        Affix CE marking.
                        Prepare Declaration of Conformity.

11 September 2027      Full CRA application. Products without CE 
                        marking cannot be placed on EU market.

Missing the June 2026 start is survivable — you can compress the timeline. Missing September 2026 means you are overlapping assessment with live vulnerability reporting obligations. Missing the 2027 deadline means your product cannot legally be sold in the EU.

ENISA and Standards: What to Watch

The CRA requires the Commission to request harmonised standards from ETSI and CEN/CENELEC. Relevant work in progress:

Using harmonised EN standards creates a presumption of conformity — your notified body assessment is faster and cheaper if your processes already align with these standards. Diverging from harmonised standards doesn't prevent conformity but requires additional justification.

Action Checklist

Immediate (before June 2026):

• Classify your product: Default / Class I / Class II using our classification guide
• Identify all open source components; start SBOM tooling (CycloneDX + cdxgen or SPDX + syft)
• Establish or document your vulnerability disclosure policy (must be a live URL)
• Inventory your supply chain for CLOUD Act-exposed services — plan EU-native migration

June 2026:

• Search NANDO for CRA-designated bodies in your product category
• Request assessment quotes from 2–3 bodies
• For Class I: finalize self-assessment decision

September 2026 onwards:

• Submit technical documentation package to chosen body
• Configure ENISA reporting pipeline (active obligation from 11 Sept 2026)
• Begin audit trail for all security-relevant code changes

Key Takeaway for Developers

The CRA Notified Body ecosystem launches on 11 June 2026 — 22 days from now. This is not a compliance deadline by itself, but it opens the door to formal certification. For Class II products, that door must be entered and exited before September 2027.

EU-native infrastructure is not just a data sovereignty choice; it's a conformity assessment simplifier. When your product's entire processing chain operates under EU jurisdiction — no US parent, no CLOUD Act exposure — the notified body's assessment scope shrinks, your documentation burden decreases, and your certification timeline shortens.

Deploy on Hetzner, Scaleway, or OVHcloud. Use EU-native PaaS platforms that don't introduce US-parent jurisdiction risk into your stack. Treat hosting jurisdiction as a compliance input, not a cost input.

CRA Notified Bodies guide | Regulation 2024/2847 | 11 June 2026 milestone | 11 September 2027 full application | NANDO database | Module B EU-type examination | sota.io EU compliance series