On this page · 15 sections
- What applies on 11 December 2027, and what already applies
- Status check: guidance, reporting platform and notified bodies
- Step 1: confirm scope, product by product
- Step 2: classify against Annex III and Annex IV
- Step 3: choose the conformity route, given where standards really are
- Step 4: build the Annex I Part I security properties
- Step 5: run vulnerability handling as a process, with the SBOM at its core
- Step 6: set and publish the support period
- Step 7: assemble the technical file, declaration and CE marking
- Open-source stewards and open-source components
- Importers, distributors and non-EU makers
- What non-compliance costs
- The 13-month plan to 11 December 2027
- How eCorpIT can help
- References
Summary. The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, entered into force on 10 December 2024 and its main obligations apply from 11 December 2027. Two parts already run: the rules on notifying conformity assessment bodies since 11 June 2026, and Article 14 reporting of actively exploited vulnerabilities and severe incidents since 11 September 2026, through ENISA's Single Reporting Platform (SRP), now on version 1.3. From December 2027, new products with digital elements placed on the EU market need a documented risk assessment, the Annex I security properties, a vulnerability process with a machine-readable SBOM, a support period of at least five years unless expected use is shorter, a technical file, an EU declaration of conformity and the CE marking. Annex III lists 19 Class I and 4 Class II important categories; Annex IV lists 3 critical ones. The catch for Class I makers: on 7 November 2026 no CRA harmonised standard was cited in the Official Journal, and CEN-CENELEC records the first two EN 40000 parts, ratified on 2 November, as not expected to be cited. Without a cited standard, common specification or certification scheme, a Class I product needs a notified body. Fines reach €15 million or 2.5% of worldwide turnover. Our verdict: classify every product now, build to the drafts, and book notified body time early.
About this article. For product and compliance leads at software and connected-device makers, including Indian exporters, selling into the EU. We read Regulation (EU) 2024/2847 as published on 20 November 2024, with its English corrigenda to 17 October 2025 and the amendment made by Regulation (EU) 2025/327, from the EU Publications Office, and checked the Commission's acts and CRA pages, ENISA, CEN-CENELEC, ETSI and named trackers on 7 November 2026. This is general information, not legal advice; confirm your classification and route with EU counsel or a notified body. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
What applies on 11 December 2027, and what already applies
Articles 71 and 69 set the dates and transitional rules; the Commission's implementation page tracks milestones in between.
| Date | What happens | Status on 7 November 2026 |
|---|---|---|
| 10 December 2024 | CRA enters into force | Done |
| 28 November 2025 | Implementing Regulation (EU) 2025/2392 describes the Annex III and IV categories | In force |
| 11 June 2026 | Chapter IV (notification of conformity assessment bodies) applies | Applies |
| 27 July 2026 | First Commission guidance, C(2026) 5252 | Published |
| Q3 2026 | First standardisation deliverables | None cited yet |
| 11 September 2026 | Article 14 reporting applies; ENISA SRP opens | Applies |
| Q4 2026 | Delegated act on presumption of conformity through the EUCC certification scheme | Not adopted yet |
| 11 December 2026 | Member States to strive for enough notified bodies (Article 35(2)) | Target |
| 30 October 2027 | More standardisation deliverables | Planned |
| 11 December 2027 | Main obligations apply, including Article 24 steward duties | Fixed in law |
| 11 June 2028 | Cybersecurity certificates under other EU laws stay valid until then, unless those laws differ | Fixed in law |
Products placed on the market before 11 December 2027 fall under the full CRA only if substantially modified from that date, but Article 14 reporting already covers legacy products too. Our CRA reporting guide covers the 24-hour, 72-hour and final-report clock; this article covers everything else.
Status check: guidance, reporting platform and notified bodies
Guidance. The Commission's non-binding guidance of 27 July 2026 covers scope (including remote data processing and open source), substantial modification, support periods, reporting and risk assessment, with 67 practical examples.
Reporting platform. ENISA calls the SRP launched on 11 September 2026 its initial operating capability, with more functions to follow. Ireland's NCSC says only SRP filings satisfy the legal duty, with an email fallback only when ENISA declares the platform offline.
Notified bodies. Article 35(2) asks Member States to strive for enough notified bodies by 11 December 2026. The Commission's conformity page (31 July 2026) says CRA bodies will appear on NANDO once they exist. One tracker found none listed in September; we could not query NANDO directly. Treat capacity as scarce.
Other acts. Two delegated regulations are in force: the vehicle exclusion in Step 1 and rules on when a CSIRT may delay passing on a notification. The implementation page lists no SBOM format or simplified technical file form for small firms yet (Articles 13(24) and 33(5)).
Step 1: confirm scope, product by product
A product with digital elements is hardware or software, plus its remote data processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That covers apps, desktop software, firmware, routers, cameras, wearables, industrial controllers and separately sold components.
Three questions decide most cases:
- Is it made available on the market? Only supply in the course of a commercial activity counts. The Commission says open-source software its maker does not monetise is not a commercial activity.
- Is the cloud part remote data processing? It is when you designed the backend, or had it designed, and the product cannot perform one of its functions without it. A connected device's companion cloud is in scope; software as a service on its own is not covered as such.
- Is another law exclusive? Delegated Regulation (EU) 2025/1535, for example, excludes products under Regulation (EU) No 168/2013 on two- and three-wheel vehicles and quadricycles, except pedal cycles in category L1e.
Write the answer down per product and version line; that memo opens the technical file.
Step 2: classify against Annex III and Annex IV
Classification follows core functionality, as described in Implementing Regulation (EU) 2025/2392, and integrating a listed component does not pass its class to the host: a news app with an embedded browser is not a browser, and a router with firewall functions is still a router. The routes below come from Article 32 and the annexes, with default examples from the Commission.
| Class | Categories (examples from the annexes) | Conformity route |
|---|---|---|
| Default | Everything else, such as mobile apps, computer games, smart speakers, memory chips | Self-assessment (Module A) allowed |
| Important, Class I (19 categories) | Identity and access management, browsers, password managers, anti-malware, VPNs, SIEM, boot managers, operating systems, routers and switches, chips with security functions, smart home security products, connected toys, wearables | Module A only when cited harmonised standards, common specifications or an EU certification scheme at substantial level are fully applied; otherwise a notified body (Module B plus C, or H) |
| Important, Class II (4 categories) | Hypervisors and container runtimes, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors and microcontrollers | Notified body (B plus C, or H) or an EU certification scheme at substantial level |
| Critical, Annex IV (3 categories) | Hardware devices with security boxes, smart meter gateways and other advanced security devices, smartcards and secure elements | As Class II, unless a delegated act mandates EU certification |
One exception matters for open-source projects with commercial makers: Annex III products that are free and open-source software may self-assess if their technical documentation is public when placed on the market.
A worked classification example
A hypothetical Bengaluru product company with four EU product lines:
| Product | Likely class | What it changes |
|---|---|---|
| Field-service mobile app with a cloud backend | Default; the backend is remote data processing | Module A; the backend's security is in scope |
| Password manager for SMB customers | Class I | Fully applied cited standards to self-assess, or a notified body |
| Wi-Fi router bundled with a home security camera | Class I for both | Same, for two categories |
| Virtual firewall appliance | Class II | Notified body or certification |
One portfolio, three routes; plan the notified body work first. If a product is also a high-risk AI system, Article 12 lets CRA compliance, shown in the declaration, cover the AI Act's cybersecurity requirement; our AI Act high-risk guide covers that side.
Step 3: choose the conformity route, given where standards really are
Harmonised standards give a legal presumption of conformity only once their references are published in the Official Journal. Under standardisation request M/606, adopted as C(2025) 618, CEN, CENELEC and ETSI are drafting 41 standards, horizontal and product-specific.
| Workstream | Standard | Status on 7 November 2026 |
|---|---|---|
| Horizontal: vocabulary | EN 40000-1-1 | Ratified 2 November 2026; no citation expected |
| Horizontal: principles, risk management, lifecycle | EN 40000-1-2 | Ratified 2 November 2026, available 18 November; no citation expected |
| Horizontal: vulnerability handling | prEN 40000-1-3 | Reported under approval; citation expected |
| Horizontal: generic security requirements (most of Annex I Part I) | prEN 40000-1-4 | Reported in drafting |
| ETSI product standards, 15 Class I and 2 Class II | EN 304 617 to 627 and 631 to 636 | Enquiry drafts dated June to August 2026; approval reported to end by mid-November |
| Chips and secure hardware | EN 40001-3 to EN 40004-3 | Reported in approval or enquiry |
| Industrial OT products | EN 50770 series | Reported in drafting |
The first two rows come from CEN-CENELEC's records and the ETSI row from ETSI's draft folder; the rest is reported by the SecureHabits and CRA Evidence trackers. We found no Commission decision citing a CRA harmonised standard in Publications Office records on 7 November 2026. A July 2026 draft amendment would push the 2026 delivery deadlines to the end of October (horizontal) and 31 December (product standards); it was reported unadopted in September.
What to do:
- Default products. Standards are optional. Build to Annex I, use EN 40000-1-2 for risk management and the drafts as checklists.
- Class I products. Run two tracks: build against the drafts in case citations land in time, and hold a notified body slot in case they do not. Watch the Official Journal, not committee news.
- Class II and critical products. Third-party assessment or certification is required anyway; engage a notified body in the first half of 2027.
- EU certification. The EUCC delegated act is planned for late 2026; do not count on it until adopted.
Step 4: build the Annex I Part I security properties
Part I lists what the product must do, applied through your risk assessment; the technical file must justify any requirement treated as not applicable.
| Annex I Part I requirement | Engineering task |
|---|---|
| (2)(a) No known exploitable vulnerabilities at release | Release gate on SCA and SAST findings |
| (2)(b) Secure by default, with reset to original state | Hardened defaults, no default passwords, secure factory reset |
| (2)(c) Security updates, automatic by default with opt-out and postponement | Signed updates, auto-update on, user deferral |
| (2)(d) Protection from unauthorised access, and reporting of it | Authentication, access control, intrusion alerts |
| (2)(e) and (f) Confidentiality and integrity of data, code and configuration | Encryption, signed firmware, integrity checks |
| (2)(g) Data minimisation | Collect only what the intended purpose needs |
| (2)(h) and (i) Availability and limited impact on other networks | Rate limiting, DoS resilience, safe failure modes |
| (2)(j) and (k) Limited attack surface and exploit mitigation | Close unused ports and services, memory-safe choices, ASLR |
| (2)(l) Security logging with user opt-out | Logging of access and changes, with an off switch |
| (2)(m) Secure, permanent deletion of data and settings | Wipe function and secure data transfer |
Step 5: run vulnerability handling as a process, with the SBOM at its core
Part II applies for the whole support period. Its first item requires you to document components, including a software bill of materials in a common machine-readable format covering at least the top-level dependencies. SPDX and CycloneDX are the usual choices. The SBOM goes in the technical file; sharing it with users is optional (Annex II point 9), and market surveillance authorities can request it.
The rest of Part II, in to-do form:
- Fix vulnerabilities without delay, with security fixes separate from feature updates where feasible.
- Test and review security regularly.
- After a fix ships, publish an advisory on the flaw, affected products, impact, severity and remediation.
- Enforce a coordinated vulnerability disclosure policy and publish a reporting contact.
- Distribute updates securely, and security updates automatically where applicable.
- Provide security updates free, with advisories, unless a tailor-made business contract says otherwise.
Article 13 adds due diligence on third-party and open-source components (13(5)), reporting component vulnerabilities to their maintainers with your fix where appropriate (13(6)), and a single point of contact for users that is not limited to automated tools (13(17)).
Step 6: set and publish the support period
Article 13(8) sets a support period of at least five years, or the expected use time if shorter, based on how long users can reasonably expect to use the product. Record the reasoning in the technical file. Then:
- Show the end date, at least month and year, at purchase, and where applicable on the product, packaging or by digital means (Article 13(19)).
- Notify users when support ends, where technically feasible.
- Keep each security update available for 10 years after release or the rest of the support period, whichever is longer (Article 13(9)).
- Keep user information available for 10 years or the support period, whichever is longer (Article 13(18)).
For software sold in successive major versions, Article 13(10) lets you meet the update duty on the latest version only, if earlier users can move to it free of charge without extra hardware or software costs: a pricing decision as much as an engineering one.
Step 7: assemble the technical file, declaration and CE marking
Annex VII sets the minimum technical file: description, intended purpose and relevant software versions; design and architecture; vulnerability handling, including the SBOM, disclosure policy, reporting contact and update distribution; the risk assessment; support period reasoning; standards applied; test reports; and the declaration of conformity.
A simplified declaration may point to the full text online (Annex VI). Products need a type, batch or serial number and the manufacturer's contact details, on the product or, if that is not possible, its packaging or an accompanying document (Article 13(15) and (16)). Software can carry the CE marking on the declaration or its website (Article 30(1)). Keep the file and declaration for at least 10 years or the support period, whichever is longer.
Open-source stewards and open-source components
Open-source software stewards are legal persons, such as foundations, that systematically support open-source software intended for commercial activities. Under Article 24 they need a cybersecurity policy, must cooperate with market surveillance authorities, and must report exploited vulnerabilities and severe incidents to the extent they are involved, which ENISA confirms applies from 11 December 2027. Article 64(10) exempts stewards from administrative fines.
A commercial open-source product carries full manufacturer duties; contributors to projects outside their responsibility are not manufacturers.
Importers, distributors and non-EU makers
Importers must check the manufacturer's conformity assessment, technical file, CE marking, declaration, user information and support end date; distributors check the CE marking, contact details and documents. Either becomes a manufacturer if it sells under its own name or makes a substantial modification (Article 21).
For Indian and other non-EU exporters:
- You are the manufacturer if the product is marketed under your name or trademark. If an EU company sells it under its own brand, it carries the duties and will push the evidence back to you.
- Your EU buyers will audit you. Expect 2027 contracts to ask for the technical file, SBOM and support period.
- An authorised representative is optional but useful. A written mandate lets an EU-established party hold your documentation and cooperate with authorities for you.
If the product also processes Indian users' personal data, align CRA logging and incident processes with your DPDP duties, as our DPDP engineering playbook explains.
What non-compliance costs
The ceilings below are in Article 64.
| Infringement | Maximum administrative fine |
|---|---|
| Annex I essential requirements and Articles 13 and 14 | €15 million or 2.5% of worldwide annual turnover, whichever is higher |
| Other listed obligations, including importers, distributors, declaration, CE marking, technical file and conformity assessment | €10 million or 2%, whichever is higher |
| Incorrect, incomplete or misleading information to notified bodies or authorities | €5 million or 1%, whichever is higher |
Micro and small enterprises cannot be fined for missing a 24-hour early warning, and stewards cannot be fined at all; a 2 July 2025 corrigendum extended the first exemption to the top tier. Member States set national penalty rules, and authorities can order withdrawal or recall.
The 13-month plan to 11 December 2027
| When | To-do |
|---|---|
| November to December 2026 | Inventory products and versions on the EU market; make sure named staff can file on the SRP |
| By January 2027 | Write scope memos; classify against Annex III and IV using Implementing Regulation 2025/2392 |
| By March 2027 | Run Annex I gap assessments; set support periods; adopt the disclosure policy and reporting contact |
| By April 2027 | Generate SBOMs in CI for every build; wire component monitoring to exploitation feeds |
| By June 2027 | Class I, II and critical lines: engage a notified body; Class I: decide whether to wait for citations |
| By September 2027 | Close engineering gaps; finish test reports |
| By October 2027 | Complete technical files, declarations, user information and support dates |
| November 2027 | Review against any standards cited by then; brief importers and distributors |
| 11 December 2027 | Place only conforming, CE-marked products on the market |
Connected machinery also falls under the EU Machinery Regulation from 20 January 2027; one threat model can serve both.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team runs Annex III classification and Annex I gap assessments, sets up SBOM generation and signed update pipelines in CI, and assembles technical files that notified bodies and EU importers can review. Talk to us at /contact-us/.
Last updated: 7 November 2026.
