Cyber Resilience Act (CRA): What Manufacturers and Software Vendors Must Do, and By When
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, makes cybersecurity a legal condition of selling connected hardware and software in the EU. It covers "products with digital elements": any software or hardware that can connect to a device or network, from a smart thermostat and its app to an industrial controller or an operating system. Manufacturers must build the product securely, handle vulnerabilities through its support period, report actively exploited vulnerabilities within 24 hours, and affix the CE marking. The reporting duty has applied since 11 September 2026; the rest applies from 11 December 2027. Source: Regulation (EU) 2024/2847.
This page is for product and engineering leads who have to deliver CRA compliance, including US companies selling into the EU: scope, timeline, the Annex I requirements, product classes, reporting, CE marking, penalties and a checklist, then where penetration testing fits.
One thing to know first: Budget Security is not a notified body. We do not issue CE marking or conformity assessments, and we do not test firmware or tear down hardware. We test the software, APIs, mobile apps and cloud back ends of connected products, and deliver a report you can file in the technical documentation.
What the Cyber Resilience Act is, and who is in scope
Article 2(1) applies the regulation to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network. Article 3(1) defines such a product as a software or hardware product and its remote data processing solutions, including components sold separately. Remote data processing (Article 3(2)) is processing at a distance that the manufacturer designed and without which the product cannot perform one of its functions. In plain terms: the cloud back end your device or app depends on is part of the product. Source: Regulation (EU) 2024/2847, Articles 2 and 3.
Who carries the obligations. The manufacturer (Article 3(13)): whoever develops or manufactures the product and markets it under its own name or trademark, paid or free. Importers (Article 3(16)) and distributors (Article 3(17)) have checking duties; Article 19 requires an importer to confirm the conformity assessment, technical documentation and CE marking exist before placing a product on the market.
US and other non-EU companies. The trigger is making the product available on the EU market, not where you are based. A US vendor selling to EU customers is the manufacturer. With no EU establishment, Article 14(7) routes your reports through the CSIRT of the member state where your authorised representative, importer or distributor sits, or where most of your users are.
What is excluded. Article 2 carves out products already covered by sector rules: medical devices and in vitro diagnostics, motor vehicles, certified civil aviation products and marine equipment. Spare parts built to the same specification as the part they replace are out, as are products made exclusively for national security, defence or classified information.
Open source. The regulation applies only to products supplied in the course of a commercial activity. Recital 18 says free and open-source software that its manufacturer does not monetise is not commercial, and individuals contributing code to projects they are not responsible for are out of scope; paid support beyond cost recovery or monetising through a platform can make it commercial. Foundations that support open-source projects used commercially are "open-source software stewards" with a light regime under Article 24 and no fines under Article 64(10). Integrate open-source components into your commercial product and you are its manufacturer, with Article 13(5) due diligence on those components.
Cyber Resilience Act timeline: the dates that matter
Article 71 sets the dates; the European Commission confirms entry into force on 10 December 2024. Source: European Commission, Cyber Resilience Act.
- 10 December 2024. Entry into force.
- 11 December 2025. Deadline for the Commission's implementing act describing the Annex III and IV product categories (Article 7(4)).
- 11 June 2026. Chapter IV, Articles 35 to 51, applies: the machinery for designating notified bodies.
- 11 September 2026. Article 14 applies: reporting of actively exploited vulnerabilities and severe incidents. Article 69(3) extends it to every in-scope product, including those placed on the market before 11 December 2027.
- 11 December 2027. Full application. Products placed on the market from this date must meet Annex I, pass conformity assessment and carry the CE marking. Under Article 69(2), products already on the market only come under the full regulation if substantially modified from then on.
As of this page's date the reporting duty is live: learn of an actively exploited vulnerability in a product you have on the EU market and the 24-hour clock is already running.
Annex I Part I: the essential requirements for the product itself
Article 13(1) requires every product to be designed, developed and produced in line with the essential cybersecurity requirements in Annex I Part I, and compliant when placed on the market. Article 13(2) requires a documented cybersecurity risk assessment covering planning, design, development, production, delivery and maintenance; Article 13(4) puts it in the technical documentation.
Part I has a general duty, an appropriate level of cybersecurity based on the risks, and then, where applicable, a list of properties the product must have:
- No known exploitable vulnerabilities when made available on the market.
- Secure by default configuration, with a reset to the original state.
- Security updates, automatic where applicable, with a user opt-out.
- Access control: authentication, identity and access management, and reporting of possible unauthorised access.
- Confidentiality of stored, transmitted and processed data, such as encryption at rest and in transit.
- Integrity of data, commands, programs and configuration against unauthorised manipulation.
- Data minimisation: process only data adequate, relevant and limited to the purpose.
- Availability of essential functions, including resilience against denial-of-service attacks.
- Minimised attack surface, including external interfaces.
- Exploitation mitigation to reduce the impact of an incident.
- Logging and monitoring of relevant internal activity, including access to or modification of data, with a user opt-out.
- Secure deletion and transfer of all user data and settings.
Read as an engineering backlog, that list is what a security review of your product must cover before 11 December 2027. The first item is the one a penetration test answers directly: you cannot claim no known exploitable vulnerabilities for a release nobody has tried to break.
Annex I Part II: vulnerability handling, SBOM and regular testing
Part II is about process. Article 13(8) sets the duration: the support period must reflect the expected time of use and "shall be at least five years", unless the product is expected to be used for less. Through that period the manufacturer must:
- Identify and document vulnerabilities and components, including by drawing up a software bill of materials (SBOM), which Article 3(39) defines as a formal record of the details and supply chain relationships of the software's components.
- Address and remediate vulnerabilities without delay, including through security updates.
- Apply effective and regular tests and reviews of the product's security. This makes penetration testing a recurring duty, not a one-off.
- Publicly disclose fixed vulnerabilities once a security update is available, with severity and remediation steps.
- Enforce a coordinated vulnerability disclosure policy and provide a contact address for reports.
- Distribute updates securely, and automatically where applicable.
- Disseminate security patches without delay and free of charge, with advisory messages for users.
Article 13(6) extends this to components: a vulnerability found in a third-party or open-source component you integrated must be reported to its maintainer and remediated. Article 13(19) requires the support period's end date, at least month and year, to be stated at the time of purchase.
Product classes and conformity assessment: self-assessment or a notified body
The CRA sorts products into four groups, and the group decides who checks your work.
Default products. Everything not listed in Annex III or IV. The Commission says most products, such as household appliances, computer games or mobile applications, go through the standard assessment. Article 32(1) lets the manufacturer self-assess under module A: internal control against Annex I, technical documentation and an EU declaration of conformity.
Important products, class I and II. Article 7 covers products with the core functionality of an Annex III category: products that primarily perform functions critical to the cybersecurity of other products, networks or services, such as authentication, intrusion detection or network protection, or whose compromise could disrupt many other products or harm users. Article 32(2): class I may self-assess only if it fully applies harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level substantial; otherwise it needs a notified body, through EU-type examination plus internal production control (modules B and C) or full quality assurance (module H). Article 32(3): class II always needs a notified body or a certification scheme at level substantial or higher.
Critical products. Article 8 covers Annex IV categories on which essential entities under NIS2 critically depend or whose compromise could disrupt critical supply chains. The Commission may require a European cybersecurity certificate; until it does, Article 32(4) applies the class II procedures. A notified body is an organisation a member state designates under Chapter IV for these third-party assessments. Budget Security is not one.
The reporting duty: 24 hours, 72 hours, final report
Article 14 covers two events: an actively exploited vulnerability in your product (Article 3(42): reliable evidence that a malicious actor has exploited it) and a severe incident affecting its security. Article 14(5) calls an incident severe when it affects, or could affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or leads to malicious code running in the product or a user's systems.
Both go to the CSIRT designated as coordinator in your member state and to ENISA at the same time, through the single reporting platform ENISA runs under Article 16.
- Early warning within 24 hours of becoming aware, including the member states where the product is available and, for incidents, whether malicious action is suspected.
- Notification within 72 hours: product details, the nature of the exploit or incident, measures taken, measures users can take, and how sensitive the information is.
- Final report: for a vulnerability, within 14 days after a corrective or mitigating measure is available; for an incident, within one month after the notification. Description, severity and impact, root cause or threat actor where known, and the fix.
Article 14(8) requires you to inform affected users, in a machine-readable format where appropriate; if you do not, the CSIRT may. Article 64(10) spares microenterprises and small enterprises from fines for missing the 24-hour deadline, not from the duty.
CE marking, technical documentation and penalties
CE marking. Article 13(12) sets the order: technical documentation, conformity assessment, EU declaration of conformity, CE marking. Article 30 requires the marking to be visible, legible and indelible and affixed before placing on the market; for software it may sit on the declaration of conformity or an easily accessible part of your website. Where a notified body was involved under module H, its identification number follows the marking.
Technical documentation. Article 31 requires it to show the means used to meet Annex I, with at least the elements in Annex VII, drawn up before placing on the market and kept current at least through the support period. This is where the risk assessment, SBOM, test reports and vulnerability handling records live, and it is the first thing a market surveillance authority or notified body asks for.
Penalties. Article 64 sets three tiers; the higher figure applies. Breaching the Annex I requirements or Articles 13 and 14: up to EUR 15,000,000 or 2.5 % of total worldwide annual turnover. Breaching other operator duties, including CE marking, documentation and conformity assessment procedures: up to EUR 10,000,000 or 2 %. Supplying incorrect, incomplete or misleading information to notified bodies or authorities: up to EUR 5,000,000 or 1 %. Authorities can also order corrective action or withdraw a product from the market.
Cyber Resilience Act compliance checklist
One row per obligation, the artefact that proves it, and the team that usually owns it. Build the technical documentation folder from day one; assembling it afterwards is what makes CRA projects slip.
| Requirement | What to produce | Who owns it |
|---|---|---|
| Scope and class (Articles 2, 7, 8) | Product inventory with scope decision and class per product, cloud back ends included | Product management with legal |
| Risk assessment (Article 13(2)) | Versioned assessment from design to maintenance, filed in the technical documentation | Security lead |
| Annex I Part I properties | Requirement-to-product mapping with evidence, plus a pentest report at release | Engineering |
| SBOM (Annex I Part II) | Machine-readable SBOM per release, generated in the build pipeline | DevOps |
| Regular tests and reviews (Annex I Part II) | Testing programme with cadence, dated reports, findings tracked to closure with retest evidence | Security lead |
| Vulnerability disclosure (Annex I Part II) | Published policy, contact address, triage procedure | Security lead |
| Updates and support period (Article 13(8), (19)) | Update mechanism, support period of at least 5 years, end date shown at purchase | Product management |
| Reporting (Article 14) | Runbook with 24-hour, 72-hour and final-report steps, platform access, on-call owner | CISO |
| Conformity assessment (Article 32) | Module A file, or notified body engagement for class I, II and critical | Compliance lead |
| Documentation and CE marking (Articles 30, 31) | Annex VII file, EU declaration of conformity, CE marking | Compliance lead |
CRA and NIS2. The CRA regulates product security: what a manufacturer builds into a product with digital elements and how it handles vulnerabilities through the support period. The NIS2 Directive regulates organisational security: the risk management, incident reporting and supply chain controls that operators of essential and important services must run. Operate in a NIS2 sector and sell a connected product, and you owe both. See NIS2 penetration testing for the organisational side.
Where penetration testing fits, and what Budget Security delivers
The CRA never says "penetration test". It asks for three things a pentest produces. Annex I Part I: no known exploitable vulnerabilities at release, which you can only assert after someone tried to exploit it. Annex I Part II: effective and regular tests and reviews through the support period. Article 31: technical documentation showing the means used to meet Annex I, and a dated report with findings, severities and retest evidence is the most legible means there is. For class I, II and critical products, a notified body reads that file.
What we deliver. Manual penetration tests by OSCP-certified testers of the parts of a connected product that run as software:
- Web application penetration testing of the customer portal, admin console or device management interface.
- API penetration testing of the REST, GraphQL or SOAP interfaces your devices, apps and partners call, where the Article 3(2) remote data processing usually lives.
- Mobile penetration testing of the iOS and Android companion apps.
- Cloud penetration testing of the AWS, Azure or Google Cloud account behind the product.
- External network penetration testing of the internet-facing infrastructure serving the fleet.
Every test is manual; tooling handles discovery only. Black, grey or white box. You get a PDF report per asset within 48 hours after the test ends: executive summary, scope, and each finding with severity, CVSS score, impact, fix, replication steps and evidence, ready for the Annex VII file. The included vulnerability management workspace tracks each finding to closure, invites developers on findings-only accounts, creates Jira Cloud issues in one click and generates a fix prompt for your AI coding tool. Retests are a paid add-on of one tester-day and close the finding in the same tracker. Pricing is $985 per tester-day for US clients (€849 per day for EU clients), no setup or project-management fee, payment after the report is delivered.
What we do not do. We are not a notified body: no Article 32 conformity assessments, no EU declarations of conformity, no CE marking. We do not write your risk assessment, SBOM or technical documentation. We do not test firmware, analyse device images or attack hardware interfaces; if your risk sits in that layer, you need a hardware security lab for it. Our scope is the web, API, mobile and cloud software of the product.
How to start. Register, add the product's assets, and the scoping engine returns tester-days and the price; booking creates a quote, not a payment, and testing starts within 7 days. For a figure first, use the pentest pricing calculator; when the scope is set, order a pentest.
FAQ
Cyber Resilience Act: frequently asked questions
Does the Cyber Resilience Act require a penetration test?
Does the CRA apply to US companies?
Does the Cyber Resilience Act apply to SaaS?
Does the CRA apply to open-source software?
What is an SBOM under the CRA?
When do I need a third-party conformity assessment?
What happens if I miss the 11 December 2027 date?
Need the test evidence for your Annex VII file?
Scope the web, API, mobile and cloud parts of your product and see the tester-day estimate first. OSCP-certified testers, start within 7 days, report within 48 hours after the test ends.