CRA Notified Bodies Are Coming: What TIC Organizations Need to Prepare Now

Overview

The EU Cyber Resilience Act — Regulation (EU) 2024/2847 — entered into force on 10 December 2024. Most commentary since has been written for manufacturers of products with digital elements: what the essential cybersecurity requirements demand, when reporting starts, which products fall into which class.

There is a second audience, and it has had far less written for it. The CRA creates an entire notified body ecosystem from scratch, in a domain where none previously existed. Chapter IV of the CRA — the framework governing notified bodies — has applied since 11 June 2026. Full application of the Regulation follows on 11 December 2027.

For Testing, Inspection and Certification organisations, that gap is the opportunity. It is also closing.

The timeline, precisely

Four dates govern the CRA, and they are frequently conflated:

Article 35(2) sets an intermediate marker: Member States are to strive to ensure a sufficient number of notified bodies in the Union by 11 December 2026, specifically to avoid bottlenecks and hindrances to market entry.

Two clarifications, because both are commonly misreported. The September 2026 date is the Article 14 reporting regime — the 24-hour early warning, 72-hour notification and 14-day final report cycle for actively exploited vulnerabilities and severe incidents. It is not the date of full application. And full application is 11 December 2027, not September 2027.

The designation gap

Chapter IV has been in force since June 2026. As of late June 2026, the Commission's NANDO database contained no CRA notified body designations at all.

That is not surprising — the machinery has to run in sequence. Under Article 36, each Member State must first designate a notifying authority responsible for assessing, designating and notifying conformity assessment bodies. Only then can a conformity assessment body apply. Under Article 43, the notifying authority assesses the applicant and notifies the Commission, which lists it in NANDO. Each stage takes months.

The arithmetic is uncomfortable. Between the first designations and 11 December 2027, every manufacturer of an Annex III Class II or Annex IV product requiring third-party assessment must complete conformity assessment. Demand will not arrive evenly; it will concentrate in the final year. Anyone who has watched MDR certification queues form knows how this ends.

For a TIC organisation, the read is straightforward: designation capacity built in 2026 is worth considerably more than designation capacity built in 2027.

Which products actually need a notified body

The CRA's conformity assessment routes are tiered, and the tiering determines the size of the addressable market.

Default category. The majority of products with digital elements. Self-assessment under Module A (internal control).

Annex III, Class I — "important" products, lower risk. Password managers, network management systems, VPNs and similar. These retain the self-assessment route provided harmonised standards, common specifications, or a European cybersecurity certification scheme cover all applicable essential requirements. Where that coverage is incomplete, third-party assessment is required.

Annex III, Class II — "important" products, higher risk. Operating systems, firewalls, microprocessors and similar. Third-party assessment is mandatory. The manufacturer chooses between:

• EU-type examination (Module B) followed by conformity to type based on internal production control (Module C); or
• conformity assessment based on full quality assurance (Module H).

Annex IV — "critical" products. Smart meter gateways, smart cards, secure elements and similar. A notified body is mandatory in every case.

Where more than one category could apply, the stricter classification governs.

The Class I conditionality deserves attention when sizing the opportunity. It is a floating boundary: as harmonised standards under the CRA are published, products migrate from third-party assessment into the self-assessment route. Conversely, gaps in the standards landscape at any given moment push Class I products toward notified bodies. Demand forecasting for CRA assessment work has to track standardisation progress, not just product classification.

Why this is a genuine vertical, not an adjacent one

It would be easy to treat CRA designation as an extension of existing product certification work. It is not, for three reasons.

The competence profile is different. MDR and IVDR assessment competence is built around clinical evidence, risk management, biocompatibility and quality systems. CRA assessment requires vulnerability handling, secure development lifecycle, SBOM practice, cryptographic implementation and coordinated vulnerability disclosure. There is real overlap in the quality management and technical documentation disciplines, and almost none in the substantive technical domain.

The evidence is different in kind. A medical device technical file is largely static at the point of assessment: it describes a design that has been frozen. A CRA technical file describes a product whose security posture is explicitly dynamic. Article 14's reporting obligations, the support period obligations, and the vulnerability handling requirements all concern what the manufacturer will do after placing the product on the market. Assessing a commitment to future process is a different exercise from assessing completed design evidence.

The manufacturer population is different. Software and hardware vendors entering CRA scope have, in many cases, never dealt with a notified body, a CE marking process, or a technical documentation requirement. TIC organisations moving into this space should expect a much higher rate of incomplete and misstructured first submissions than they see in mature regulated verticals — with the corresponding effect on assessment throughput.

That last point is the one to plan capacity around. The MDR experience is instructive: application incompleteness, not assessment complexity, is the dominant driver of elapsed certification time. A vertical where most applicants are first-time entrants will be worse.

What to do in the window

1. Engage your notifying authority now. Article 36 designation of notifying authorities is a Member State obligation, and the maturity of that process varies considerably across Member States. Establishing the relationship, understanding the national assessment procedure, and scoping your intended designation before the application queue forms is the single highest-leverage action available.

2. Map competence honestly. The accreditation assessment will test technical competence against the CRA's essential requirements in Annex I, not against generic cybersecurity credentials. Identify where you need to hire versus where you can develop, and note that the assessor market is competitive and will get more so.

3. Design the assessment workflow before designation, not after. This is the mistake most frequently made when entering a new scheme. Organisations achieve designation and then discover their process infrastructure was built around the evidentiary shape of a different regulation. CRA files will have SBOMs, vulnerability disclosure policies, support period declarations and secure development lifecycle evidence. If your review tooling models a technical file as a fixed document set mapped to a fixed requirements list, it will fit CRA evidence poorly.

4. Plan for evidence that changes during assessment. A CRA technical file may legitimately change mid-assessment because a vulnerability was disclosed and handled. Your process needs a defined position on how that is treated — reassessment scope, versioning of the assessed evidence, and traceability of which version of which artefact supported which finding. Getting this wrong is a designation-audit finding waiting to happen.

5. Build the traceability discipline in from the start. In a new scheme with no established assessment precedent, the defensibility of your decisions rests entirely on the quality of your record: which requirement, which evidence, which reviewer, which reasoning. Schemes accumulate precedent over time; the CRA has none yet. Early assessments will be scrutinised.

The AI question, stated carefully

There is an obvious argument that AI-assisted review is well suited to CRA files: they are software-heavy, they contain highly structured artefacts like SBOMs, and the applicant population will generate a high volume of incomplete submissions that need systematic gap identification.

The argument is sound as far as it goes, and it stops well short of automated conformity decisions. A new scheme with no precedent is precisely the environment where a conformity decision must rest on documented human reasoning. What AI-assisted review can legitimately do is ensure the reviewer starts from a complete map of the file: every essential requirement in Annex I located against the evidence that purports to satisfy it, every gap identified in one pass rather than serially, every claim traceable to its source artefact.

That is the same position we hold for MDR and IVDR work, and it is consistent with the TIC Council's February 2026 framework on digitalisation of assurance services, which explicitly rejects full automation of conformity decisions while endorsing digital methods supported by validated methodologies and auditable records.

For the general case, see human-in-the-loop AI for technical assessment and how AI is transforming conformity assessment.

The short version

The CRA notified body ecosystem is being built now, from nothing, against a hard deadline of 11 December 2027. There were no designations in NANDO as of June 2026. The organisations that secure designation in 2026 will meet a demand curve that steepens sharply through 2027, in a vertical whose competence profile, evidence types and applicant maturity differ materially from established TIC verticals.

The preparation that matters is not the designation application itself. It is the assessment infrastructure that has to be in place the day designation is granted.

Conformo builds AI-assisted review infrastructure for Notified Bodies, Certification Bodies and TIC organisations. Every finding is traceable to its source, and every conformity decision remains with a qualified reviewer.