CE Marking and the EU Declaration of Conformity Under the CRA: What You Sign and What Sits Behind It
For the vast majority of products with digital elements (PDEs), the legal gateway to the EU market under the Cyber Resilience Act comes down to three documents: a technical file, an EU Declaration of Conformity (DoC), and the CE marking that follows from them. The manufacturer - not a notified body, not a certification lab - carries out the assessment, draws up the technical documentation, signs the DoC, and affixes the CE marking. This post explains the mechanics of each document, how the Module A self-assessment route works for Default-class products, and what you can and should be building right now.
This article is general guidance on the Cyber Resilience Act, not legal advice. Confirm specifics against Regulation (EU) 2024/2847 and seek qualified legal or regulatory advice for your situation.
Key points
- The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024; CE marking, the EU Declaration of Conformity, technical documentation, and the essential requirements all become fully enforceable from 11 December 2027.
- The EU Declaration of Conformity is the formal legal document in which the manufacturer declares the product meets the applicable requirements; its required content is set out in Annex V; it is mandatory before CE marking can be affixed.
- The technical documentation behind the DoC is governed by Annex VII and must be kept for at least 10 years after the product is placed on the market (or the support period, whichever is longer).
- Roughly 90% of PDEs fall into the Default class and may use Module A "internal control" self-assessment (Annex VIII) - no notified body required.
- Self-assessment does not mean lighter requirements. The product must still meet all Annex I essential requirements; the manufacturer simply attests to it themselves.
- As of June 2026, no CRA harmonised standard has been cited in the Official Journal, so the Article 27 presumption of conformity is not yet available for any product category. Manufacturers must demonstrate conformity directly against Annex I.
- You can - and should - start building the technical file and drafting the DoC now, well ahead of the December 2027 deadline.
The three documents and how they connect
Think of the paperwork as a stack. The technical file is the evidence base. The EU Declaration of Conformity is the legal statement that summarises and certifies that evidence. The CE marking is the visible signal to the market that the statement has been made. You cannot have the CE marking without the DoC, and you cannot have a credible DoC without the technical file.
The EU Declaration of Conformity (Annex V): what it must contain
The EU Declaration of Conformity is drawn up by manufacturers and states that the fulfilment of the applicable essential cybersecurity requirements set out in Annex I has been demonstrated. It must follow the model structure set out in Annex V and contain the elements specified in the relevant conformity assessment procedures set out in Annex VIII.
Annex V specifies the minimum content. The required elements are:
| Element | Notes |
|---|---|
| Product name and type | Sufficient detail to uniquely identify the product; a photograph may be included |
| Manufacturer name and address | Or authorised representative if applicable |
| Statement of sole responsibility | A legally required verbatim phrase - do not paraphrase it |
| Object of the declaration | Description allowing traceability |
| Statement of conformity | Declares compliance with Regulation (EU) 2024/2847 and any other applicable Union harmonisation legislation |
| Conformity assessment module used | Module A (internal control), B+C, H, or a European cybersecurity certification scheme |
| Signed declaration | Date, place, name, and function of the signatory |
A declaration number is not mandatory, but is strongly recommended for version control and internal tracking.
The declaration must be updated as appropriate and made available in the languages required by the Member State in which the product is placed on the market.
The simplified DoC option
The CRA also provides an option for a simplified declaration (Article 13(20) in connection with Annex VI). This version is shorter and can be used, for example, in packaging or user manuals where space is limited. Where a simplified EU Declaration of Conformity is provided, it shall contain the exact internet address at which the full EU Declaration of Conformity can be accessed. The URL must be stable (do not change it after products are distributed), accessible without registration or login, and the page should allow the DoC to be downloaded or printed.
The full DoC must still exist in the technical file and be available to authorities on request, even when you distribute only the simplified version with the product. The simplified version is a pointer, not a substitute.
Where the CE marking goes
The CE marking shall be affixed visibly, legibly and indelibly to the product. Where that is not possible or not warranted on account of the nature of the product, it shall be affixed to the packaging and to the EU Declaration of Conformity accompanying the product.
Software products get a specific rule: for products with digital elements which are in the form of software, the CE marking shall be affixed either to the EU Declaration of Conformity or on the website accompanying the software product. In the latter case, the relevant section of the website shall be easily and directly accessible to consumers.
The CE marking shall be affixed before the product is placed on the market. Affixing it afterwards - or affixing it before the DoC is signed - is non-compliant.
If a notified body is involved in a Module H (full quality assurance) procedure, the CE marking shall be followed by the identification number of the notified body, affixed by the body itself or, under its instructions, by the manufacturer. For Module A self-assessment, no notified body number appears.
The technical documentation (Annex VII): what goes in the file
The technical documentation is the complete package of evidence, security controls, lifecycle processes and product information required to demonstrate conformity with the essential cybersecurity requirements in Annex I. It must be created before placing the product on the market and kept updated throughout the lifecycle.
Annex VII sets out the minimum content. In practice, the file typically includes:
- General product description and intended use - what the product does, who it is for, software versions covered
- Security architecture and design - how the product is structured, interfaces, trust boundaries
- The Article 13 cybersecurity risk assessment and its results - the document that determines which Annex I requirements apply and how; see our Article 13 risk assessment guide for the full treatment
- The SBOM - a machine-readable inventory of software components; see the SBOM guide for detail on format and content
- Description of the vulnerability-handling and disclosure process - how you receive, triage, and remediate reported vulnerabilities
- Description of the update mechanism - how security updates are delivered to users during the support period
- Test and assessment results - evidence that the product was tested against the requirements you claim to meet
- Standards or specifications applied - including any harmonised standards or common specifications relied upon
When placing a product on the market, the manufacturer shall include the cybersecurity risk assessment in the technical documentation required pursuant to Article 31 and Annex VII. Where certain essential cybersecurity requirements are not applicable to the product, the manufacturer shall include a clear justification to that effect in that technical documentation.
Manufacturers shall keep the technical documentation and the EU Declaration of Conformity at the disposal of the market surveillance authorities for at least 10 years after the product has been placed on the market or for the support period, whichever is longer.
The technical file is a living document, not a one-time deliverable. If the product changes substantially, or if new threats emerge that affect your risk assessment, the file — and potentially the DoC — must be updated. Build version control into your documentation process from the start.
Our compliance checklist has a section-by-section breakdown of Annex VII to help you track what you have and what is still missing.
Module A: how the Default-class self-assessment actually works
Generally, the manufacturer can choose between a self-assessment procedure (the so-called internal control procedure based on Module A), a third-party conformity assessment procedure via a notified body, or, where available and applicable, a European cybersecurity certification scheme.
For Default-class products, Module A is the standard route. This procedure, set out in Annex VIII, does not require an external notified body. Instead, the responsibility remains fully with the manufacturer.
What Module A actually requires the manufacturer to do:
- Draw up the technical documentation covering all Annex VII elements.
- Evaluate the product against all applicable Annex I essential requirements, using the technical documentation as the evidence base.
- Declare conformity by signing the EU Declaration of Conformity.
- Affix the CE marking.
- Keep the file available to market surveillance authorities for the required retention period.
The critical point: the company must compile comprehensive technical documentation - product description, design and production details, risk analysis, vulnerability handling processes, applied standards, and test results. These elements serve as evidence that the essential cybersecurity requirements of the CRA (Annex I) have been met. Module A shifts the burden of proof onto the manufacturer's own documentation, which is why the quality of the technical file matters so much.
What about Important and Critical products?
If your product is in Annex III (Important, Class I or II) or Annex IV (Critical), the route is different. When a product is an Important product of Class I, the manufacturer can make use of the self-assessment procedure only if it has applied harmonised standards, common specifications (where available), or made use of a European cybersecurity certification scheme (where available and applicable); otherwise, it needs to undergo third-party assessment via a notified body. In the case of Class II products, a conformity assessment procedure involving a notified body is mandatory.
Not sure which class your product falls into? Use the scope checker or read the product classes guide - this post does not re-cover classification.
The standards gap: what it means for your DoC right now
This is the most practically important context for 2026.
No CRA harmonised standard has been published in the Official Journal yet (as of early June 2026), so the Article 27 presumption of conformity is not available for any product category.
In April 2025, CEN, CENELEC, and ETSI officially accepted Standardisation Request M/606 from the European Commission to develop a set of 41 EU-wide harmonised standards for CRA compliance by Q3 2026. Public enquiry of the key horizontal draft (EN 40000-1-4, generic security requirements) is expected to take place from mid-July to mid-November 2026. Ratification as an EN is still not the finish line: the Commission must then cite the reference in the Official Journal, and only that citation triggers the presumption of conformity.
The two core horizontal standards, on secure development and on vulnerability handling, are expected by 30 August 2026; the vertical standards by 30 October 2026. Until standards are cited, conformity must be demonstrated directly against the Annex I requirements.
What this means in practice: For Default-class products using Module A, you are already in the right lane - you demonstrate conformity directly against Annex I regardless of whether harmonised standards exist. The standards gap does not block you; it just means you cannot take the shortcut of a presumption of conformity. Build your technical file against Annex I directly.
For Important Class I products, the gap is more acute: one of the most urgent gaps is Important Class I, where conformity is expected to rely on vertical standards (i.e., product-type-specific requirements). Until those standards are cited, Class I manufacturers who want to self-assess face uncertainty about the exact technical bar. Watch the EC standardisation page for citation notices.
Settled vs. still developing (June 2026)
Settled: The legal text of the CRA, the Annex V DoC structure, the Annex VII technical documentation requirements, the Module A self-assessment route for Default products, and the Chapter IV notified-body notification framework (in force since 11 June 2026).
Still developing: Harmonised standards under M/606 (none yet cited in the Official Journal); the EC's draft guidance on scope (consultation closed 31 March 2026, final version not yet published); and the ENISA single reporting platform for the September 2026 vulnerability-reporting obligations.
What to do now: building your technical file and drafting the DoC
The deadline is 11 December 2027, but the technical file and DoC are not documents you write in a week. Here is a practical sequence.
Use the scope checker to confirm whether your product is Default, Important Class I/II, or Critical. Your class determines your conformity assessment route. Everything else follows from this.
Create a version-controlled folder or document management system for each product. Include the product name, version(s) in scope, intended use, and the date the file was opened. Annex VII is your content checklist.
This is the load-bearing document. It determines which Annex I requirements apply and how, and it must be included in the technical file. See the Article 13 guide for the methodology.
Produce a description of the product's security design: interfaces, trust boundaries, authentication mechanisms, data flows, update path. This does not need to be a formal threat model (though that helps), but it must be sufficient for a market surveillance authority to understand how the product is secured.
For any product containing software, an SBOM is required. See the SBOM guide for format options (SPDX, CycloneDX) and what the CRA requires. Automate generation in your build pipeline so it stays current.
Describe how you receive vulnerability reports (your coordinated vulnerability disclosure policy), how you triage and remediate them, and how security updates reach users. These are Annex I, Part II obligations and must appear in the technical file.
Record the results of any security testing — penetration tests, static analysis, fuzz testing, code review — and map them to the Annex I requirements they address. Where a requirement is not applicable, document the justification.
Using the Annex V structure, draft the DoC. Reference Module A (Annex VIII, internal control) as the conformity assessment procedure. Include the legally required verbatim statement of sole responsibility. Have it reviewed before signing.
Once the technical file is complete and the assessment is done, sign the DoC, affix the CE marking (on the product, packaging, DoC, or website as appropriate for your product type), and publish the DoC at a stable, publicly accessible URL.
The technical file and DoC are not static. Schedule reviews when: a new version is released that may constitute a substantial modification; a significant new vulnerability is discovered; or harmonised standards are cited in the Official Journal and you want to rely on the presumption of conformity.
Interactive: DoC readiness self-check
Use this tool to assess how complete your EU Declaration of Conformity and technical file are right now.
Common mistakes to avoid
Signing the DoC before the technical file is complete. The DoC is a declaration that conformity has been demonstrated. If the technical file is not yet complete, the declaration is not yet true. Sequence matters.
Treating Module A as a lighter-touch process. Self-assessment means the manufacturer bears full responsibility for demonstrating conformity against all Annex I requirements. The absence of a notified body does not reduce the evidentiary bar - it raises the stakes on the quality of your own documentation.
Forgetting to update the DoC. The declaration shall be updated as appropriate. A product that undergoes a substantial modification after the DoC is signed requires a fresh assessment and an updated declaration.
Publishing the DoC at a URL that changes. The URL must be stable - do not change it after products are distributed. Use a permanent, dedicated page rather than a blog post or a file path that may be reorganised.
Waiting for harmonised standards before starting. Many manufacturers are waiting for harmonised standards to be finalised before acting. That may lead to challenges such as missed timelines. While CEN/CENELEC and ETSI have committed to delivering these standards at least one year before full CRA application, delays are possible and preparation should not wait.
Further reading
- Key deadlines at a glance
- CRA product classes: Default, Important, Critical
- Article 13 risk assessment guide
- SBOM guide
- Full compliance checklist
- EC conformity assessment page
- EC standardisation page
- Regulation (EU) 2024/2847 on EUR-Lex
Stay ahead of the standards gap. When harmonised standards under M/606 are eventually cited in the Official Journal, manufacturers who have already built their technical files against Annex I directly will be well placed to map their existing evidence to the new standards — and potentially gain the presumption of conformity with minimal rework.
For monthly updates on CRA standardisation progress, guidance publications, and deadline changes, subscribe to The CRA Brief — a short, plain-English newsletter from CRA Facts.
Related reading
CRA vs NIS2: Which EU Cyber Rule Applies to Your Software - and Is SaaS in or Out?
The CRA covers products placed on the market; NIS2 covers organisations operating essential services. Pure SaaS is generally out of CRA scope - but the line is not always clean.
The CRA Support Period: It's Not a Flat Five Years
The CRA support period is not a flat five-year rule. It's the expected product lifetime - and at least five years. Here's how to set, justify, and communicate yours.
Article 13 CRA Risk Assessment: The Document That Holds Everything Together
Article 13 of the Cyber Resilience Act requires a documented cybersecurity risk assessment before CE marking. Here's what it must cover, why it's load-bearing, and how to build one.