Under the Cyber Resilience Act, a manufacturer may place a product on the EU market only after it has drawn up the technical documentation and completed the conformity assessment procedure that applies to the product. Once that procedure shows that the product and the manufacturer’s vulnerability handling meet the essential cybersecurity requirements, the manufacturer signs the EU declaration of conformity and affixes the CE marking. Article 13(12).
This guide explains what each procedure involves, how to prepare the evidence, how to work with a notified body where one is required, and how to complete the declaration and marking. It assumes you already know the product’s category; our CRA product classification guide covers that step.
What must be done before the product is placed on the market
In order:
- Draw up the technical documentation.
- Carry out the conformity assessment procedure, or have it carried out.
- Once it has a positive result, draw up and sign the EU declaration of conformity.
- Affix the CE marking.
The manufacturer remains responsible for the product’s compliance, including when a consultant, test laboratory or notified body contributes to the work.
Dates. These obligations apply from December 11, 2027, to every unit placed on the market from that date, including units of models designed earlier. Units placed on the market before then come under the CRA only if they are substantially modified afterwards. Vulnerability and incident reporting already applies, to all products in scope. Our CRA reporting requirements guide covers it.
Which procedures you can use depends on the product’s category:
| Category | Procedures available |
|---|---|
| Default | Any procedure, including internal control (Module A) |
| Important, Class I | Module A only if you apply harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level “substantial” or higher, covering the relevant requirements; otherwise B+C or H |
| Important, Class II | B+C, H, or an applicable European cybersecurity certification scheme at assurance level “substantial” or higher |
| Critical | An EU cybersecurity certificate where the Commission has made one mandatory for the category; otherwise the same procedures as Class II |
For Class I, the Commission’s guidance reads the condition strictly. You must apply all the applicable requirements of a relevant harmonized standard, and the standard must cover at least the risks of the product’s core function. Risks from additional functions still need their own measures. Commission guidance, paragraphs 148-152.
Three cases follow different rules:
- Open-source software in an important category: it can use Module A, provided the technical documentation is made public when the product is placed on the market.
- High-risk AI systems: these generally follow the AI Act’s procedure, which then also covers the CRA requirements. One exception: if the product is a critical product, or an important product that cannot use Module A under the CRA, and the AI Act allows it internal control, the CRA’s own procedures apply to its cybersecurity requirements. Article 12.
- Electronic health record systems: an amendment made by the European Health Data Space Regulation directs them to that Regulation’s procedure. That Regulation applies in phases. Its rules on placing EHR systems on the market apply from March 26, 2029 or March 26, 2031, depending on the categories of health data the system processes.
If one of these applies, check which procedure applies to your product on the date you place it on the market.
What Modules A, B+C and H involve
| Procedure | What the manufacturer does | What the notified body does | What continues afterwards |
|---|---|---|---|
| Module A, internal control | Draws up the technical documentation; makes sure design, development, production and vulnerability handling keep the product compliant; signs the declaration and affixes the CE marking | Not involved | Keep the documentation current and available to authorities |
| Module B, EU-type examination | Applies to one notified body with the technical documentation, risk assessment and supporting evidence | Examines the documentation and specimens, carries out or commissions tests, and issues an EU-type examination certificate if the product type and vulnerability handling processes comply | Tell the body about changes that may affect conformity; the body audits vulnerability handling periodically |
| Module C, conformity to type | Keeps production in line with the approved type; signs the declaration and affixes the CE marking | Does not assess production | Keep production consistent with the approved type |
| Module H, full quality assurance | Runs an approved quality system covering design, development, final testing and vulnerability handling, for the whole support period; signs the declaration and affixes the CE marking with the body’s number | Assesses and approves the quality system, including a visit to your premises where they exist; carries out surveillance audits | Tell the body about intended changes to the quality system |
Module A still needs evidence. No outside body checks the work, but the manufacturer must still implement the measures from its risk assessment and verify, by testing or other means, that the product complies. It must also document the result before signing.
Module B is always followed by Module C. The examination covers the product’s design and the manufacturer’s vulnerability handling processes. The certificate identifies the approved type and any conditions for its validity. The Commission’s FAQ notes that the notified body sets its validity period.
Module H needs a quality system written for the CRA. The system must show how products meet the essential requirements and how vulnerabilities are handled. It can build on an existing quality management system, but the FAQ makes clear that an ISO 9001 certificate alone does not satisfy Module H. The Commission suggests the module may suit manufacturers with many product types or frequent releases.
Certification schemes can be used only once the Commission has specified a scheme for the purpose, and only for the requirements the certificate covers. For Class I and Class II products, the certificate must be at assurance level “substantial” or higher, as the table shows. A critical product needs a certificate only where the Commission has made one mandatory for its category. Check whether a scheme exists for your category before planning on this route.
Prepare the evidence
Every procedure rests on the same core evidence:
- The exact product assessed: hardware revision, software version and configuration, including any remote data processing that forms part of the product.
- The risk assessment: which requirements apply, why any do not, and how each risk is treated. See our CRA risk assessment guide.
- The technical documentation. See our CRA technical documentation guide.
- Test and review results for the version being assessed.
- Vulnerability handling evidence, including the SBOM, the coordinated vulnerability disclosure policy and the update mechanism. See our CRA SBOM requirements guide.
- The standards and specifications you applied, including any you applied only in part.
Testing. The CRA does not prescribe a test method or set requirements for test laboratories; you can test in-house or use an external laboratory. Market surveillance authorities may test the product themselves, with a different method where justified. Record the method, the version tested and the results so the tests can be repeated.
For Module B, the application to the notified body includes:
- your name and address, and those of your authorized representative if it lodges the application;
- the technical documentation, with an adequate analysis and assessment of the risks;
- the supporting evidence for your design and vulnerability handling solutions, with test results where necessary;
- a written declaration that the same application has not been lodged with any other notified body.
Say which documents you relied on, especially where you did not apply a harmonized standard in full. The body will also examine specimens of critical parts of the product and agree with you where tests take place, so plan which specimens and test environments you can provide.
For Module H, the application includes:
- your name and address, and those of your authorized representative if it lodges the application;
- the technical documentation for one model of each product category to be covered;
- the quality system documentation;
- the same written declaration that the application has not been lodged with any other notified body.
The quality system documentation describes responsibilities, design and verification controls, tests and their frequency, and the records kept. Module H does not remove the need for technical documentation for each product.
Language. Documents for a notified body must be in an official language of the country where the body is established, or in a language the body accepts.
Standards. Applying a harmonized standard gives a presumption of conformity only once its reference has been published in the Official Journal, and only for the requirements it covers. Check that the reference has been published before relying on it for presumption, and record which requirements remain outside it. Our risk assessment guide explains how the EN 40000 standards fit together, and our IEC 62443 and Cyber Resilience Act guide explains how existing IEC 62443 work can contribute. Article 27.
Working with a notified body
Check the body’s notification. A body can act under the CRA only once it has been notified for it. The notification states the modules and products it covers. Accreditation, an ISO certificate or a notification under other EU legislation does not on its own make a body a CRA notified body. Look the body up in the Commission’s NANDO database and check that it is listed for the Cyber Resilience Act, for your module and for your product category.
Before you apply, agree with the body:
- the product, versions and configurations in scope;
- how you applied harmonized standards or other specifications, and where you did not;
- the specimens, test environments and access the body will need;
- how questions, additional evidence and changes during the assessment will be handled;
- who may receive the evaluation report. Under Module B, the body may release it only with your agreement, apart from what it must report to its notifying authority.
These planning points are an example of implementation. The CRA does not mandate this list; the application contents and the body’s tasks set out in the Regulation remain binding.
Fees must take account of the needs of microenterprises and small and medium-sized enterprises.
Draw up the EU declaration of conformity
The declaration states that the product meets the essential cybersecurity requirements, and by signing it the manufacturer takes responsibility for that. It follows the model in Annex V:
- product name, type and any information needed to identify it uniquely;
- name and address of the manufacturer or its authorized representative;
- a statement that the declaration is issued under the manufacturer’s sole responsibility;
- the object of the declaration, identified so it can be traced (a photograph may be included);
- a statement of conformity with the relevant EU legislation;
- the harmonized standards, common specifications or certification used;
- where applicable, the notified body’s name and number, the procedure followed and the certificate issued;
- additional information, signature, name and function of the signatory, and place and date of issue.
Provide it in the languages required by each country where the product is sold, and update it as needed. The Commission’s FAQ explains that the declaration does not need to list serial numbers. A new product version may need a new declaration, especially after a substantial modification.
One declaration for all EU laws. If other EU legislation also requires a declaration, for example the Radio Equipment Directive, draw up a single declaration covering all of them, naming each one.
What goes with the product:
- either a copy of the full declaration, or the simplified declaration in Annex VI, which gives the exact web address of the full declaration (a link to your homepage is not enough);
- the user information and instructions;
- at the time of purchase, the end date of the support period, at least the month and year.
The declaration is a public-facing document. The technical documentation is not: you do not have to share it with customers or the public, except for open-source software using the route described above.
Affix the CE marking
CE marking indicates that the manufacturer declares the product conforms with the applicable EU requirements, after completing the required conformity assessment procedure. Depending on the product and the procedure, that procedure may involve a notified body. Only the manufacturer or its authorized representative may affix it, and no other mark may be used in a way that could be confused with it.
Where:
- On the product, visibly, legibly and indelibly.
- On both the packaging and the accompanying declaration, if the nature of the product makes marking it impossible or unwarranted.
- For software, either on the declaration or on the website accompanying the software. On a website, the relevant section must be easy for consumers to reach directly.
When: before the product is placed on the market, and only after the conformity assessment procedure has a positive result.
Size: as a general rule at least 5 mm high, keeping the standard proportions. It may be smaller if the nature of the product requires it, provided it stays visible and legible, but not for design reasons.
Notified body number: under Module H, the body’s identification number follows the CE marking. The CRA does not require it under B+C, though other legislation that applies to the product may.
If other EU legislation also requires CE marking, the single marking covers all of it.
Example: a release that is not yet ready
Example Gateway 2.1 is a fictional building gateway with a companion mobile app. Assume the gateway is in the default category and its manufacturer has chosen Module A. Two weeks before the planned release, the team checks whether the evidence is complete.
| Item | Evidence | Status | Action before signing |
|---|---|---|---|
| Assessed release | Release record for firmware 2.1.0 and app 3.4.0, with the production configuration | Complete | None |
| Protection from unauthorized access | Risk treatment: no debug access on production units; penetration test of firmware 2.1.0 | Open: the test found the debug interface still reachable in the production configuration | Close the interface, retest the production build, update the risk assessment and test record |
| SBOM | SBOM for firmware 2.1.0 | Open: no SBOM yet for app 3.4.0 | Generate the app SBOM and add it to the technical documentation |
| Support period | Five-year support period decided and justified | Open: end date not yet shown at the point of sale | Add the month and year to the product page and packaging |
| Declaration and CE marking | Draft declaration naming the firmware and app versions | Waiting | Sign and mark only once the open items are closed |
This is an example of implementation based on the CRA’s internal control procedure. These record fields, statuses and review steps are not mandated by the CRA, and the rows are a sample. The underlying duties to assess conformity, document it and declare it remain binding.
The procedure has not yet reached a positive result, so the declaration stays unsigned and the release waits.
Under B+C or H, the same review would also confirm three things: the release matches the certified type or falls within the approved quality system, the conditions of the certificate or approval are met, and any relevant change has been reported to the notified body.
Keep the result current
Your documentation. Keep the technical documentation up to date for at least the support period, and update the declaration when needed.
Under Module B. Tell the notified body about every change to the approved type or the vulnerability handling processes that may affect conformity or the certificate’s conditions. This covers more than substantial modifications. Such changes need an addition to the certificate. The body also audits your vulnerability handling periodically.
Under Module H. Keep the quality system effective for the whole support period. Tell the notified body about intended changes; it decides whether they need reassessment. Expect periodic surveillance audits. According to the Commission’s FAQ, adding new or substantially modified products to the system needs a new assessment by the same body.
If the product stops complying. Take corrective action immediately, or withdraw or recall the product. Reporting exploited vulnerabilities and severe incidents is a separate duty.
Retention. Keep the technical documentation, the declaration and any certificates, quality system records and notified body decisions available to authorities. The period is at least ten years after the product is placed on the market, or the whole support period if that is longer. Article 13(13).
Check before you sign the declaration
- The procedure is one your product’s category allows, and its conditions are met and recorded.
- The technical documentation names the exact release you are placing on the market.
- Every applicable requirement has evidence, and every requirement you treat as not applicable has a reason.
- Any harmonized standard you rely on for presumption of conformity, or for the choice of procedure, has a reference published in the Official Journal, and the requirements it does not cover are handled. Other standards and technical references can still support your evidence.
- Under B+C or H, the certificate or approval covers this release, its conditions are met, and changes have been reported.
- The declaration has every Annex V element, in the right languages, and the simplified version gives the exact address of the full one.
- The CE marking is placed correctly for this type of product, with the body’s number under Module H.
How Meroi Security can help
Meroi Security can help you confirm which procedure applies, organize the risk assessment and technical documentation, review the evidence for gaps before a notified body sees it, and prepare the declaration of conformity. Where a notified body is required, the formal assessment and certificate come from that body. Explore our Cyber Resilience Act compliance services.
In the regulation
- Article 13: Obligations of manufacturers
- Article 27: Presumption of conformity
- Article 28: EU declaration of conformity
- Article 30: Rules and conditions for affixing the CE marking
- Article 32: Conformity assessment procedures for products with digital elements
- ANNEX V: EU DECLARATION OF CONFORMITY
- ANNEX VI: SIMPLIFIED EU DECLARATION OF CONFORMITY
- ANNEX VIII: CONFORMITY ASSESSMENT PROCEDURES
Related guides
- EU Cyber Resilience Act Product Classification: Categories and Conformity Routes Cyber Resilience Act product classification: Annex III and IV categories, core functionality, conformity routes and when a notified body is needed.
- Cyber Resilience Act Technical Documentation: Building the Evidence File Prepare Cyber Resilience Act technical documentation with an Annex VII evidence checklist, product-version traceability, review steps and retention requirements.
- Cyber Resilience Act Cybersecurity Risk Assessment: Article 13 and Annex I in Practice How to carry out the CRA cybersecurity risk assessment: scope, intended and foreseeable use, Annex I applicability, residual risk, components and updates.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act)
- Commission guidance C(2026) 5252 on the application of the CRA, section 6
- Commission services CRA FAQ v1.4, September 4, 2026, sections 6 and 7
- Regulation (EC) No 765/2008 (accreditation and market surveillance; CE marking principles)
- European Commission, NANDO notified bodies database