If your name or trademark is on a product with digital elements placed on the EU market, the Cyber Resilience Act usually treats you as the manufacturer. This page explains the main CRA manufacturer obligations: secure design, technical documentation, conformity assessment, CE marking, support-period duties, vulnerability handling, and mandatory reporting.
Summary
- Are you the manufacturer? You are usually the manufacturer when you develop, manufacture, or commission the product and market it under your own name or trademark. Branding is the decisive test; the supply contract does not move the CRA role by itself.
- What must be ready before market placement? Cybersecurity risk assessment, essential cybersecurity requirements mapping, technical documentation, conformity assessment, EU Declaration of Conformity, CE marking, manufacturer/contact information, and user instructions.
- What continues after market placement? Vulnerability handling, security updates, support-period disclosure, corrective measures, cooperation with market surveillance authorities, and document retention. Security updates remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer.
- What must be reported? Actively exploited vulnerabilities and severe incidents, routed through the ENISA single reporting platform on a 24h / 72h / final-report cadence. The two streams have different final-report deadlines, detailed in the reporting section below.
- When does it apply? Vulnerability and incident reporting starts 11 September 2026; the rest of the manufacturer regime follows. See the implementation timeline below for the full milestone chain.
- Penalty exposure: top-tier infringements can reach EUR 15 000 000 or 2.5% of total worldwide annual turnover, whichever is higher. Micro and small enterprises get narrow relief on the 24h early-warning deadlines only. See penalties and enforcement for the article-by-article fine ladder.
Four numbers that frame manufacturer exposure: 21 essential requirements split across product and process, two reporting deadlines per stream, top-tier fine.
Who Is a Manufacturer under the CRA?
In practical terms, the CRA manufacturer is the brand owner or product maker responsible for placing the product on the market under its name or trademark. The definition covers entities that develop, manufacture, or have a product designed, developed or manufactured, and then market it under their own name or trademark, whether paid, monetised, or free of charge.
Outsourcing does not move the role: if an OEM or contractor builds the product but your name is on it, you are still the manufacturer. If the product is not under your name or trademark, you may instead be an importer, distributor, authorised representative, or substantial modifier. For the full role decision tree, see who must comply with the CRA.
Core Manufacturer Duties
Manufacturer duties group into four clusters: secure design and risk-assessed product properties; vulnerability-handling processes operated across the support period; pre-market artefacts that must exist before placing on the market (technical documentation, conformity assessment, EU DoC, CE marking); and post-market duties (corrective measures, cooperation with market surveillance, support-period disclosure, cessation notice). The table below maps each duty to the specific Article 13 paragraph that anchors it.
| Duty | Key point | Source |
|---|---|---|
| Design and produce against essential requirements | Essential requirements are mandatory, modulated by the cybersecurity risk assessment. | Article 13(1) |
| Cybersecurity risk assessment | Documented, updated across the support period, included in the technical documentation. | Article 13(2) |
| Component due diligence | Includes free and open-source components. Exercise due diligence when integrating components; once aware of a vulnerability in one, document it, report it upstream to the component maintainer, and remediate it in your own product. | Article 13(5), Article 13(6) |
| 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. | Article 13(8) |
| 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. | Article 13(9) |
| Substantially modified software versions | The vulnerability-remediation rule may apply only to the latest version where users have free access to it. Public archives of unsupported versions are allowed with risk warnings. | Article 13(10), Article 13(11) |
| Pre-market technical doc, conformity assessment, CE, and series-of-production controls | Draw up the technical documentation. Carry out the conformity assessment or have it carried out. Draw up the EU DoC and affix CE. Maintain procedures so series production stays compliant. | Article 13(12) |
| 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. | Article 13(13) |
| Product identification + manufacturer identification | Type/batch/serial number. Manufacturer name, trade name or trademark, postal address, digital contact, also reproduced in the information accompanying the product. | Article 13(15), Article 13(16) |
| Single point of contact | Allows users to choose their preferred means of communication. Must not be limited to automated tools. | Article 13(17) |
| User-information accompaniment | Information and instructions in a language easily understood by users and market surveillance, accessible online for the same retention period. | Article 13(18) |
| 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. | Article 13(19) |
| EU DoC delivery | Either full DoC or simplified DoC containing the exact internet address at which the full DoC can be accessed. | Article 13(20) |
| 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. | Article 13(21), Article 13(22) |
| Cessation of operations | Inform market surveillance and, by any means available, the users before cessation takes effect. | Article 13(23) |
| SBOM format + dependency assessments | Commission may specify SBOM format by implementing acts. ADCO may run Union-wide dependency assessments. | Article 13(24), Article 13(25) |
Essential Cybersecurity Requirements
Manufacturers have to satisfy two sets of essential cybersecurity requirements: product-security requirements and vulnerability-handling requirements. The first set governs how the product is designed, developed and produced. The second governs the processes the manufacturer must operate during the support period.
Cybersecurity Risk Assessment
Manufacturers run a cybersecurity risk assessment to figure out which essential cybersecurity requirements bind their specific product. The assessment is documented once and kept current across the support period. It lives inside the technical documentation, and where a requirement is not applicable the assessment carries the written justification.
Product Security Requirements
Before market placement, the product must be designed, developed and produced to provide an appropriate level of cybersecurity based on risk. The manufacturer's cybersecurity risk assessment determines which controls in the list below apply, and where a control is not applicable the technical documentation must include a clear justification.
- (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" wording on several items above is governed by the risk assessment, not by manufacturer preference.
Vulnerability-Handling Requirements
Separately from the product-security controls, the manufacturer must operate vulnerability-handling processes during the support period: component documentation, SBOM, testing, remediation, coordinated vulnerability disclosure, reporting channels, secure update distribution and user advisories.
- (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) Share 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
The vulnerability-handling requirements above apply from market placement through the support period. Security updates remain available for at least 10 years after issuance or for the remainder of the support period, whichever is longer.
Component Due Diligence
Component due diligence applies whether the component is commercial or free and open-source. The manufacturer documents the component vulnerabilities they become aware of, addresses them in their own product, and shares relevant information with the component maintainer (including, where appropriate, the relevant code or documentation in machine-readable format). The documentation surface is the SBOM and the technical-documentation file.
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 | What it contains or requires |
|---|---|
| Technical documentation | Product description, design and development information, the cybersecurity risk assessment, 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. |
| Conformity assessment | Module A self-assessment for default-class products and for Important Class I where harmonised standards, common specifications, or a cybersecurity certification scheme are fully applied. Important Class II uses notified-body routes (Module B+C or H) or a European cybersecurity certification scheme at assurance level at least "substantial". Critical products use a European cybersecurity certification scheme where applicable. Otherwise they use notified-body routes. |
| EU Declaration of Conformity | Either the full DoC supplied with the product or a simplified DoC carrying the exact internet address of the full DoC. The DoC content set: manufacturer name and address, product identification, statement of conformity with the essential cybersecurity requirements, standards applied with reference numbers and dates, notified-body name and number where applicable, certificate reference, date, signature, signatory name and function. |
| CE marking | Affixed visibly, legibly, and indelibly to the product; its height may be lower than 5 mm provided it stays visible and legible. Where the product's nature does not permit, on the packaging and the EU declaration of conformity. Where a notified body is involved in the Module H (full quality assurance) conformity assessment, 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 products; Important Class I where harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least "substantial" exist and are fully applied |
| B + C EU-type examination + production control | Important Class II route. Class I where no relevant harmonised standard, common specification or European cybersecurity certification scheme is applied. Critical products when routed through notified-body assessment. |
| H full quality assurance | Alternative for Important products. Critical products when routed through notified-body assessment. |
See the technical documentation guide, conformity assessment guide, product classification guide, and declaration of conformity guide for the details of each artefact.
Reporting Vulnerabilities and Severe Incidents
Manufacturers have two reporting streams. Both route simultaneously to the CSIRT designated as coordinator and to ENISA via the single reporting platform. The two streams share the 24h/72h cadence but have different final-report deadlines, a frequently-misunderstood point.
The 24-hour early-warning clock applies only to actively exploited vulnerabilities. The severe-incident stream has its own trigger and its own 24h/72h/1-month cadence.
| Stream | 24h early warning | 72h notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability | Within 24h of awareness | Within 72h of awareness | 14 days after a corrective or mitigating measure is available |
| Severe incident | 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 rules (including the fallback cascade for non-EU manufacturers), the user-notification duty, and the single reporting platform mechanics.
Support Period and Post-Market Duties
The headline numbers (5-year minimum support period, 10-year security update availability) appear in the duty-cluster table above. Determination criteria, point-of-purchase end-date disclosure, the EOL-notification duty, and the substantially-modified-software-version rules are covered in the support period cluster guide.
Two manufacturer post-market duties live alongside the support-period regime and do not have their own cluster page. On awareness that the product no longer conforms to the essential cybersecurity requirements, 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. 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 or Substantial Modifier?
Substantial modification is a different route into manufacturer-level obligations. It applies when a third party modifies a product after market placement and makes the modified product available on the market. Article 22 says:
"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."
The substantial-modification regime explicitly excludes manufacturers, importers and distributors. It applies to third parties outside the role chain: system integrators, value-added resellers, enterprise IT departments that modify vendor products before redistribution. Its 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. A "substantial modification" is a change after market placement that affects compliance with the essential cybersecurity requirements or modifies the intended purpose for which the product was assessed.
| Case | Classification |
|---|---|
| Original engineering, original brand | Manufacturer |
| 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 as a substantial modifier. |
| White-label rebrand of a non-EU product by an EU entity | EU entity is the manufacturer via the rebrand bridge for importers and distributors. This is not a third-party substantial-modifier case. If you started as the EU importer, see the importer cluster guide for what changes when you cross into the manufacturer regime. |
| EU integrator bundles compatible products without modifying their internals | Distributor, not substantial modifier. See the distributor cluster guide for the distributor obligation set. |
| Enterprise IT installs a custom firmware build on vendor devices, then resells | Substantial modifier. Treated as manufacturer for the modified product. |
The practical consequence of being caught by the substantial-modification regime: full manufacturer 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 reporting cadence above.
Implementation Timeline
- Past milestone
- Upcoming enforcement
- Final deadline
- Ecosystem milestone
Common Pitfalls
| Claim | Why it fails |
|---|---|
| "We are not really the manufacturer; an OEM in another country builds it." | The brand owner is the manufacturer, regardless of who builds the product. Outsourcing the build does not transfer the obligation. |
| "Our security policy is good enough; we do not need to do an essential-requirements assessment." | The cybersecurity risk assessment is mandatory and must live inside the technical documentation. |
| "Our customers don't ask for a SBOM, so we don't make one." | An SBOM in a commonly used machine-readable format is required, covering at least top-level dependencies. Customer interest is irrelevant. |
| "Our chatbot is the single point of contact." | Users must be able to choose their preferred means of communication. The channel cannot be limited to automated tools. |
| "Five years from product launch is plenty for the support period." | The support period runs from each unit's market placement, not from product launch. Units placed in year 4 carry support obligations into year 9. |
| "The 14-day final report deadline applies to incidents too." | No. Vulnerabilities get 14 days after a corrective measure is available; severe incidents get one month after the 72h notification. |
| "Our SLA already covers vulnerabilities; we don't need to report to ENISA." | Reporting goes to the coordinator CSIRT and ENISA simultaneously, via the single reporting platform. Customer SLAs do not substitute. |
| "We have insurance for breaches." | Administrative fines are not insurable in most Member States. Risk transfer cannot replace compliance. |
| "Reporting only applies once we have a European entity." | Non-EU manufacturers are routed 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." | Delay is allowed only in duly justified cases until users can apply the patch. Routine quarterly batching does not qualify. |
CRA by EU country
The obligations above are the same in every Member State. What changes per country is the institutional chain: which authority enforces, which CSIRT receives your reports, and the language your user-facing documentation must ship in. Several national designations are still being finalised, so each brief flags what is confirmed and what is still expected.
- France: ANSSI as notifying authority, ANFR for market surveillance, reporting through CERT-FR.
- Germany: BSI as combined market surveillance and notifying authority, reporting through CERT-Bund.
- Italy: ACN as the single national authority, with ACCREDIA accreditation.
- Netherlands: NCSC reporting and intended RDI market surveillance.
- Poland: CSIRT NASK routing and PCA accreditation.
- Spain: INCIBE-CERT reporting and the CCN/ENAC notified-body split.
Frequently Asked Questions
What are the main obligations for a manufacturer under the CRA?
Four duty clusters. Vulnerability and incident reporting starts 11 September 2026; the full regime applies 11 December 2027.
- Before placing on the market. Risk assessment, essential cybersecurity requirements design, technical documentation, conformity assessment, EU Declaration of Conformity, CE marking.
- Throughout the support period. Vulnerability handling, SBOM, remediation, coordinated vulnerability disclosure, secure updates. At least five years per unit.
- Single point of contact. Non-automated channel reachable by users.
- Vulnerability and incident reporting. 24-hour, 72-hour and final-report cadence to the coordinator CSIRT and ENISA via the single reporting platform.
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.
Am I a manufacturer or an importer?
Depends on whose brand is on the product.
- Your own brand or trademark on the product. Manufacturer route, regardless of where the product is built. Full obligation set under the manufacturer regime.
- Someone else's brand (non-EU person) on a product you place on the Union market. Importer route. Verification set only.
Manufacturer vs authorised representative: what is the difference?
The AR is a paperwork proxy, not a substitute manufacturer. Appointing one is optional.
- What the AR does, by written mandate. Holds the EU DoC and technical documentation at the disposal of market surveillance, answers reasoned requests, cooperates on enforcement actions.
- What stays with the manufacturer. Engineering, risk assessment, vulnerability handling, conformity assessment, series-of-production duties, and placing the product on the market.
Are there SME exemptions for manufacturers?
Substantive obligations apply regardless of size. No exemption from the duties themselves.
- SME concession, narrow. Micro and small enterprises are exempt from fines tied specifically to the 24-hour early-warning deadlines, and nothing else.
- Sentencing factor. Authorities must give due regard to the size of the offender (including SMEs and start-ups) when setting fine amounts.
- OSS-steward category, separate. Open-source software stewards have a broader exemption from administrative fines but are not SMEs.
When do CRA manufacturer obligations apply?
Two staggered dates.
- Vulnerability and incident reporting. Starts 11 September 2026. Manufacturers placing products on the EU market need 24-hour, 72-hour and final-report capability in place by this date, even if their full conformity programme is still being built.
- The rest of the manufacturer regime. Starts 11 December 2027. Covers the full manufacturer duty set: essential cybersecurity requirements, conformity assessment, EU DoC, CE marking, and technical documentation.
What is the support period and how is it determined?
At least five years from each unit's market placement, or the expected in-use period if shorter.
- How the manufacturer determines the period. Considers reasonable user expectations, the product's nature and intended purpose, Union law on lifetimes, support periods of comparable products, operating-environment availability, integrated third-party component support periods, ADCO guidance, and Commission guidance. The analysis goes into the technical documentation.
- Disclosure at point of purchase. End date in at least month-and-year format.
- Security update availability after the period ends. Each issued security update stays available for at least 10 years after issuance, or for the rest of the support period if longer.
What is the difference between an "actively exploited vulnerability" and a "severe incident"?
Different definitions, different final-report deadlines. Both streams share the 24-hour early warning and 72-hour notification cadence.
- Actively exploited vulnerability. A vulnerability for which there is reliable evidence that a malicious actor has exploited it without permission of the system owner. Final report: 14 days after a corrective or mitigating measure is available.
- Severe incident. Either (a) negatively affects, or can affect, the product's ability to protect availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, OR (b) has led, or can lead, to the introduction or execution of malicious code in the product or in a user's network. Final report: one month after the 72-hour notification.
Do open-source components in our product affect our manufacturer obligations?
Yes. The manufacturer exercises due diligence on every integrated third-party component, including non-commercial open-source ones.
- Vulnerability in a component. Report to the entity maintaining the component and remediate in your own product.
- Sharing fixes upstream. Where the manufacturer has developed a fix, share the relevant code or documentation with the component maintainer where appropriate, in machine-readable format where applicable.
- SBOM coverage. At least the top-level dependencies.
- OSS stewards are a different category. Lighter regime, not the manufacturer regime.