Do You Need a Notified Body Under the CRA?

Only if your product's core functionality matches an important or critical product category, and then, for class I, only if you cannot apply a harmonised standard that covers the cybersecurity risks of that core functionality. Everything else self-assesses under the internal control procedure the Cyber Resilience Act calls module A. That is the rule, and the Commission's guidance on applying the CRA, published in July 2026 as the annex to C(2026) 5252, turns both halves of it into tests with worked examples. The contrarian part is that the deciding question is not "is our product on the Annex III list." It is "what is our product's core functionality," and the guidance says a product has exactly one, decided by its main features and technical capabilities rather than by how it is marketed. Products that can do what a listed category does but whose core functionality substantially exceeds or falls short of it are not that category. The second surprise is that applying a harmonised standard is not a checkbox: the standard has to cover at least all the risks of the core functionality, and the presumption of conformity you get from it stops at the edge of the standard's scope.

Which categories exist, and the four tiers they produce, is covered in our article on Annex III classes and conformity routes; this one does not repeat those lists. What follows is how the class is actually decided, what each procedure asks of you, the standards-coverage test, what a notified body is and who says so, how certificates you already hold count, and when a later change sends you back.

Key takeaways

• The class is decided by core functionality, and a product has only one. Ancillary functions do not change it, integrating a listed component does not change it, and misrepresenting it to escape a stricter regime is a breach the guidance names.
• Default products always self-assess under module A. Class II and critical products always take a third-party route. Class I takes a third-party route only where a harmonised standard, common specification or certification scheme has not been applied, or has been applied only in part.
• The standard must cover at least all cybersecurity risks of the core functionality, applied in full. Risks from additional functions still have to be treated and documented, and get no presumption of conformity.
• A notified body is a conformity assessment body assessed, designated, notified and monitored by the member state where it sits, and listed on the Commission's NANDO database. Chapter IV, which makes that possible, applies from 11 June 2026.
• Existing EU type-examination certificates under other Union legislation stay valid for the risks they cover until 11 June 2028, and a substantial modification sends only the modified parts back for assessment.

Start with core functionality, not the product name

The guidance is not law. Its own paragraph 8 says it "is not binding for economic operators" and that an authoritative interpretation "may only be given by the Court of Justice of the European Union." It is, however, the Commission's stated interpretation, written under Article 26(1) of the Regulation, which requires the Commission to publish guidance with "a particular focus on facilitating compliance by microenterprises and small and medium-sized enterprises," and it is written for notified bodies and market surveillance authorities as much as for manufacturers. Section 6 is the part that answers this article's question.

Paragraph 139 defines core functionality as "that product's main features and technical capabilities, without which it would not be able to meet its intended purpose," assessed "in light of that product's specific context and conditions of use" and drawing on the instructions for use, promotional material and technical documentation. Five rules follow from it in paragraphs 140 to 145, and they change classification decisions in both directions:

• Additional functions do not reclassify. A product "rarely" does only its core function, and performing functions beyond a listed category's description "does not in itself prevent the product from having one such core functionality."
• Integrating a listed component does not reclassify. Paragraph 141 restates Article 7(1): "the mere integration of an important or critical product with digital elements does not in itself render the product" important or critical. The guidance's example is a smartphone, which integrates an operating system but whose core functionality is communication and access to services, not that of an operating system.
• Substantially exceeding or falling short takes you out. Paragraph 142's examples are the ones security vendors should read. Security orchestration, automation and response software "often has the ability to perform the functions" of a SIEM, but its core functionality "substantially exceeds that of a SIEM," so it "is generally not considered to have the core functionality of SIEM systems." Log collection and dashboard tools that do not correlate data or produce actionable security insights fall short of a SIEM and are "generally not to be considered" one either.
• You may not game it. Paragraph 143: a manufacturer "may not misrepresent the core functionality" of its product "in such a way as to escape the conformity assessment regime applicable to important or critical products with digital elements," and "clear inconsistencies between promotional materials, instructions for use, and technical documentation" are the tell.
• One core functionality per product, written down. Paragraph 144 says a product "may not have more than one core functionality" for this purpose, and that because Annex VII of the Regulation requires the technical documentation to describe the intended purpose and the conformity assessment procedure followed, "the product's core functionality should therefore be clearly identified."

The rule that surprises software companies is paragraph 145 on modules. A product sold as one suite but composed of distinct modules that are also "offered for separate purchase, licensing or subscription" is several products, each classified on its own core functionality. The guidance's example 61 is a security suite whose separately subscribed SIEM module is class I, whose intrusion detection module is class II, and whose analytics module is default. If your pricing page sells the components separately, the CRA classifies them separately. The technical descriptions of each category sit in Commission Implementing Regulation (EU) 2025/2392, which the guidance cites as the reference for what "operating system," "router" or "SIEM" means for this purpose.

Paragraph 146 adds the consequence: non-compliance with Article 32 can trigger administrative fines under Article 64(3).

The three routes, and what each asks of you

Once the core functionality is fixed, the route follows. The Commission's summary of the legislative text calls the self-assessment route "the internal control procedure (based on module A)," and the guidance's paragraph 148 describes the alternatives as "a more stringent conformity assessment procedure, with the involvement of a thirdparty (based on module B+C, module H or cybersecurity certification schemes)."

Module A means the manufacturer performs the assessment against the Annex I essential requirements, assembles the technical documentation, and signs the declaration; nobody outside checks it before the product ships, and a market surveillance authority can check it afterwards. Module B+C is an EU-type examination of the product design by a notified body followed by the manufacturer's own production control against the examined type. Module H is full quality assurance, in which the notified body approves and then surveils the manufacturer's quality system for design, production and testing rather than examining each type. The certification route uses a scheme adopted under Regulation (EU) 2019/881; the guidance's footnote 24 notes that at assurance level substantial "the involvement of a third-party certification body is required," so it is a third-party route by another door, and the Commission's conformity assessment page says products certified under such a scheme "might not need the participation of a notified body," on conditions the Commission has still to specify.

Footnote 23 of the guidance records the one direction in which you always have freedom: "the manufacturer can nonetheless always choose to apply a more stringent conformity assessment procedure." Some buyers will ask for a notified body certificate on a default product. That is a commercial decision, not a legal one, and it is available.

The standards test is about coverage, not about having a standard

This is the part of the decision most summaries get wrong, and the guidance is unusually precise about it.

Paragraph 149 sets two conditions for a class I product to use module A: "(i) all the applicable requirements of a relevant harmonised standard need to be applied; and (ii) the standard's scope needs to cover at least all the cybersecurity risks associated to that product's core functionality." Paragraph 150 then reminds you that the Article 13(2) risk assessment is always required, that the product may be broader than the standard, and that "where implementing the standard does not cover all risks, the manufacturer should ensure via other means that its product with digital elements is in compliance with the essential requirements." Example 62 is an antivirus product that also cleans disks and blocks trackers: the manufacturer applies the harmonised standard to the antivirus core, treats the other risks with additional measures, documents both, and may use internal control for the whole product. Example 63 is a router with an integrated firewall: the router standard covers the core, the firewall standard or other measures cover the firewall, and module A is available.

Then paragraphs 153 to 155 separate two things that get conflated. Applying a covering standard unlocks the procedure. It does not extend the presumption of conformity beyond the standard's scope. Example 64: the antivirus manufacturer "will benefit from presumption of conformity for the risks associated with that product's core functionality, but not for the risks associated with additional functionalities." Example 65: when the standard is updated to cover disk cleaning but not anti-tracking, the presumption grows to match, and no further. The footnote quoting the Blue Guide is the principle underneath: manufacturers "always, even when using harmonised standards ... remain fully responsible for assessing all the risks of their product."

Two facts about the standards themselves, both from the Commission's CRA standardisation page. The standardisation request M/606 covers "a set of 41 standards in support of the CRA," split between horizontal standards, including vulnerability handling, and vertical product standards that "provide presumption of conformity for product types," with the Annex III and Annex IV categories prioritised. And the test in paragraph 148 is written against harmonised standards "the references of which have been published in the Official Journal of the European Union," so a draft standard, however finished, does not open module A for a class I product. Whether a cited standard exists for your category on the day you assess is the single fact to check, and the guidance's own phrasing about routers, "it is expected that the harmonised standard for routers will address" the core risks, is in the future tense.

What a notified body is, and who says so

The Commission's summary defines a notified body as "a conformity assessment body designated in accordance with Article 43 and other relevant Union harmonisation legislation." That is the legal definition; the conformity assessment page gives the practical one. Conformity assessment bodies "have to be assessed, designated, notified and monitored by the Member State where they are established," and once a body is notified "it will be published on the NANDO website of the European Commission." Nobody self-declares as a CRA notified body; if a firm is not on NANDO for the CRA, its certificate is a consultancy report.

The machinery that makes designation possible is Chapter IV of the Regulation, which applies from 11 June 2026, eighteen months before the main obligations apply from 11 December 2027. That gap exists so that bodies can be accredited, designated and listed before manufacturers need them, and the Commission's CRA page is careful in how it frames the need: "some products of particular relevance for cybersecurity may need to undergo a third-party assessment by a notified body before they are sold on the EU market." Some, not most. The same page records that the Regulation entered into force on 10 December 2024 and that the Article 14 reporting obligations apply from 11 September 2026, ahead of everything discussed here; if you have not built that capability yet, the reporting obligations are the earlier deadline.

One thing the guidance says about itself matters here. Paragraph 6 states it is intended "to support the activities of market surveillance authorities, notifying authorities and notified bodies, with a view to ensuring the harmonised enforcement of the CRA across the Union." A notified body assessing a class I product will apply the same core functionality and coverage tests you read above. Writing your classification memo in the guidance's vocabulary is not pedantry; it is the document the assessor will be looking for.

Certificates you already hold, and the 11 June 2028 line

If your product is radio equipment or machinery, you may already hold an EU type-examination certificate that covers cybersecurity requirements under that legislation. Article 69(1), quoted in the guidance's paragraph 247, keeps such certificates and approval decisions valid for CRA purposes until 11 June 2028, unless they expire earlier or the other legislation says otherwise. Paragraph 248 limits the relief to "the cybersecurity risks and corresponding requirements that are covered by the respective Union harmonisation legislation on the basis of which they were issued," and paragraph 249 is explicit that a valid certificate "does not exempt manufacturers from carrying out a comprehensive cybersecurity risk assessment under the CRA"; it lets them rely on the certificate "as evidence of compliance for their conformity assessment procedure, to the extent that the corresponding cybersecurity risks are already covered."

The worked example is the Radio Equipment Directive delegated act. A certificate issued against its cybersecurity requirements covers risks such as network protection, personal data and fraud prevention; the guidance's paragraph 253 lists what it typically does not cover, "risks related to vulnerability handling processes, data minimisation, and reduction of the attack surface," which are precisely the CRA's Annex I additions. So an existing certificate shortens the assessment. It does not replace the vulnerability-handling program, the software bill of materials, or the risk assessment, and the reliance ends on 11 June 2028 even where the certificate itself runs longer.

Re-assessment after a change

Paragraph 123 of the guidance covers what happens when a substantially modified product goes back through assessment. The original manufacturer "may reuse existing documentation and tests for aspects of the product with digital elements that are not impacted by the substantial modification," the procedure "should focus on the substantially modified parts," and "where a third-party conformity assessment is performed, the conformity assessment body should focus its assessment on the substantially modified parts." A notified body engagement is therefore not a fixed cost per release; it scales with what changed, provided your technical file is structured so that unchanged parts can be shown to be unchanged. What counts as a substantial modification, and how the transitional rules treat products already on the market, is in our scoping article rather than here.

When you do not need a notified body, said plainly

Four cases, each of them common.

Your product's core functionality is not in an important or critical category, however many security features it has. Module A applies, and buying a notified body assessment is optional.

Your product is class I and a harmonised standard whose reference is in the Official Journal covers the risks of its core functionality, and you apply all of it. Module A applies, with additional measures documented for any risks outside the standard.

Your product is class I or class II free and open-source software and you make the technical documentation public. Article 32(5), restated in paragraph 137 of the guidance, lets you follow the default-category procedures.

Your product is not placed on the EU market at all. That question comes before every one above, and whether the CRA applies to your product is where to start if you are unsure.

Where Top Floor fits

We write the classification memo in the guidance's terms: the core functionality determination with the paragraph 139 evidence attached, the module analysis if you sell components separately, the standards-coverage test against what is actually cited, and the reasoning for any product near a boundary. Then we build the technical file and the Annex I evidence that every route needs, which is the work our EU Cyber Resilience Act practice exists for, with penetration testing supplying the security testing the vulnerability-handling requirements ask for.

We are not a notified body, we are not on NANDO, and we do not issue EU-type examination certificates or CE marks. For class I products heading to a third-party route and class II products that have no choice, the useful thing we do is get the file into the shape an assessor reads quickly, and then step back. Where the CRA sits alongside other product or sector regimes, that is international compliance scope and should be planned as one program.

How to decide this week

Write one sentence per product naming its core functionality, using the Implementing Regulation's category descriptions where one fits and stating plainly where none does. Check that the sentence is consistent with your sales page and your instructions for use; if it is not, paragraph 143 is your problem before conformity is.

For every product whose core functionality is class I, find out whether a harmonised standard covering it has been cited in the Official Journal. If yes, map your risk assessment to the standard's scope and list the risks that fall outside it. If no, put a notified body engagement in the plan and start the technical file now, because the file is the same in either case.

For anything class II or critical, the route is decided; the open question is which module, and that is a conversation to have with a notified body listed on NANDO, not with a consultancy.

Frequently asked questions

Who can certify a product under the CRA?

For the third-party routes, a notified body: a conformity assessment body that has been assessed, designated, notified and monitored by the member state in which it is established and published on the Commission's NANDO database, under the machinery in Chapter IV of the Regulation. Alternatively, a certification body operating a European cybersecurity certification scheme at assurance level at least substantial. A consultancy, an auditor or a testing lab that is not on NANDO for the CRA cannot certify conformity, whatever its report is called. For the internal control route, nobody certifies; the manufacturer assesses and declares.

Does applying a harmonised standard mean we can self-assess?

For a class I important product, only if two conditions hold: you apply all the applicable requirements of the standard, and the standard's scope covers at least all the cybersecurity risks of the product's core functionality. The standard also has to be one whose reference has been published in the Official Journal; a draft does not count. Risks from additional functions still have to be treated by other means and documented, and the presumption of conformity you gain stops at the edge of the standard's scope. For class II and critical products, applying a standard does not open self-assessment at all.

Do we need a new notified body assessment every time we update the product?

Only where the update is a substantial modification, and even then the guidance says the conformity assessment should focus on the substantially modified parts, that existing documentation and tests may be reused for unaffected parts, and that a third-party assessor should concentrate on what changed. Routine maintenance, repair and refurbishment that do not change the intended purpose or the level of risk are generally not substantial modifications. The practical consequence is to structure the technical file so unchanged parts can be shown to be unchanged.

Does an existing type-examination certificate under the Radio Equipment Directive count?

Partly, and for a limited time. Under Article 69(1), EU type-examination certificates and approval decisions issued for cybersecurity requirements under other Union legislation remain valid until 11 June 2028 unless they expire sooner, and you may rely on them as evidence for the risks they cover, such as network protection, personal data and fraud prevention under the Radio Equipment Directive delegated act. You still have to carry out the full CRA risk assessment, and risks the certificate does not cover, the guidance names vulnerability handling, data minimisation and attack surface reduction, have to be assessed and treated under the CRA regardless.