The manufacturer carries the deepest CRA (Regulation (EU) 2024/2847) obligation set: Article 13 (design, technical documentation, conformity assessment, support period, post-market duties), Article 14 (24h/72h reporting of actively exploited vulnerabilities and severe incidents to ENISA and the coordinator CSIRT), and Annex I (13 product requirements in Part I, 8 vulnerability-handling requirements in Part II). This page covers each duty, plus the Article 3(13) test that decides whether you are the manufacturer at all.
Summary
- Article 3(13) classification: you are a manufacturer if you develop or have products designed, developed or manufactured and market them under your own name or trademark. Branding decides; supply contracts do not.
- Article 13 obligations: cybersecurity risk assessment (13(2) to (4)), Annex I Part I + Part II compliance (13(1), 13(8)), component due diligence (13(5) to (6)), technical documentation (Article 31, Annex VII), conformity assessment (Article 32), EU DoC (13(20), Article 28, Annex V), CE marking (Article 30), support period of at least 5 years or expected in-use period (13(8)) with documented end date (13(19)), 10-year retention or support period whichever is longer (13(13)).
- Article 14 reporting: two streams, both via the ENISA single reporting platform under Article 16, simultaneously to the CSIRT designated as coordinator. Vulnerabilities: 24h early warning, 72h notification, final report 14 days after a corrective measure is available. Severe incidents: 24h early warning, 72h notification, final report within one month of the 72h notification.
- Penalty exposure (Article 64(2)): up to EUR 15 000 000 or 2.5% of total worldwide annual turnover, whichever is higher. Article 64(10) limits administrative-fine relief to micro and small enterprises on the 14(2)(a) and 14(4)(a) deadlines only.
- Deadlines: Article 14 vulnerability and incident reporting starts 11 September 2026. The rest of the manufacturer regime starts 11 December 2027 (Article 71).
Three numbers that frame manufacturer exposure: 21 essential requirements across Annex I, two reporting deadlines per stream, top-tier fine.
Who Is a Manufacturer under the CRA?
Article 3(13) defines the manufacturer verbatim:
"Manufacturer" means a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge.
You are a manufacturer for CRA purposes if both of the following apply:
| Element | Test |
|---|---|
| Develop, manufacture, or have products designed/developed/manufactured | Includes outsourced design or contract manufacturing. The work need not happen on your premises. |
| Market under your own name or trademark | The product as placed on the market identifies your entity as the source, by branding, packaging, marketing materials or accompanying documentation. |
The two elements are cumulative. A factory that produces a product but markets it under another company's brand is not the manufacturer for CRA purposes; the brand owner is. Conversely, a company that puts its own brand on a product designed and built by a third-party factory is the manufacturer regardless of who did the engineering. Free, monetised and paid distribution all count; the regulation explicitly says "whether for payment, monetisation or free of charge".
If neither element applies you are not the manufacturer. You may be the importer under Article 3(16) (you place a non-EU-branded product on the Union market), the distributor under Article 3(17) (you make the product available after the importer without affecting its properties), or the authorised representative under Article 3(15) and Article 18 (you act on the manufacturer's behalf by written mandate). A third-party who substantially modifies a product after market placement is treated as the manufacturer of the modified version under Article 22; the same analysis applies via Article 3(13) when the modifier markets the modified product under its own name. For the full role-classification matrix and the decision tree comparing all five roles, see who must comply with the CRA.
Article 13 at a Glance
| Para | Duty | Key point |
|---|---|---|
| 13(1) | Design and produce against Annex I Part I | Essential requirements are mandatory, modulated by the cybersecurity risk assessment. |
| 13(2) to (4) | Cybersecurity risk assessment | Documented, updated across the support period, included in technical documentation under Article 31. |
| 13(5) to (7) | Component due diligence | Includes free and open-source components. Document vulnerabilities of which the manufacturer becomes aware; report upstream and remediate. |
| 13(8) | Support period | At least 5 years, or the expected in-use period if shorter. Documented in the technical documentation. Includes vulnerability-handling and CVD policy obligations. |
| 13(9) | Security update availability | Each security update remains available for at least 10 years after issuance, or for the remainder of the support period, whichever is longer. |
| 13(10) to (11) | Substantially modified software versions | Compliance with Annex I Part II (2) may apply only to the latest version where users have free access to it; public archives of unsupported versions allowed with risk warnings. |
| 13(12) to (14) | Pre-market technical doc + conformity assessment + CE; series-of-production controls | Draw up technical documentation under Article 31; carry out conformity assessment under Article 32 or have it carried out; draw up the EU DoC and affix CE; maintain procedures so series production stays compliant. |
| 13(13) | Retention | Technical documentation and EU DoC at the disposal of market surveillance authorities for at least 10 years or the support period, whichever is longer. |
| 13(15) to (16) | Product identification + manufacturer identification | Type/batch/serial number; manufacturer name, trade name or trademark, postal address, digital contact, also reproduced in Annex II information. |
| 13(17) | Single point of contact | Allows users to choose their preferred means of communication. Must not be limited to automated tools. |
| 13(18) | Annex II accompaniment | Information and instructions in a language easily understood by users and market surveillance, accessible online for the same retention period. |
| 13(19) | Support-period end date | Specified at time of purchase, including at least the month and year. Display end-of-support notification to users where technically feasible. |
| 13(20) | EU DoC delivery | Either full DoC or simplified DoC containing the exact internet address at which the full DoC can be accessed. |
| 13(21) to (22) | Post-market corrective measures + cooperation | Withdraw, recall or bring back into conformity on awareness of non-conformity. Provide all information to market surveillance on reasoned request. |
| 13(23) | Cessation of operations | Inform market surveillance and, by any means available, the users before cessation takes effect. |
| 13(24) to (25) | SBOM format + dependency assessments | Commission may specify SBOM format by implementing acts. ADCO may run Union-wide dependency assessments. |
Annex I: The Essential Cybersecurity Requirements
Annex I has two parts. Part I lists 13 requirements about the product's properties, modulated by the manufacturer's cybersecurity risk assessment under Article 13(2). Part II lists 8 requirements about the manufacturer's vulnerability-handling processes; these are not risk-modulated and apply regardless of product type or class.
Part I: Product Properties (Article 13(1), Annex I Part I)
Products with digital elements shall be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. On the basis of the cybersecurity risk assessment under Article 13(2), the following apply where applicable:
| Code | Requirement |
|---|---|
| (a) | Made available without known exploitable vulnerabilities |
| (b) | Secure-by-default configuration; reset-to-original-state available (tailor-made products to business users may agree otherwise) |
| (c) | Vulnerabilities addressable through security updates; automatic updates installed within an appropriate timeframe by default with an opt-out and postpone option, where applicable |
| (d) | Protection from unauthorised access (authentication, identity or access management, reporting on possible unauthorised access) |
| (e) | Confidentiality of stored, transmitted, processed data, including encryption at rest or in transit using state-of-the-art mechanisms |
| (f) | Integrity protection of data, commands, programs, configuration; reporting on corruptions |
| (g) | Data minimisation: process only data adequate, relevant, and limited to the intended purpose |
| (h) | Availability of essential and basic functions, also after an incident; resilience to denial-of-service |
| (i) | Minimise negative impact on availability of services provided by other devices or networks |
| (j) | Limit attack surfaces, including external interfaces |
| (k) | Reduce incident impact via exploitation mitigation mechanisms and techniques |
| (l) | Provide security information by recording and monitoring relevant internal activity, with user opt-out |
| (m) | Allow users to securely and easily remove all data and settings; ensure secure data transfer where applicable |
The "where applicable" qualifier in Annex I Part I (2) means the manufacturer's risk assessment determines which (a)–(m) requirements bind the product. Where a requirement is not applicable, the technical documentation must include a clear justification under Article 13(4).
Part II: Vulnerability Handling (Article 13(8), Annex I Part II)
Part II is unconditional: it applies across the full support period regardless of product class or risk profile.
| Code | Requirement |
|---|---|
| (1) | Identify and document vulnerabilities and components, including a software bill of materials (SBOM) in a commonly used machine-readable format covering at least the top-level dependencies |
| (2) | Address and remediate vulnerabilities without delay through security updates; where technically feasible, separate security updates from functionality updates |
| (3) | Apply effective and regular tests and reviews of product security |
| (4) | Once a security update is available, share and publicly disclose information about fixed vulnerabilities (description, affected products, impacts, severity, remediation guidance). May delay public disclosure in duly justified cases until users can apply the patch |
| (5) | Put in place and enforce a coordinated vulnerability disclosure (CVD) policy |
| (6) | Facilitate sharing of information about potential vulnerabilities (including in third-party components) by providing a contact address for vulnerability reports |
| (7) | Mechanisms to securely distribute updates so vulnerabilities are fixed in a timely manner and, where applicable, automatically |
| (8) | Disseminate security updates without delay; free of charge unless agreed otherwise with a business user for tailor-made products; with advisory messages to users |
Part II runs from market placement through the support period (Article 13(8)). Security updates remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer (Article 13(9)).
Pre-market artefacts: what must exist before placing the product on the market
Four artefacts must exist before the product is placed on the market. Each is anchored in a specific CRA article and produces a specific compliance act: the file the manufacturer keeps, the assessment it runs, the declaration it signs, the mark it affixes.
| Artefact | Anchor | What it contains or requires |
|---|---|---|
| Technical documentation | Article 31, Annex VII (drawn up under Article 13(12)) | Product description, design and development information, the cybersecurity risk assessment under Article 13(2), the harmonised standards or common specifications applied, the conformity-assessment route and result, the EU DoC, and the vulnerability-handling process. Retained for at least 10 years or the support period, whichever is longer (Article 13(13)). |
| Conformity assessment | Article 32 | Module A self-assessment for default-class products only. Important Class II by default, and Critical products absent a European cybersecurity certification scheme, require Module B+C or Module H via a notified body. Important Class I may use Module A only where harmonised standards, common specifications, or a cybersecurity certification scheme are fully applied. |
| EU Declaration of Conformity | Article 13(20), Article 28, Annex V | Either the full DoC supplied with the product or a simplified DoC carrying the exact internet address of the full DoC. Annex V fixes the contents: manufacturer name and address, product identification, statement of conformity with Annex I, standards applied with reference numbers and dates, notified-body name and number where applicable, certificate reference, date, signature, signatory name and function. |
| CE marking | Article 30, Regulation (EC) No 765/2008 | At least 5 mm high, visible, legible, indelible, on the product or its data plate. Where size or nature does not permit, on the packaging and accompanying documents. Where a notified body intervened in production control, its four-digit identification number follows the CE mark. |
The conformity-assessment module choice is the single most consequential decision in this section. The table and the decision diagram below give the row-by-row detail.
| Module | When |
|---|---|
| A internal production control | Default-class products only |
| B + C EU-type examination + production control | Important Class II by default; Class I where no relevant harmonised standard, common specification or European cybersecurity certification scheme is applied |
| H full quality assurance | Alternative for Important products; required for Critical products absent a European cybersecurity certification scheme covering the requirements |
See the technical documentation guide, conformity assessment guide, product classification guide, and declaration of conformity guide for the details of each artefact.
Reporting Deadlines for Manufacturers (Article 14)
Article 14 sets two reporting streams for manufacturers, both routed simultaneously to the CSIRT designated as coordinator and to ENISA via the single reporting platform under Article 16. The two streams share the 24h/72h cadence but have different final-report deadlines, a frequently-misunderstood point.
| Stream | 24h early warning | 72h notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability (14(1)–(2)) | Within 24h of awareness | Within 72h of awareness | 14 days after a corrective or mitigating measure is available |
| Severe incident (14(3)–(5)) | Within 24h of awareness | Within 72h of awareness | One month after the 72h notification |
The vulnerability final-report clock starts when the patch is ready, not when awareness occurred; the gap can be weeks or months. The severe-incident final-report clock is fixed at the 72h notification, so day 33 from awareness in practice. See the vulnerability reporting cluster guide for the operational workflow, the CSIRT coordinator routing under Article 14(7) (including the fallback cascade for non-EU manufacturers), the user-notification duty under Article 14(8), and the Article 16 single reporting platform mechanics.
Support Period and Post-Market Duties
Article 13(8) sets the support period at at least 5 years, or the expected in-use period if shorter; security updates remain available for at least 10 years after issuance under Article 13(9). The end date (at least month and year) must be disclosed at point of purchase under Article 13(19). See the support period cluster guide for determination criteria, the substantially-modified-software-version rules at 13(10) and (11), and the EOL-notification duty.
Two manufacturer post-market duties live alongside the support-period regime and do not have their own cluster page. Article 13(21)–(22): on awareness of non-conformity with Annex I, the manufacturer immediately takes corrective measures, or withdraws or recalls as appropriate, and on a reasoned request from a market surveillance authority provides all information needed to demonstrate conformity in a language the authority understands. Article 13(23): a manufacturer ceasing operations informs the relevant market surveillance authorities before cessation takes effect, and informs users by any means available and to the extent possible.
Manufacturer vs Article 22 Substantial Modifier
Article 22 covers a different case from Article 3(13) classification. Verbatim:
"A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of a product with digital elements and makes that product available on the market, shall be considered to be a manufacturer for the purposes of this Regulation."
Article 22 explicitly excludes manufacturers, importers and distributors. It applies to third parties outside the Article 3 chain: system integrators, value-added resellers, enterprise IT departments that modify vendor products before redistribution. The Article 22(2) scope is sharp: the modifier is treated as manufacturer for the part of the product affected by the substantial modification, or for the entire product if the modification has an impact on the product's cybersecurity as a whole. "Substantial modification" is defined in Article 3(30) as a change after market placement that affects compliance with Annex I Part I or modifies the intended purpose for which the product was assessed.
| Case | Classification |
|---|---|
| Original engineering, original brand | Manufacturer (Article 3(13)) |
| Original brand, third party adds firmware features after market placement that change attack surface | Original manufacturer remains; the third party is also a manufacturer for the modified part under Article 22 |
| White-label rebrand of a non-EU product by an EU entity | EU entity is the manufacturer under Article 3(13); not "Article 22 escalation" |
| EU integrator bundles compatible products without modifying their internals | Distributor under Article 3(17), not Article 22 |
| Enterprise IT installs a custom firmware build on vendor devices, then resells | Article 22 modifier; treated as manufacturer for the modified product |
The practical consequence of Article 22 catching a third party: full Article 13 and Article 14 obligations for the modified part or whole product, including a fresh technical file, a fresh DoC, fresh CE under the modifier's responsibility, and the Article 14 reporting cadence above.
Implementation Timeline
Common Pitfalls
| Claim | Why it fails |
|---|---|
| "We are not really the manufacturer; an OEM in another country builds it." | Article 3(13) catches the brand owner. Outsourcing the build does not transfer the obligation. |
| "Our security policy is good enough; we do not need to do an Annex I Part I assessment." | Article 13(2) makes the cybersecurity risk assessment mandatory. The technical documentation must include the assessment under Article 13(4). |
| "Our customers don't ask for a SBOM, so we don't make one." | Annex I Part II (1) requires identification of vulnerabilities and components, including a SBOM in a commonly used machine-readable format. The customer's interest is irrelevant. |
| "Our chatbot is the single point of contact." | Article 13(17) requires the user to be able to choose their preferred means of communication. Means must not be limited to automated tools. |
| "Five years from product launch is plenty for the support period." | Article 13(8) runs the support period from each unit's market placement, not from launch. Units placed in year 4 carry support obligations into year 9. |
| "The 14-day final report deadline applies to incidents too." | No. Vulnerabilities: 14 days after corrective measure available. Severe incidents: one month after the 72h notification (Article 14(2)(c) vs 14(4)(c)). |
| "Our SLA already covers vulnerabilities; we don't need to report to ENISA." | Article 14 reporting is to the CSIRT designated as coordinator and ENISA simultaneously, via the Article 16 single reporting platform. Customer SLAs do not substitute. |
| "We have insurance for breaches." | Administrative fines under Article 64 are not insurable in most Member States. Risk transfer cannot replace compliance. |
| "Article 14 only applies once we have a European entity." | Article 14(7) third subparagraph routes non-EU manufacturers through a CSIRT cascade based on AR, importer, distributor or user location. The reporting duty starts on 11 September 2026 regardless. |
| "We delay public disclosure of every vulnerability until the next quarterly release." | Annex I Part II (4) allows delay only in duly justified cases until users can apply the patch. Routine quarterly batching is not a "duly justified case". |
Frequently Asked Questions
What is a manufacturer under the CRA?
The brand owner. A manufacturer is the entity that develops or commissions a product (including via an outsourced factory) and then markets it under its own name or trademark, paid or free. The brand on the product, not the location of the production line, decides who the manufacturer is. Open-source software stewards are a separate, lighter category; consumer-only resale without a brand is distribution, not manufacturing (Article 3(13); steward regime at Article 3(14)).
Am I a manufacturer or an importer?
It depends on whose brand is on the product. Your own name or trademark on the product makes you the manufacturer, regardless of where the product is built. A non-EU person's brand on a product you place on the Union market makes you the importer. Slap your own brand on a non-EU-built product and you carry the full manufacturer obligation set; keep the original brand and route it through your EU entity, and you carry only the importer verification set (Articles 3(13) and 3(16); manufacturer obligations at Articles 13 and 14; importer obligations at Article 19).
Manufacturer vs authorised representative: what is the difference?
The AR is a paperwork proxy, not a substitute manufacturer. By written mandate, the AR holds the EU DoC and technical documentation at the disposal of market surveillance authorities, answers reasoned requests, and cooperates on enforcement actions. Engineering, risk assessment, vulnerability handling, conformity assessment and series-of-production duties stay with the manufacturer. The AR does not place the product on the market; that act remains with the manufacturer or its importer. Appointing an AR is optional, not mandatory (Articles 3(15) and 18(1)–(3); duties that stay with the manufacturer are listed in Articles 13(1)–(11), 13(12) first subparagraph, and 13(14)).
Are there SME exemptions for manufacturers?
The substantive obligations apply regardless of size. The CRA's only SME-specific concession on penalties protects micro and small enterprises from fines tied specifically to the 24h early-warning deadlines, and nothing else. Open-source software stewards have a broader exemption from administrative fines but are a different category. Authorities must also give due regard to the size of the offender (including SMEs and start-ups) when setting fine amounts in individual cases; that is a sentencing factor across the whole regime, not an obligation exemption (Articles 13 and 14 apply to all sizes; SME concession at Article 64(10)(a) for the 14(2)(a) and 14(4)(a) deadlines; sentencing factor at Article 64(5)(c); broader OSS-steward exemption at Article 3(14) and 64(10)(b)).
When do CRA manufacturer obligations apply?
Two dates. Article 14 vulnerability and incident reporting starts on **11 September 2026**. The rest of the manufacturer regime (Article 13, Annex I, conformity assessment, EU DoC, CE marking, technical documentation) starts on **11 December 2027**. Manufacturers placing products on the EU market need an Article 14 reporting capability in place by September 2026 even if their full Article 13 conformity programme is still being built (Article 71 applicability; Article 14 reporting from 11 September 2026; Articles 13, 30, 31, 32 and Annex I from 11 December 2027).
What is the support period and how is it determined?
At least 5 years, or the expected in-use period if shorter. The manufacturer determines the period taking into account reasonable user expectations, the nature and intended purpose of the product, relevant Union law on product lifetimes, support periods of similar products on the market, the availability of the operating environment, the support periods of integrated third-party components, and ADCO and Commission guidance. The information considered must be included in the technical documentation. The end date (at least month and year) must be disclosed at point of purchase. Once issued, security updates remain available for at least 10 years or the remainder of the support period, whichever is longer (Articles 13(8), 13(9) and 13(19)).
What is the difference between an "actively exploited vulnerability" and a "severe incident" for Article 14?
Different definitions, different final-report deadlines. An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it without permission of the system owner. A severe incident is one that negatively affects (or can affect) the product's ability to protect availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led (or can lead) to introduction or execution of malicious code in the product or a user's network. Both streams use the 24h early warning + 72h notification cadence, but final reports differ: vulnerabilities are reported 14 days after a corrective measure is available, incidents within one month of the 72h notification (actively exploited vulnerability at Article 3(42); severe incident at Article 14(5); deadlines at Article 14(2) and (4)).
Do open-source components in our product affect our manufacturer obligations?
Yes. The manufacturer must exercise due diligence when integrating third-party components, including free and open-source ones not placed on the market commercially. On identifying a vulnerability in a component, the manufacturer reports it to the person or entity maintaining the component and remediates it under Annex I Part II. Where the manufacturer has developed a fix, it shares the relevant code or documentation with the component maintainer where appropriate, in machine-readable format where applicable. The product needs an SBOM covering at least the top-level dependencies. Open-source software stewards are a separate category with their own (lighter) regime (Articles 13(5)–(7); SBOM at Annex I Part II (1); steward category at Article 3(14)).