The short answer: if a product is placed on the EU market and has a direct or indirect data connection, the EU Cyber Resilience Act (CRA) may cover the hardware, software, and components. Reporting obligations have applied since 11 September 2026; full application starts on 11 December 2027. Start with a product inventory and scope assessment, then build vulnerability handling, incident reporting, technical documentation, and a conformity-assessment path. Do not wait until 2027. This is public-source research, not legal advice; scope must be confirmed product by product.
This guide is for Chinese manufacturers exporting connected equipment, industrial controls/gateways, embedded software, standalone software, or digital components to the EU, and for service providers integrating those products. Data cut-off: 25 October 2026. Requirements and implementation may change; verify against the European Commission and the legal text before deciding.
Reporting is already live. Full compliance lands in 2027. CE is not a piece of paper; it is a loop of risk, documentation, vulnerability handling, and reporting.
Which products does the EU CRA cover?
The CRA covers hardware, software, and components placed on the EU market with a direct or indirect data connection; applicability depends on intended purpose, sales model, and exclusions, not just the presence of a chip.
The European Commission defines a “product with digital elements” as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. A direct or indirect logical or physical data connection can bring a product into scope; it is not limited to consumer electronics or “connected devices”.
Not every piece of software is automatically covered. Whether it is placed on the market in the course of commercial activity, whether another EU law excludes it, and whether remote data processing is an inseparable part of the product all affect the analysis. The table below is an initial screen, not a legal or conformity conclusion.
| Product form | Data connection | Possibly in scope | What to verify |
|---|---|---|---|
| Connected industrial equipment, gateways, controllers | Yes, direct or indirect | Likely | Placed on the EU market; other-law exclusions |
| Device firmware / embedded software | Through the device | Likely | Part of a product or placed separately |
| Standalone software, apps, development tools | Network/data connection | Possible | Commercial placement, open source, exclusions |
| Components/modules sold separately | Yes | Possible | Whether placed on the market as a product |
| Remote data processing (cloud/service) | Yes | Depends | Designed by the manufacturer; absence would prevent a product function |
| Products covered by other EU legislation | Yes | May be excluded | Specific exclusion and applicable law |
Editorial screening, not a legal conclusion. Confirm scope against the regulation, intended purpose, sales model, and official guidance.
What is the 2026–2027 timeline?
The CRA entered into force on 10 December 2024; reporting obligations have applied since 11 September 2026, and full application starts on 11 December 2027 — not 2027 as a preparation start date.
Many companies treat the CRA as a 2027 issue, but reporting obligations began on 11 September 2026 and apply to products already placed on the EU market, including products placed before 2027. Even before the main obligations apply, an actively exploited vulnerability or severe incident can start the reporting clock.
| Date | Milestone | What it means for the company |
|---|---|---|
| 10 Dec 2024 | CRA enters into force | Start scope, role, and process preparation |
| 11 Jun 2026 | Conformity-assessment body provisions apply | Notified-body capacity develops |
| 11 Sep 2026 | Vulnerability and severe-incident reporting applies | Contacts, severity triage, and 24/72-hour process must work |
| 11 Dec 2026 | Implementation milestone: Member States notify sufficient conformity-assessment bodies | Watch notified-body coverage; it does not mean every product needs third-party assessment |
| 11 Dec 2027 | Full application | Risk assessment, technical file, conformity assessment, CE/declaration, support period, etc. |
| After 11 Dec 2027 | Existing products and substantial modification | Products placed before 2027 generally apply only after substantial modification; reporting still covers products already on the market |
Dates come from European Commission public pages; 11 Dec 2026 is an implementation milestone, not a universal compliance deadline. Verify the official timeline before deciding.
What obligations do manufacturers have?
Manufacturers must perform a risk assessment, meet essential cybersecurity requirements, prepare technical documentation, complete conformity assessment, CE-mark/declare, state a support period, and handle vulnerabilities and reports.
The main CRA obligations fall on the manufacturer that places the product on the EU market under its name or trademark. Even if production is outsourced, you may still be the manufacturer if you sell under your brand. Third-party components require due diligence; responsibility cannot be shifted entirely to suppliers.
| Stage | Obligation | Verifiable evidence |
|---|---|---|
| Design and development | Risk assessment; secure-by-default, access control, cryptography, updates, and other essential requirements | Risk analysis, architecture/data flow, design decisions |
| Components and supply chain | Due diligence on third-party components to avoid uncontrolled risk | Component/dependency list, versions, vulnerability records |
| Before placing on the market | Technical documentation, conformity assessment, EU declaration, CE marking | Technical file, assessment record, declaration |
| User information | Secure installation/use instructions, support-period end date, manufacturer contact | Instructions, packaging/website information |
| After placement | Handle vulnerabilities during the support period; report actively exploited vulnerabilities and severe incidents | Vulnerability tickets, patch records, report receipts |
| Market surveillance | Keep the technical file, cooperate with authorities, correct/recall when needed | Document index, contacts, corrective-action log |
A summary of obligations, not the full legal text. Specific technical and documentation requirements follow the CRA annexes and Commission guidance.
Why do important/critical products need third-party assessment?
Default products can self-assess; important/critical products follow Annex III/IV, with conditional self-assessment for class I and third-party assessment for class II/critical products.
The CRA is not one certification for every product. Most default products can use an internal-control self-assessment; products listed as important or critical follow stricter routes. Important class I products may self-assess where harmonised standards, common specifications, or EU cybersecurity certification are used; otherwise a notified body is needed. Class II and critical products generally require third-party assessment or applicable EU certification.
| Category | Typical route | Key condition | What to prepare |
|---|---|---|---|
| Default product | Internal control / self-assessment | Meet essential requirements and keep technical documentation | Risk assessment, testing, documentation, declaration |
| Important class I | Self-assessment or notified body | Whether harmonised standards/common specifications/certification are applied | Standards evidence or third-party report |
| Important class II | Notified-body assessment | Product category falls under Annex III | Technical file, assessment scheduling, remediation |
| Critical product | Notified body / EU certification | Product category falls under Annex IV | Stricter testing, supply-chain and ongoing monitoring |
Categories and routes follow CRA Annexes III/IV and implementing rules; this table does not replace classification. Not every “industrial software” product is automatically important or critical.
How do vulnerability and incident reporting work?
Report through ENISA’s single reporting platform to the CSIRT of the main establishment: 24-hour early warning, 72-hour notification, final report 14 days after a fix for vulnerabilities, and within one month for severe incidents.
Reporting is not just “tell the customer” or “email the importer”. The manufacturer submits through ENISA’s CRA Single Reporting Platform; the receiving CSIRT is in the Member State of the main establishment, with information normally shared with ENISA and then distributed to CSIRTs in other Member States where the product is available.
| Step | Deadline | Content/action |
|---|---|---|
| Early warning | Within 24 hours of awareness | Flag the actively exploited vulnerability or severe incident and open a report |
| Full notification | Within 72 hours | Add impact, product, versions, and available handling information |
| Final vulnerability report | Within 14 days after a corrective/mitigating measure is available | Root cause, fix, impact, and prevention measures |
| Final severe-incident report | Within one month of the 72-hour notification | Root cause, impact, response, and next steps |
Reporting has applied since 11 Sep 2026 and covers products already placed on the EU market, including those before 2027. Fields and process follow ENISA and Commission guidance.
What should the technical file and evidence chain contain?
The technical file must explain risks, design, components, vulnerability handling, testing, support period, and user instructions; it is an auditable evidence chain, not a single CE certificate.
- Product and versions: model, firmware/software version, intended purpose, data flows, and connection method.
- Risk assessment: threats, attack surface, assets, treatment, and residual risk.
- Essential-requirements mapping: how secure defaults, access control, cryptography, integrity, and updates are met.
- Components and dependencies: third-party/open-source versions, sources, vulnerability status, and update policy.
- Testing and validation: functional/security tests, vulnerability scans, penetration testing where applicable, and fix verification.
- Support and vulnerability handling: support end date, patch cadence, disclosure policy, and contacts.
- User information: secure installation, configuration, updating, and decommissioning in a language users and authorities can understand.
- Conformity evidence: assessment route, EU declaration, CE marking, and notified-body report where applicable.
How should supply-chain roles be divided?
Non-EU manufacturers must define roles with the EU importer/authorised representative/distributor; importers and distributors have verification duties and cannot push all compliance onto the Chinese factory.
CRA duties are distributed across manufacturers, importers, distributors, and an optional authorised representative. The importer is the EU entity placing a non-EU product on the market and carrying verification duties; distributors check CE marking, user information, and contact details. Even without an EU establishment, the Chinese manufacturer must agree with its EU partners on who reports, who keeps documents, and who talks to market surveillance.
- Manufacturer: primary responsibility for design, risk assessment, technical documentation, vulnerability handling, and reporting.
- Importer: verify that the manufacturer has completed the relevant obligations, technical documentation, and CE marking; keep necessary information.
- Distributor: verify CE, user information, and support period; stop supply and inform upstream when issues arise.
- Authorised representative: may perform some tasks under a written mandate; whether one is required depends on the sales model.
What should we do now?
Start with a product inventory and scope assessment, then build vulnerability/incident processes and documentation; reporting is already live, so make contacts, severity triage, and the 24/72-hour flow work first.
Do not start by buying a “CRA template”. List every product sold or planned for the EU, its versions, data connections, components, and EU partners; then classify it and choose an assessment route. Reporting is already live, so incident response and vulnerability handling should come before marketing materials.
| Budget/people category | What to do | Cost driver | Frequently missed |
|---|---|---|---|
| Product inventory and scope | Model/version/data-flow/EU sales inventory | Product count, variants, channels | Only listing finished devices; missing components/software |
| Risk and gap assessment | Threat modelling, essential-requirements mapping, remediation list | System complexity, current security maturity | Treating a compliance template as a risk analysis |
| Secure design and testing | Secure defaults, permissions, cryptography, updates, testing/pen testing | Product count, test scope, external lab | One pre-launch test only |
| Technical file and declaration | Technical documentation, user information, support period, EU declaration | Documentation base, version control, languages | Documents drift from product versions |
| Conformity assessment | Self-assessment or notified-body assessment | Product category, notified-body lead time, remediation rounds | Underestimating scheduling and remediation |
| Vulnerability handling and reporting | PSIRT/contacts, 24/72-hour process, platform submission | Installed base, incident frequency, on-call capacity | Only a customer-service mailbox, no security contact |
| Post-market maintenance | Patches, support period, component updates, market-surveillance cooperation | Support years, versions, supply chain | No budget for long-term maintenance |
No universal prices: product count, category, current security baseline, notified-body scheduling, and languages vary widely. The budget is an editorial framework, not a quote; CE certification and legal responsibility require qualified bodies/lawyers.
Is Lingyi a fit?
For software asset inventories, permissions/logs, incident processes, technical-documentation support, and private deployment, Lingyi can assist; CE certification and legal opinions require notified bodies and lawyers.
Lingyi is not a notified body and does not issue CE certificates or legal opinions. We can help map software/device data flows and assets, improve permissions, logging, audit and incident-response processes, support the software parts of the technical file, and manage versions/updates in private or internal deployments. Formal classification, conformity assessment, and market access must be confirmed by qualified bodies.
Related reading: EU AI Act for manufacturers, agent regulation and compliance, private AI deployment cost, and manufacturing export websites.
FAQ
These questions come from export manufacturers and software teams; answers use European Commission public materials, not legal advice.
Does the CRA apply only to hardware?
No. It covers hardware, software, and components that are placed on the EU market as products with digital elements and have a direct or indirect data connection. Applicability still depends on the sales model, intended purpose, and exclusions.
Can we wait until 2027?
No. Reporting has applied since 11 September 2026 and covers products already placed on the EU market; the other main obligations apply from 11 December 2027. Products placed before 2027 generally apply only after substantial modification, but reporting may still apply.
We only export software or SaaS. Are we covered?
Possibly. Standalone software, apps, components, and remote data processing can fall in scope; whether it is commercial placement and whether remote processing is manufacturer-designed and essential to a product function must be assessed case by case.
Does every product need a notified body?
No. Default products can generally self-assess; important class I products may self-assess where harmonised standards/common specifications/certification are used; class II and critical products generally require a notified body or applicable EU certification.
Who receives a vulnerability report?
Submit through ENISA’s CRA Single Reporting Platform; the receiving CSIRT is in the Member State of the main establishment, with information normally shared with ENISA and relevant Member State CSIRTs. It is not only a customer or importer notice.
How do CRA, the AI Act, and NIS2 relate?
They have different scopes and objectives and may overlap for the same product or service. The CRA addresses product cybersecurity, the AI Act addresses AI risk and compliance, and NIS2 addresses the cybersecurity of critical/important entities. One does not replace another; assess each product and entity separately.
Sources, method, and limits
This is public-source research and editorial synthesis, without a product-specific classification, conformity assessment, or legal review. Sources are the European Commission CRA pages, the legislative summary, and the implementation timeline; dates and requirements are subject to the official texts. CRA guidance, standards, and notified-body capacity are still developing, so re-check before deciding.
- European Commission, Cyber Resilience Act (last updated 7 Sep 2026): official page.
- European Commission, Cyber Resilience Act — Manufacturers (last updated 14 Aug 2026): official page.
- European Commission, Cyber Resilience Act — Reporting obligations (last updated 11 Sep 2026): official page.
- European Commission, The Cyber Resilience Act — Summary of the legislative text (last updated 3 Dec 2025): official summary.
- European Commission, Cyber Resilience Act — Implementation (last updated 27 Jul 2026): implementation timeline.
The Chinese version is at 欧盟 CRA 制造业准备清单.