The EU Cyber Resilience Act for Software Teams: What to Do Before December 2027
EU Cyber Resilience Act factsheet
| Field | Value |
|---|---|
| Regulation | Regulation (EU) 2024/2847, the EU Cyber Resilience Act, in force since December 10, 2024 |
| Reporting duty | Article 14 applies from September 11, 2026, to in-scope products placed on the Union market before or after that date under Article 69(3) |
| Full application | Annex I, conformity assessment, CE marking, market surveillance and penalties apply from December 11, 2027 under Article 71(2) |
| Who it binds | Manufacturers of products with digital elements made available on the Union market in the course of a commercial activity; importers and distributors have narrower duties |
| Scope | Products with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, together with qualifying remote data processing solutions |
| Out of scope | Free and open-source software supplied outside a commercial activity, plus the exclusions in Article 2(2) to 2(4) |
| Maximum fines | Up to EUR 15 million or 2.5% of worldwide annual turnover for Annex I and Articles 13 and 14; EUR 10 million or 2% for the Article 64(3) list; EUR 5 million or 1% for incorrect, incomplete or misleading information |
| Standards status | No EU CRA harmonized standard was cited in the Official Journal as of September 25, 2026 |
| Last verified | September 25, 2026 |
The EU Cyber Resilience Act (EU CRA, Regulation (EU) 2024/2847) has two operational deadlines, and confusing them creates two different compliance failures. Article 14 reporting applies from September 11, 2026, to in-scope products placed on the Union market before or after that date. Most of the regulation applies from December 11, 2027, including secure-by-design requirements, conformity assessment, technical documentation, and CE marking. For products placed on the market earlier, those requirements apply if the product is substantially modified from that date.
This guide is for security engineering, product security, PSIRT, and security leaders at software companies with mixed portfolios. It covers scope and class per product, Annex I in engineering terms, the evidence file, and the order in which to build the program. The EU CRA 24-hour reporting runbook covers filing mechanics, while the Cyber Resilience Act (EU CRA) glossary entry defines the main terms.
This is engineering guidance, not legal advice. The binding law is Regulation (EU) 2024/2847. Commission guidance C(2026) 5252 and the Commission CRA FAQ are non-binding interpretive aids.
Latest EU Cyber Resilience Act updates
Newest first, verified through September 25, 2026.
- September 11, 2026. Article 14 reporting applies. Manufacturers now file early warnings, notifications and final reports through ENISA’s Single Reporting Platform.
- September 4, 2026. The Commission issues version 1.4 of its CRA implementation FAQ. ENISA’s list of coordinator CSIRTs for Article 14 reports appears in early September and was last updated on September 10.
- September 3, 2026. The Commission implementation tracker still lists the Q4 2026 EUCC delegated act and the December 11, 2026, sufficient-notified-bodies objective as future milestones. No EU CRA harmonized standard is cited in the Official Journal.
- August 30, 2026. The original M/606 date for the horizontal principles and vulnerability-handling standards passes without a cited harmonized standard. A reported draft amendment would move the dates, but it was not adopted at the verification date. The independent state-of-play tracker follows the standardization schedule.
- August 13, 2026. ETSI opens public enquiry on 17 draft European Standards for Annex III categories, including operating systems, browsers, SIEM, hypervisors and firewalls. These drafts are not harmonized standards.
- July 27, 2026. The Commission publishes C(2026) 5252, with worked examples on scope, remote data processing, free and open-source software, substantial modification and the support period.
Standards, guidance and conformity-assessment capacity can change quickly. The legal application dates do not. Each entry links to its source so you can check the current status.
What the EU Cyber Resilience Act is, in one screen
The EU CRA is Union product-compliance legislation. It applies conformity assessment, technical documentation, an EU declaration of conformity, CE (Conformité Européenne, which is French for European Conformity) marking and market surveillance to products with digital elements, including software placed on the market on its own. The manufacturer must show conformity with Annex I and handle vulnerabilities throughout the support period.
NIS2 regulates organizations and the services they operate; the EU CRA regulates products and the manufacturers that place them on the market. A CRA notification, a NIS2 incident report and a GDPR breach notice based on the same event should be drafted from one incident record, so the factual account and timestamps agree.
The manufacturer is the natural or legal person that develops or manufactures a product with digital elements, or has it designed, developed or manufactured, and markets it under its own name or trademark. An authorized representative under Article 18 can perform specified tasks but does not take over the manufacturer’s core Article 13 or Article 14 duties.
The legal test is the Union market, not the location of any user who can reach a service. A non-EU company can be in scope through a distance-sales offer targeted at Union customers. The phrase “sold into the EU” is too imprecise for a classification memo.
Key terms and acronyms
| Term | Meaning |
|---|---|
| Actively exploited vulnerability | A vulnerability with reliable evidence that a malicious actor has exploited it in a system without the owner’s permission (Article 3(42)). Article 14 reporting starts when the manufacturer becomes aware of one in its product. |
| CE marking | Short for Conformité Européenne, French for European Conformity. The manufacturer affixes it after a positive conformity assessment to show it takes responsibility for the product’s conformity. |
| Conformity assessment | The procedure that shows a product meets Annex I. Module A is the manufacturer’s internal control. Module B followed by C, and Module H, involve a notified body. |
| CSIRT | Computer security incident response team. The national CSIRT designated as coordinator receives Article 14 reports together with ENISA. |
| CVD | Coordinated vulnerability disclosure: a process for receiving and handling vulnerability reports in coordination with the reporter. Annex I Part II point 5 requires a CVD policy. |
| EDR | Endpoint detection and response software, which monitors hosts for attacks and malware. |
| ENISA | The EU Agency for Cybersecurity. It runs the Single Reporting Platform. |
| EUCC | The EU cybersecurity certification scheme based on Common Criteria, adopted under the Cybersecurity Act. |
| GRC | Governance, risk and compliance: the team or function that owns policy, evidence and audits. |
| Harmonized standard | A European standard written at the Commission’s request. When it is cited in the Official Journal and correctly applied to the relevant requirements, it gives a presumption of conformity under Article 27. |
| NANDO | The Commission’s public database of notified bodies. |
| NIS2 | Directive (EU) 2022/2555, which sets cybersecurity duties for organizations and the services they run. |
| Notified body | A conformity-assessment body that a Member State has notified to carry out third-party assessment under the EU CRA. |
| prEN | A draft European Standard (EN) that is still going through approval. |
| PSIRT | Product security incident response team: the team that receives, triages and responds to vulnerabilities in a company’s products. |
| SBOM | Software bill of materials: a formal record of the components in a product’s software and their supply-chain relationships (Article 3(39)). Annex I requires it in a machine-readable format. |
| SKU | Stock keeping unit: an internal identifier for a product or edition. This guide runs the scope and class decision per SKU so nothing is missed; SKUs that are the same product can share one assessment. |
| SRP | ENISA’s Single Reporting Platform, the channel for Article 14 reports. |
| Substantial modification | A change after placement that affects compliance with Annex I Part I or changes the intended purpose the product was assessed for (Article 3(30)). |
| VEX | Vulnerability Exploitability eXchange: a statement of whether a product is affected by a known vulnerability. |
| Vulnerability handling | The Annex I Part II processes a manufacturer runs for the whole support period. |
Is your product in scope, and which class?
Run the decision for each SKU, not for the company as a whole. A browser-only SaaS service that is not the remote data processing solution of a product with digital elements is generally not itself a product with digital elements. A downloadable client, browser extension, on-premises installation or SDK can be in scope when it is separately made available on the Union market in the course of commercial activity.
A remote service falls within the product only when the manufacturer controls its development, and a product function would fail without it. A third-party cloud dependency is not automatically in scope. The planned EU CRA SaaS scope guide takes that function test further.
For each SKU, record the manufacturer, operator role, release channel, placement date, intended use, local and remote components, core functionality, and proposed class. High-risk AI systems and EHR systems follow special conformity rules.
Selected software categories and conformity routes
The descriptions below are selected examples. The binding category text and technical descriptions appear in Implementing Regulation (EU) 2025/2392.
| Class | Selected software categories | Conformity route | Practical implication |
|---|---|---|---|
| Default | Products not listed in Annex III or IV and not subject to a special rule, including many business applications, thick clients, SDKs and developer tools | Any Article 32(1) procedure: Module A, Module B followed by C, or Module H | Module A still requires the Article 13(2) risk assessment, Annex VII technical file, Annex V declaration and CE marking |
| Important Class I | Identity and privileged-access management, browsers, password managers, anti-malware, VPN, network management, SIEM, boot managers, PKI, network interfaces and operating systems | Module A only where an applicable Article 32(2) instrument is fully applied; otherwise, Module B followed by C, or Module H | Without a cited applicable instrument, proprietary Class I products need a third-party route for uncovered requirements |
| Important Class II | Hypervisors and container runtime systems; firewalls and intrusion detection or prevention systems | Module B followed by C, Module H, or an applicable Article 27(9) scheme at assurance level substantial or higher | Module A is unavailable for proprietary Class II products |
| Critical | Hardware devices with security boxes, smart-meter gateways and specified advanced-security devices | Article 32(4), read with Article 8 | Almost never the route for a pure software company |
Class follows core functionality, not marketing language, and not every embedded component. Embedding a firewall does not turn an ordinary business application into a firewall. Selling a product whose core function is network traffic control may.
A worked mixed portfolio
This illustrative portfolio shows why one company-level answer is not enough. Legal should approve the final determination for each real product.
| Illustrative SKU | Initial scope view | Likely class or route | Decision evidence to retain |
|---|---|---|---|
| Browser-only analytics SaaS | Generally outside product scope unless it is a required remote data processing solution for another product | No class until a qualifying product connection is established | Architecture, delivery model and function-dependency memo |
| Downloadable desktop client | Potentially in scope when commercially made available on the Union market | Default unless core functionality matches Annex III or IV | Distribution channel, placement date and functionality analysis |
| Browser extension | Potentially in scope as separately supplied software | Default or Class I if its core function matches a listed category | Store listing, intended purpose and class memo |
| Customer-installed SDK | Potentially in scope when made available as a product in commercial activity | Usually default | License, distribution terms, supported versions and risk assessment |
| Host-based EDR agent | In scope where commercially made available | Class II if core functionality is host-based intrusion detection; Class I if primarily anti-malware | Mapping to the technical description, product documentation and legal approval |
| Required cloud control plane | In scope as part of the product only if the manufacturer controls its development and a product function fails without it | Follows the product and its core functionality | Responsibility, dependency and failure-mode evidence |
EDR is difficult because the label is not a category. Host-based intrusion detection matches Class II item 2, while software focused on finding, removing or quarantining malware can match Class I item 4. Record the technical description the product satisfies and why.
The deadlines, and what placed on the market means
| Date | What applies | Which products |
|---|---|---|
| June 11, 2026 | Chapter IV provisions on notifying authorities and conformity-assessment bodies, except Article 35(1) | Institutional provisions; Article 35(2) sets a Member State objective for sufficient notified bodies by December 11, 2026 |
| September 11, 2026 | Article 14 reporting of actively exploited vulnerabilities and severe incidents | In-scope products placed on the Union market before or after that date under Article 69(3) |
| December 11, 2027 | Annex I, Article 13 manufacturer duties, conformity assessment, CE marking, technical documentation, market surveillance and penalties | Each product placed on the market on or after that date, plus earlier products that are substantially modified |
“Placed on the market” means the first supply of an individual product on the Union market; “made available” covers each later supply. December 2027 is when a newly placed product must already conform, not when work begins. An earlier product enters the full regime if it is substantially modified, so product lines are not grandfathered as a group.
Article 64 establishes three maximum administrative-fine tiers. Non-compliance with Annex I or Articles 13 and 14 can reach EUR 15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. The infringements listed in Article 64(3) can reach EUR 10 million or 2%, while incorrect, incomplete or misleading information to notified bodies or market-surveillance authorities can reach EUR 5 million or 1%. Article 64(10) contains narrow derogations for certain missed 24-hour deadlines by micro and small enterprises and for open-source software stewards; the reporting duties themselves remain.
What Annex I requires from engineering
Annex I Part I point 1 applies generally. Points 2(a) through 2(m) apply based on the Article 13(2) risk assessment and where applicable. Threat modeling can support that assessment, but it does not replace the per-product risk assessment or the requirement-by-requirement rationale.
Point 2(a) requires products to be made available without known exploitable vulnerabilities. It does not require the absence of every vulnerability. The planned known exploitable vulnerabilities guide addresses the evidence needed for that judgment.
Annex I Part I engineering map
| Requirement | Engineering task | Evidence artifact |
|---|---|---|
| Point 1: cybersecurity appropriate to the risks | Complete the Article 13(2) risk assessment for each product and determine which requirements apply | Approved risk assessment and applicability matrix |
| 2(a): no known exploitable vulnerabilities when made available | Triage known vulnerabilities in the product and its components before every release | Version-linked triage record and release-gate approval |
| 2(b): secure by default and resettable | Define, implement and test a hardened default state and restoration path | Configuration specification and reset test results |
| 2(c): security updates, automatic by default where applicable | Maintain a secure update mechanism with user controls for opt-out and postponement where required | Update design, user-interface record and update tests |
| 2(d): access control and unauthorized-access reporting | Design authentication, authorization, detection and notification | Access-control model, misuse tests and alert evidence |
| 2(e): confidentiality at rest and in transit | Inventory cryptography and manage keys and transport security | Cryptographic inventory, key-management standard and test results |
| 2(f): integrity of data, commands, programs and configuration | Apply signing, integrity checks and tamper detection | Signing design, verification logs and tamper tests |
| 2(g): data minimization | Tie collected data to the intended product purpose and remove unnecessary collection | Data inventory and approved minimization review |
| 2(h): availability after an incident, including DoS resilience | Design and test resilience, recovery and rate limiting | Availability test plan, results and recovery evidence |
| 2(i): minimize negative effects on other devices or networks | Review outbound traffic, resource use and failure behavior | Network-behavior analysis and abuse-case tests |
| 2(j): limit attack surfaces and external interfaces | Maintain an interface inventory and disable unused services and ports | Versioned interface inventory and hardening evidence |
| 2(k): reduce exploitation impact | Apply memory-safety measures, sandboxing and privilege separation where appropriate | Architecture decision records and mitigation tests |
| 2(l): record relevant internal activity with user control | Implement security logging and the required user-controlled opt-out | Logging specification, sample records and opt-out tests |
| 2(m): secure deletion and transfer of data and settings | Build and test deletion and export paths | Deletion, export and residual-data test results |
Annex I Part II vulnerability handling map
Part II runs for the support period and covers the whole product, including integrated third-party and open-source components. The planned continuous vulnerability-handling guide develops the lifecycle.
| Requirement | Engineering task | Evidence artifact |
|---|---|---|
| 1: identify and document vulnerabilities and components, including a machine-readable SBOM | Generate a version-linked component inventory from the resolved build | SBOM, build provenance and component inventory per release |
| 2: remediate without delay; separate security updates where technically feasible | Maintain patch pipelines across every supported version | Remediation records, release evidence and version-coverage matrix |
| 3: regular and effective security testing and review | Run a scheduled testing program based on product risk | Test plan, reports, findings and closure records |
| 4: disclose fixed vulnerabilities, subject to the narrow overriding-risk exception | Publish advisories when updates become available | Advisory, publication approval and exception record if used |
| 5: coordinated vulnerability disclosure policy | Operate a public intake, triage and response process | Published CVD policy, case records and response metrics |
| 6: contact and information sharing, including third-party components | Maintain one monitored security contact and supplier communication paths | Contact record and upstream or downstream notices |
| 7: secure update distribution, automatic where applicable | Sign updates and verify integrity before installation | Signing logs, channel tests and integrity-verification evidence |
| 8: security updates free of charge, with advisory messages | Keep security fixes outside paid upgrade gates | Product policy, license terms and release notices |
The exceptions to secure-by-default configuration and free security updates are limited to an agreement between the manufacturer and a business user for a tailor-made product. They are not general enterprise-contract opt-outs.
The timeline from September 2026 to December 2027
Each phase ends with an observable exit condition, not a percentage-complete status.
| Phase | Months | External date | Work | Exit criterion |
|---|---|---|---|---|
| 1 | Sep to Oct 2026 | Article 14 applies from Sep 11, 2026 | Launch the reporting runbook; create the portfolio register; determine manufacturer, channel, scope and draft class per SKU | Every SKU has a named owner, scope record and draft class; the reporting roster can file |
| 2 | Nov 2026 to Jan 2027 | Dec 11, 2026, notified-body objective | Approve class and route; decide support periods; create the Annex VII file skeleton; publish the CVD policy; prepare supplier and assessment packages | Every SKU has an approved class, route, support period and evidence owner |
| 3 | Feb to Jul 2027 | Check Official Journal citations monthly | Close Annex I gaps; generate SBOMs from resolved builds; implement update retention, Annex II information and substantial-modification controls | The evidence index is complete against Annex VII and refresh triggers are working |
| 4 | Aug to Dec 2027 | Oct 30, 2027, standards milestone; Dec 11, 2027, full application | Complete conformity assessment; sign the Annex V declaration; place the CE marking; enforce the release gate | No product can be placed on the market without an approved file, declaration, Annex II information and marking |
CE marking, the declaration and the technical file
CE marking on software is real. Article 30(1) allows the manufacturer to affix it to the EU declaration of conformity or to an easily and directly accessible section of the website accompanying the software. A general corporate page is not enough. The marking goes on before the product is placed on the market and only after a conformity assessment produces a positive result. Under Module H, the notified body’s identification number follows the marking.
The declaration follows Annex V. A simplified Annex VI declaration can accompany the product and direct the user to the full version. Technical documentation follows Annex VII and is kept current under Article 31(2). It is provided to market-surveillance authorities and, under Modules B and H, the notified body; there is no general duty to publish it. The technical file and declaration must be retained for at least 10 years after placement or for the support period, whichever is longer. The planned December 2027 checklist covers the Annex II, Annex V and Annex VII mechanics.
The support period and the 10-year update rule
The support period reflects expected use and is at least five years unless expected use is shorter. It may need to be longer. The manufacturer tells users the end month and year at purchase.
Each security update must remain available for at least 10 years after issue, or for the remaining support period, whichever is longer. Binaries, signing infrastructure, advisories and evidence therefore need an owner and budget.
For later substantially modified versions, Article 13(10) permits remediation through the latest version only when earlier users can move free of charge and without added hardware or software costs. Otherwise, older versions retain their own remediation duty.
SBOM under the EU CRA
Annex I Part II point 1 requires a machine-readable software bill of materials in a commonly used format covering at least top-level dependencies. It belongs in the Annex VII technical documentation; providing it to users is optional under Annex II point 9. The planned EU CRA SBOM guide addresses formats, depth and supplier inputs.
The SBOM should be generated from the resolved build and tied to a released version. Supplier SBOMs and vulnerability notices feed the manufacturer’s inventory, but they do not replace the manufacturer’s own record. As of September 3, 2026, no Commission implementing act specifies the SBOM format or depth. BSI TR-03183 Part 2 offers a useful mapping to SPDX and CycloneDX but is not binding.
Vulnerability Exploitability eXchange, or VEX, can record whether a product is affected, not affected, fixed or still under investigation for a known vulnerability. VEX is useful evidence for prioritization and supplier communication, but the EU CRA does not require it as a filing format and a VEX statement is only as reliable as the analysis behind it.
Reporting: the clock is running
From September 11, 2026, a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident affecting an in-scope product must submit an early warning without undue delay and within 24 hours, a fuller notification without undue delay and within 72 hours of the same awareness time, and a final report within 14 days after a corrective or mitigating measure becomes available for a vulnerability or within one month after the notification for a severe incident. Filings go through the ENISA Single Reporting Platform hub to the coordinator CSIRT and ENISA; the ENISA SRP FAQ covers current platform use. The detailed runbook explains awareness, evidence, ownership and the three clocks; a CVE or proof of concept alone is not reliable evidence of real-world malicious exploitation.
Harmonized standards may arrive late, but the application date is fixed
Standardization request M/606 is Commission Implementing Decision C(2025) 618. The horizontal product-security requirements in prEN 40000-1-4 were scheduled for October 30, 2027. The ENISA Secure by Design and Default Playbook can help teams translate the principles into repeatable engineering actions, but it is guidance rather than a harmonized standard.
Article 27 creates a presumption of conformity only when the relevant harmonized standard has been cited in the Official Journal and applied as required. Publication of a draft or adoption of an EN is not enough by itself. Nothing in Article 71(2) makes December 11, 2027, conditional on the standards program. A current EUCC certificate also does not satisfy Article 27 or Article 32 unless a CRA act specifies the scheme as applicable.
The plan differs by product class:
- Default products. Assess directly against Annex I, document the engineering measures and retain the evidence.
- Class I and Class II products. Identify candidate conformity-assessment bodies now and use only a body notified for the relevant EU CRA scope. Check NANDO and the Official Journal monthly.
- Contingency. Decide which releases can proceed under Module A, which require a third-party route and which must pause if an applicable route is not available.
The 15-month build order
Treat the EU CRA as a product program with an executive sponsor. The main dependencies are portfolio ownership, classification, supplier information, version-linked evidence, and assessment capacity.
| Workstream | Prepares | Approves | Due | Exit criterion |
|---|---|---|---|---|
| Program ownership and budget | CISO | Executive sponsor | Sep 2026 | Charter names the owner, budget and phase gates |
| Article 14 runbook, filers, CVD policy and contact | PSIRT | Legal | Before Sep 11, 2026 | Roster, escalation path, shared record and published contact are operational |
| Portfolio register and release-channel map | Product security | Legal | Oct 2026 | Every SKU records manufacturer, operator, channel and placement logic |
| Classification memo per SKU | Product security | Legal or product compliance | Oct 2026 | Signed memo identifies scope, class, route and unresolved questions |
| Support-period decision | Product with legal and finance | Legal and product leadership | Dec 2026 | Each SKU has an approved end month and year with cost assumptions |
| Supplier governance | Procurement and product security | Legal | Dec 2026 | Contracts and intake require component data, notices and due diligence |
| Conformity-assessment procurement | GRC and product security | CISO | Dec 2026 | Each Class I and II SKU has a candidate route, body and contingency |
| Article 13(2) risk assessment and Annex I gap plan | Engineering and product security | CISO | Jan 2027 | Applicability matrix is approved and every gap has an owner and due date |
| Substantial-modification control | Engineering and legal | Legal | Q1 2027 | Release process invokes reassessment on documented triggers |
| Continuous vulnerability handling and per-release SBOM | Product security and engineering | PSIRT lead | Q1 2027 | Supported-version matrix, SBOM and case workflow operate on every release |
| Update hosting and evidence retention | Engineering and IT | Finance | Q2 2027 | Ten-year retention design has an owner, capacity and funded cost model |
| Annex VII evidence index and Annex II information | GRC | Product compliance or legal | Q3 2027 | Every required item has a current artifact and refresh trigger |
| Conformity assessment, declaration and CE marking | Product security and GRC | Authorized manufacturer signatory | Q3 to Q4 2027 | Positive assessment, signed declaration and approved marking location are recorded |
| Conformity release gate | Release management | CISO | Before Dec 11, 2027 | Pipeline blocks placement without the approved file, declaration, Annex II information and marking |
The declaration signatory is the authorized manufacturer signatory, not automatically the CISO. At every gate, the exit condition is evidence for the version placed on the market, not a policy that exists somewhere else in the company.
AI agents are writing the code the EU CRA will judge
Your developers’ AI agents are writing the code the EU CRA will judge, and your team is accountable for it. The obligations attach to the product and its manufacturer whether a person or an AI system produced the code.
That changes the evidence problem. A release decision under point 2(a) is an exploitability judgment across code that no person may have reviewed line by line. Vulnerability handling becomes version-coverage accounting when agents change supported branches quickly. The SBOM must come from the resolved build because an agent may have introduced the dependency. This is an agentic AI security problem viewed through the technical file, and the planned AI agents and EU CRA code guide develops that connection.
Trent’s continuous scanning and exploitability assessment supports a manufacturer’s vulnerability-handling program by helping identify and prioritize potentially exploitable issues, including issues in agent-produced code, and by keeping findings current as connected code changes. Trent’s component inventory may contribute to the manufacturer’s inventory, but it is not the manufacturer’s SBOM. The underlying security approach has been measured against real-world CVEs in the CWE-Bench evaluation. Scoping, classification, support-period commitments, conformity assessment, technical documentation, the EU declaration of conformity, CE marking and Article 14 notifications remain the manufacturer’s responsibility.
Two deliverables to start this month
The first two rows of the build order can start now: a per-SKU classification memo with legal sign-off, and a named program owner with a budget line. Everything after that has a date, an owner and an exit criterion above. If the security team wants a second pair of eyes on the exploitability side, that is what a demo is for.
Reviewed by Brajesh Kumar, MTS at Trent AI and Eno Thereska, Co-founder & CEO at Trent AI
EU Cyber Resilience Act FAQ
This is engineering guidance, not legal advice. The binding law is Regulation (EU) 2024/2847. Commission guidance C(2026) 5252 is non-binding and should be read alongside the regulation and current official materials.
What is the EU Cyber Resilience Act?
The EU Cyber Resilience Act is Regulation (EU) 2024/2847, product-compliance law for hardware and software with digital elements placed on the Union market. It requires manufacturers to manage cybersecurity risk, satisfy applicable Annex I requirements, maintain technical documentation, complete conformity assessment, issue an EU declaration of conformity, affix CE marking and handle vulnerabilities throughout the support period.
Who does the EU Cyber Resilience Act apply to?
The main duties apply to manufacturers that place products with digital elements on the Union market under their own name or trademark. Importers and distributors have narrower verification and cooperation duties. A manufacturer outside the EU can still be covered when it targets the Union market. An authorized representative does not assume the manufacturer’s core Article 13 and Article 14 responsibilities.
What products are covered by the Cyber Resilience Act?
The regulation covers products with digital elements made available on the Union market in commercial activity, including software supplied on its own and qualifying remote data processing solutions. The intended purpose or reasonably foreseeable use must include a direct or indirect connection to a device or network. Article 2 excludes specified regulated products and non-commercial free and open-source software.
Does the Cyber Resilience Act apply to SaaS?
Browser-only SaaS is generally not itself a product with digital elements unless it is the qualifying remote data processing solution of another product. Downloadable clients, extensions, SDKs and on-premises software can be products in their own right. A backend qualifies only when the manufacturer is responsible for its development, and a product function depends on it.
When does the Cyber Resilience Act take effect?
The regulation entered into force on December 10, 2024. Article 14 reporting applies from September 11, 2026, including to in-scope products placed on the Union market earlier. Most manufacturer obligations, Annex I requirements, conformity assessment, CE marking, market surveillance and penalties apply from December 11, 2027, to newly placed products and substantially modified earlier products.
What does placed on the market mean under the EU CRA?
Placed on the market means the first supply of an individual product on the Union market. Made available means any later supply. The test applies to each product, not merely to a product family, or the date a version was first launched globally. Distance-sales offers targeted at Union customers can establish that a product is made available there.
What are important and critical products under the EU CRA?
Important products are the categories listed in Annex III and divided into Class I and Class II. Critical products are listed in Annex IV. Classification depends on the product’s core functionality and the technical descriptions in Implementing Regulation (EU) 2025/2392. The class determines the available conformity route, including when third-party assessment is required.
What are the penalties for non-compliance with the Cyber Resilience Act?
Article 64 creates tiered maximum administrative fines based on the obligation breached and, for undertakings, worldwide annual turnover. The largest tier applies to Annex I and Articles 13 and 14. Actual enforcement depends on the circumstances and statutory factors. The narrow derogations for specified small-enterprise reporting delays and open-source stewards do not remove the underlying duties.
Does the Cyber Resilience Act require an SBOM?
Yes. Annex I Part II point 1 requires a machine-readable SBOM in a commonly used format covering at least top-level dependencies. The SBOM belongs in the technical documentation. Providing it to users is optional under Annex II point 9. It should be tied to the resolved build and the exact released version rather than assembled from a stale manifest.
How long must manufacturers provide security updates under the EU CRA?
The support period must reflect expected product use and is normally at least five years, though it can be shorter when expected use is shorter and longer when expected use is longer. Each security update issued during that period must remain available for at least 10 years after issue or for the remaining support period, whichever is longer.
What must be reported within 24 hours under the EU CRA?
A manufacturer must submit an early warning after becoming aware of an actively exploited vulnerability contained in its product or a severe incident affecting the product’s security. The deadline is without undue delay and within 24 hours. Ordinary vulnerabilities, a CVE record or a proof of concept do not by themselves establish reliable evidence of real-world malicious exploitation.
What does CE marking mean for software under the EU CRA?
CE marking indicates that the manufacturer has completed the applicable conformity assessment and takes responsibility for the product’s conformity. For software, the marking can appear on the EU declaration of conformity or on an easily and directly accessible accompanying website section. It must be applied before the product is placed on the Union market, not before assessment is complete.
