November 4, 2026
Updated: November 5, 2026
Who is in scope, what Annex I and the SBOM rules require, the 24-hour reporting clock from 11 September 2026, and how security testing produces conformity evidence.
Mohammed Khalil
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is the EU law that sets mandatory cybersecurity requirements for hardware and software "products with digital elements" sold in the European Union. It entered into force on 10 December 2024. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents within 24 hours, followed by a 72-hour notification and a final report. From 11 December 2027, products must meet the essential requirements, pass a conformity assessment and carry the CE marking. Security testing produces much of the evidence that proves it.
| Item | What the regulation says |
|---|---|
| Legal instrument | Regulation (EU) 2024/2847, adopted 23 October 2024, published in the Official Journal on 20 November 2024 |
| Applies to | Hardware and software products with digital elements made available on the EU market that connect, directly or indirectly, to a device or network |
| Main duty holders | Manufacturers, with supporting duties for authorized representatives, importers and distributors, and a light regime for open-source software stewards |
| Core requirements | Annex I Part I (security properties of the product) and Annex I Part II (vulnerability handling, including a software bill of materials) |
| Reporting | Actively exploited vulnerabilities and severe incidents: 24-hour early warning, 72-hour notification, final report (Article 14) |
| Proof of conformity | Risk assessment, technical documentation (Annex VII), conformity assessment (Article 32), EU declaration of conformity, CE marking |
| Key dates | In force 10 December 2024; reporting from 11 September 2026; main obligations from 11 December 2027 |
| Maximum fines | Up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaches of Annex I, Article 13 or Article 14 |
The CRA is a product law, not an organizational one. It follows the same "New Legislative Framework" model the EU uses for toys or radio equipment: meet the essential requirements, prove it in a technical file, sign a declaration and affix the CE marking. What is new is that cybersecurity becomes a condition of market access, and that the obligations continue for the whole support period of the product.
Article 71 of the regulation sets three application dates. The Commission's implementation page adds the supporting acts that fill in the details.
| Date | What happens | Source |
|---|---|---|
| 23 October 2024 | Regulation adopted | Regulation (EU) 2024/2847 |
| 20 November 2024 | Published in the Official Journal | EUR-Lex |
| 10 December 2024 | Entry into force (20th day after publication) | Article 71(1) |
| 28 November 2025 | Implementing Regulation (EU) 2025/2392 gives technical descriptions of important and critical product categories | European Commission |
| 11 December 2025 | Delegated act on when CSIRTs may delay passing on a notification adopted | European Commission |
| 11 June 2026 | Chapter IV applies: rules for notifying conformity assessment bodies | Article 71(2) |
| 27 July 2026 | First Commission guidance on applying the CRA published (non-binding) | European Commission |
| 11 September 2026 | Article 14 reporting obligations apply; ENISA's Single Reporting Platform operational | Article 71(2); European Commission |
| 11 December 2027 | Full application: essential requirements, conformity assessment, CE marking; open-source steward reporting under Article 24(3) | Article 71(2); European Commission |
If you are reading this after 11 September 2026, the reporting duty already applies to you. It covers every in-scope product on the EU market, including products placed on the market before 11 December 2027 (Article 69(3)). The rest of the CRA does not bite on legacy products unless they undergo a substantial modification after 11 December 2027 (Article 69(2)).
Harmonised standards are still arriving. Under standardisation request M/606, the Commission asked the European standardisation organizations for 41 standards. According to the Commission's CRA FAQ, the horizontal standards on secure development and on vulnerability handling were requested by 30 August 2026, product-specific (vertical) standards by 30 October 2026, and the standard covering the Annex I Part I product properties by 30 October 2027. A standard only gives a presumption of conformity once its reference is published in the Official Journal, so check the Journal before relying on one.
Article 2(1) puts a product in scope when it is a "product with digital elements" made available on the EU market and its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Article 3(1) defines that product as a software or hardware product and its remote data processing solutions, including components placed on the market separately.
In practice that covers connected devices, routers, operating systems, desktop and mobile apps, firmware, software libraries sold as products and the cloud back ends a product needs to work. Mobile apps, for example, are a default-category product, so the security testing you already do for a mobile application becomes part of a CRA technical file. Connected consumer devices are among the most exposed product types; our IoT hacking statistics show why regulators started there.
The law applies wherever the manufacturer is based. A US company that sells a connected product or commercial software into the EU is a manufacturer under the CRA, and its importers and distributors carry their own checks.
Remote data processing is covered only when the manufacturer designs it and the product cannot perform one of its functions without it (Article 3(2)). Recital 12 gives the line: cloud features that let you control a smart home device remotely are in scope, while websites that do not support a product's functionality and cloud services designed outside a manufacturer's responsibility are not. Software as a Service as such falls under the NIS2 Directive rather than the CRA. If you run SaaS for EU customers, our guide to NIS2 penetration testing covers the obligations that apply to you as an entity.
Open-source software is in scope only when it is made available on the market in the course of a commercial activity (recital 18). Non-commercial projects are outside the CRA. Foundations and similar legal persons that support open-source software intended for commercial use on a sustained basis are "open-source software stewards" with a light regime under Article 24: a documented cybersecurity policy, cooperation with authorities and, from 11 December 2027, reporting duties to the extent they are involved in development.
| Exclusion | Legal basis |
|---|---|
| Medical devices and in vitro diagnostic medical devices | Article 2(2): Regulations (EU) 2017/745 and 2017/746 |
| Motor vehicles under type-approval rules | Article 2(2): Regulation (EU) 2019/2144 |
| Products certified under EU civil aviation rules | Article 2(3): Regulation (EU) 2018/1139 |
| Marine equipment | Article 2(4): Directive 2014/90/EU |
| Identical spare parts made to the same specification | Article 2(6) |
| Products developed or modified exclusively for national security or defense, or to process classified information | Article 2(7) |
Article 2(5) also lets the Commission limit or exclude the CRA for products whose sector rules give the same or a higher level of protection.
| Role | Who it is | Main CRA obligations |
|---|---|---|
| Manufacturer | Develops or manufactures the product, or has it made, and markets it under its own name or trademark (Article 3(13)) | Risk assessment, Annex I compliance, support period, vulnerability handling, technical documentation, conformity assessment, declaration and CE marking, Article 14 reporting |
| Authorized representative | EU-established person with a written mandate from the manufacturer | Tasks named in the mandate, such as cooperating with market surveillance authorities |
| Importer | EU-established person placing a non-EU brand's product on the EU market | Verify the conformity assessment, technical documentation and CE marking before placing the product; act on known vulnerabilities and non-compliance |
| Distributor | Makes the product available without changing its properties | Check CE marking and that manufacturer and importer duties were met; inform the manufacturer of vulnerabilities |
| Open-source software steward | Legal person sustaining commercial-use open source | Cybersecurity policy, cooperation, limited reporting from 11 December 2027; not subject to administrative fines |
An importer or distributor that puts a product on the market under its own name, or substantially modifies it, takes on the manufacturer's obligations (Articles 21 and 22).
Most products are in the default category and the manufacturer may self-assess. Products whose core functionality matches a category in Annex III (important) or Annex IV (critical) face stricter conformity routes. Integrating such a product as a component does not by itself make the final product important or critical (Article 7(1)). Implementing Regulation (EU) 2025/2392 now gives the technical descriptions of each category.
| Category | Examples from the annexes | Conformity assessment route (Article 32) |
|---|---|---|
| Default | Products not listed in Annex III or IV, such as most mobile apps, games and smart speakers | Any route, including internal control (module A) self-assessment |
| Important, class I (Annex III) | Identity management and privileged access management systems; standalone and embedded browsers; password managers; anti-malware software; VPN products; network management systems; SIEM systems; boot managers; PKI and certificate issuance software; physical and virtual network interfaces; operating systems; routers, internet modems and switches; microprocessors, microcontrollers, ASICs and FPGAs with security functions; smart home virtual assistants; smart home security products such as door locks, cameras, baby monitors and alarms; connected toys with social or location features; health-monitoring or children's wearables outside medical device rules | Module A only if harmonised standards, common specifications or a certification scheme at assurance level at least "substantial" were applied in full; otherwise EU-type examination (module B plus C) or full quality assurance (module H) with a notified body |
| Important, class II (Annex III) | Hypervisors and container runtime systems; firewalls and intrusion detection and prevention systems; tamper-resistant microprocessors; tamper-resistant microcontrollers | Third-party assessment: module B plus C or module H, or a European cybersecurity certification scheme at assurance level at least "substantial" where available |
| Critical (Annex IV) | Hardware devices with security boxes; smart meter gateways and other devices for advanced security purposes, including secure cryptoprocessing; smartcards or similar devices, including secure elements | A European cybersecurity certification scheme where the Commission requires one by delegated act (Article 8(1)); otherwise the class II routes |
Two details often get lost. Operating systems and general microprocessors are class I, not class II; only tamper-resistant chips are class II. And free and open-source products in class I or II may still use self-assessment if the manufacturer makes the technical documentation public (Article 32(5)).
Article 6 says a product may be made available only if it meets Annex I Part I and the manufacturer's processes meet Annex I Part II. Article 13(2) and (3) require a documented cybersecurity risk assessment that decides how each Part I requirement applies, and that assessment goes into the technical file. A requirement that does not apply needs a written justification.
On the basis of that risk assessment and where applicable, Part I point (2) requires products to:
| Point | Requirement in short | Typical testing question |
|---|---|---|
| (a) | Be made available without known exploitable vulnerabilities | Has the release been tested, and were exploitable findings fixed or justified? |
| (b) | Ship with a secure-by-default configuration, with a reset option | Are default credentials, open debug services and permissive settings gone? |
| (c) | Allow vulnerabilities to be fixed through security updates, automatic by default with an opt-out | Can an attacker tamper with or downgrade the update channel? |
| (d) | Protect against unauthorized access through authentication, identity or access management, and report possible unauthorized access | Can authentication or authorization be bypassed? |
| (e) | Protect the confidentiality of stored, transmitted or processed data, for example by state-of-the-art encryption | Is sensitive data exposed at rest or in transit? |
| (f) | Protect the integrity of data, commands, programs and configuration, and report corruption | Can configuration or firmware be modified without authorization? |
| (g) | Process only data that is adequate, relevant and limited (data minimization) | Does the product or its API collect or expose more than it needs? |
| (h) | Protect the availability of essential functions, including resilience against denial-of-service attacks | Do essential functions survive malformed input and load? |
| (i) | Minimize negative impact on other devices or networks | Can the product be abused to attack others? |
| (j) | Limit attack surfaces, including external interfaces | Which ports, services and APIs are exposed, and are they needed? |
| (k) | Reduce incident impact using exploitation mitigation mechanisms | Are memory protections and sandboxing in place? |
| (l) | Record and monitor relevant internal activity, with a user opt-out | Are security events logged in a way investigators can use? |
| (m) | Let users securely and permanently remove all data and settings | Does a factory reset really erase data? |
Point (1) adds the overarching rule that products must ensure "an appropriate level of cybersecurity based on the risks."
"No known exploitable vulnerabilities" does not mean "no vulnerabilities." The Commission's FAQ says the CRA does not require a product to be free from all vulnerabilities, and that exploitability is decided case by case, considering whether the vulnerable code is reachable, what access an attacker needs and whether compensating controls exist. That is exactly the judgment a penetration test with exploit validation supports.
Part II of Annex I lists eight processes manufacturers must run for the whole support period:
Point 3 is the one security teams should underline. "Effective and regular tests and reviews" is an ongoing process requirement, not a one-time pre-launch check. It fits naturally into a secure SDLC.
Annex I Part II point (1) requires an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies" of the product. Article 3(39) defines an SBOM as a formal record of the components in the product's software and their supply chain relationships.
Three points answer most SBOM questions:
Article 13(5) requires due diligence when you integrate third-party components, including open source. When you find a vulnerability in a component, Article 13(6) requires you to report it to whoever maintains that component and to share any fix you developed. The Commission's guidance (paragraphs 222 to 225) narrows this: you report upstream only for the version you integrate, not where the maintainer is already aware, and not where the component is unmaintained. Weak links in that chain are how supply chain attacks spread.
The support period must reflect how long the product is expected to be in use and is at least five years, unless the product is expected to be in use for less (Article 13(8)). Each security update must stay available for at least 10 years after release or for the rest of the support period, whichever is longer (Article 13(9)). The end date of support, at least month and year, must be clear at the time of purchase (Article 13(19)).
A mature vulnerability management program already covers much of Part II. The CRA's addition is that the evidence must sit in a technical file that an authority can request.
Article 14 creates two reporting duties for manufacturers:
| Stage | Actively exploited vulnerability (Article 14(2)) | Severe incident (Article 14(4)) |
|---|---|---|
| Early warning | Within 24 hours of becoming aware; indicate Member States where the product is available | Within 24 hours; say whether unlawful or malicious acts are suspected and indicate Member States where the product is available |
| Notification | Within 72 hours: general information on the product, the nature of the exploit and vulnerability, corrective or mitigating measures taken and measures users can take, and how sensitive the information is | Within 72 hours: nature of the incident, initial assessment, measures taken and measures users can take, and sensitivity |
| Final report | No later than 14 days after a corrective or mitigating measure is available: description, severity and impact; information on the malicious actor where available; details of the update or other fix | Within one month after the 72-hour notification: detailed description, severity and impact; likely threat type or root cause; applied and ongoing mitigation |
| Intermediate report | On request of the CSIRT (Article 14(6)) | On request of the CSIRT (Article 14(6)) |
Later stages are needed only "unless the relevant information has already been provided." Note the asymmetry: the vulnerability final report runs from when a fix exists, while the incident final report runs from the 72-hour notification.
The deadlines run from when the manufacturer "becomes aware." The Commission's guidance on applying the CRA (paragraph 213) says a manufacturer should assess a suspicious event immediately and is aware when, after that initial assessment, it has "a reasonable degree of certainty" that a vulnerability in its product is being actively exploited or that a severe incident has compromised the product's security. The guidance stresses prompt action on that initial assessment. Slow triage does not stop the clock in practice; it just makes the eventual report look late.
Notifications go through the Single Reporting Platform run by ENISA, which the Commission says has been operational since 11 September 2026. You submit once, to the endpoint of the CSIRT designated as coordinator in the Member State of your main EU establishment, and the notification is simultaneously accessible to ENISA (Article 14(7)). The main establishment is where decisions on product cybersecurity are mainly taken; if that cannot be determined, it is the EU establishment with the most employees.
Manufacturers with no EU establishment report to the CSIRT of, in order: the Member State of the authorized representative acting for the most of your products, then that of the importer placing the most of your products, then that of the distributor making the most of your products available, and finally the Member State with the most users of your products.
The receiving CSIRT passes the notification to the CSIRTs of other Member States where the product is available. It may delay that only on justified cybersecurity grounds, such as an ongoing coordinated disclosure (Article 16(2)); the Commission adopted a delegated act on 11 December 2025 setting the conditions.
Separately, Article 14(8) requires you to inform impacted users, and where appropriate all users, about the vulnerability or incident and the mitigations they can apply, in a machine-readable format where appropriate. The guidance (paragraph 220) says this should be risk-based: detailed technical information may be limited to affected customers where public disclosure would itself increase risk. The Commission's reporting obligations page links to ENISA's platform resources.
| Situation | Mandatory report under Article 14? | Basis |
|---|---|---|
| Reliable evidence that attackers exploited a flaw in your product, including a zero-day | Yes | Article 3(42); Commission FAQ |
| A vulnerability your own testers or an external testing lab found, with no evidence of malicious exploitation | No; voluntary reporting under Article 15 is possible | Commission FAQ; recital 68 |
| A bug-bounty submission with no evidence of prior exploitation | No | Commission FAQ |
| An actively exploited flaw in a third-party component that is reachable and exploited in your product | Yes; the component's manufacturer also reports if the component was placed on the market | Commission FAQ; guidance paragraph 218 |
| A component vulnerability that is not reachable, or not exploited, in your product | No; but report it upstream (Article 13(6)) and handle it under Annex I Part II | Guidance paragraph 218 |
| Active exploitation you already knew about before 11 September 2026 | No retroactive report | Guidance paragraph 217 |
| A vulnerability known before 11 September 2026 whose exploitation you learn of after that date | Yes | Guidance paragraph 217 |
| An exploited flaw in a product placed on the market in 2020 or whose support period has ended | Yes; reporting continues even where vulnerability handling duties do not apply | Article 69(3); guidance paragraph 210 |
| A severe incident that compromises the security of your product | Yes | Article 14(3) and (5) |
Article 64(10) excludes administrative fines for micro and small enterprises that miss the 24-hour early-warning deadline; the 72-hour notification and final report still apply to them. Anyone, not only manufacturers, may notify vulnerabilities, cyber threats, incidents and near misses voluntarily under Article 15.
The CRA regulates products; NIS2 and DORA regulate organizations. A single company can sit under all three. A manufacturer of network equipment may report an actively exploited vulnerability in its router under the CRA, while the same company, if it is an essential or important entity, reports a significant incident on its own services under NIS2. Recital 12 places SaaS under NIS2, not the CRA.
The deadlines look familiar on purpose, but the triggers, recipients and content differ, so keep separate decision trees. For entity-level testing and reporting duties, see our guides to NIS2 penetration testing and, for banks, insurers and their ICT providers, DORA penetration testing and TLPT requirements. Financial entities that buy CRA-marked products will increasingly ask suppliers for CRA evidence during DORA third-party reviews.
The CRA never uses the words "penetration test," but it asks for what a pentest produces. Annex I Part II point (3) requires "effective and regular tests and reviews of the security of the product." Annex VII point 6 requires the technical documentation to contain "reports of the tests carried out to verify the conformity" of the product and of the vulnerability handling processes. And Part I point (2)(a) requires release without known exploitable vulnerabilities, which you can only claim credibly if someone has looked for them.
The Commission's FAQ adds two useful points. The CRA does not mandate a specific evaluation methodology, and manufacturers may test in their own or external laboratories under their sole responsibility. Market surveillance authorities may then run their own tests, and the FAQ notes that cybersecurity testing is not deterministic, so results may differ. Your technical file should therefore show scope, method, dates, findings, fixes and retests, not just a pass statement.
| CRA requirement | Testing or review activity | Evidence to file (Annex VII) |
|---|---|---|
| Risk assessment (Article 13(2)–(3)) | Threat modeling of the product, its interfaces and its remote data processing | Documented risk assessment that states how each Annex I Part I point applies |
| No known exploitable vulnerabilities (Part I (2)(a)) | Pre-release penetration test with exploit validation and severity scoring | Test report, remediation records, retest results, justification for accepted residual risk |
| Secure by default (Part I (2)(b)) | Configuration review of shipped defaults, debug interfaces and default credentials | Default configuration baseline and review notes |
| Access control, confidentiality, integrity (Part I (2)(d)–(f)) | Authentication and authorization testing; API and cloud back-end testing; transport and storage encryption checks | Findings mapped to Annex I points, with fixes |
| Attack surface and exploit mitigation (Part I (2)(j)–(k)) | Exposed service enumeration; review of hardening and memory protections | Attack surface inventory and hardening evidence |
| Secure updates (Part I (2)(c); Part II (7)) | Update channel tampering, signature validation and rollback testing | Update mechanism test results |
| SBOM and components (Part II (1)) | Dependency analysis of the shipped build against the SBOM; triage of known component vulnerabilities for reachability | Machine-readable SBOM and component triage log |
| Regular tests and reviews (Part II (3)) | Retesting after major releases, significant fixes and architecture changes | Dated test history across versions |
| CVD and reporting (Part II (5)–(6); Article 14) | Check that the disclosure contact works; tabletop drill of the 24-hour early warning | CVD policy, contact address, runbook and drill notes |
For the risk assessment row, our guide to threat modeling shows how to build the Article 13 risk assessment.
White-box or gray-box testing, where testers get source code, architecture notes and test accounts, fits this purpose better than a pure black-box test, because the technical file needs coverage you can explain, not just findings an outsider stumbled on. Choose methodology by the product's risk assessment: a class II firewall deserves deeper and more frequent testing than a default-category game.
A finding from your own penetration test is not, by itself, an actively exploited vulnerability. The Commission's FAQ gives the example of a zero-day found by a cybersecurity assessment laboratory testing on the manufacturer's behalf, with no evidence of previous malicious exploitation, and says it is not subject to mandatory reporting. You must still handle and fix it under Annex I Part II, and you may report it voluntarily.
The picture changes if testers find signs that someone else got there first: an unknown web shell, unexpected accounts, logs that show exploitation by an unknown party in a customer environment, or indicators of compromise in a product's cloud back end. That is potential evidence of active exploitation or a severe incident, and it can start the 24-hour clock once your initial assessment reaches a reasonable degree of certainty. Write that into the rules of engagement:
The steps below are DeepStrike method guidance for meeting Article 14, not text from the regulation. Adapt them to your incident response plan.
| Time from first signal | Step | Owner | Output |
|---|---|---|---|
| 0 to 2 hours | Log the signal and start triage: customer report, researcher report, threat intelligence, telemetry or pentest escalation | Product security on-call | Ticket with timestamp |
| 2 to 8 hours | Initial assessment: is the flaw in our product, is there reliable evidence of malicious exploitation, or has a severe incident compromised product security? Check the SBOM for affected versions | Product security with engineering | Documented awareness decision and time |
| Before 24 hours from awareness | Submit the early warning through the Single Reporting Platform to the main-establishment CSIRT, listing Member States where the product is available | Designated reporting lead | Early warning receipt |
| Before 72 hours | Submit the notification with exploit nature, measures taken, user mitigations and sensitivity; start user communication under Article 14(8) | Reporting lead, communications | Notification receipt; customer advisory |
| Fix available | Ship the security update separately from feature changes where feasible; retest the fix | Engineering, testers | Release notes; retest report |
| 14 days after fix, or one month after notification for incidents | Submit the final report; publish fixed-vulnerability information under Part II point (4) when appropriate | Reporting lead | Final report receipt; advisory |
Rehearse this at least once with a realistic scenario. The weakest link is usually not the form; it is finding out within hours which product versions contain the vulnerable component and who in the EU sells them.
A penetration test does not make a product CRA-compliant. It does not replace the risk assessment, the conformity assessment, a notified body where one is required, or the declaration and CE marking, and the manufacturer remains solely responsible. What testing gives you is credible evidence for the parts of Annex I that need it, and a regular cadence that satisfies Part II point (3).
DeepStrike's penetration testing services follow that model. Our testers work manually, in black-box, gray-box or white-box mode with source code access where provided, across web applications, APIs, mobile apps, cloud and infrastructure. We exploit and validate vulnerabilities, score severity with CVSS, and deliver reports with reproduction steps, root causes and fix recommendations, followed by remediation retesting and an attestation letter. For a CRA technical file, that means test reports you can map to Annex I points and a retest history that shows the issues were fixed.
Do now, because reporting already applies:
Do before 11 December 2027:
Article 64 sets maximum administrative fines in three tiers. Member States set the detailed rules and must make penalties effective, proportionate and dissuasive.
| Infringement | Maximum fine |
|---|---|
| Non-compliance with the essential requirements (Annex I) or the obligations in Article 13 or 14 | EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher |
| Non-compliance with other listed obligations, including importer and distributor duties, the declaration, CE marking, technical documentation and conformity assessment procedures | EUR 10 million or 2% of total worldwide annual turnover, whichever is higher |
| Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities | EUR 5 million or 1% of total worldwide annual turnover, whichever is higher |
Market surveillance authorities can also order corrective action, withdrawal or recall of non-compliant products.
The Cyber Resilience Act is Regulation (EU) 2024/2847. It sets mandatory cybersecurity requirements for hardware and software products with digital elements sold in the EU, covering secure design, vulnerability handling, security updates, reporting and CE marking across the product's support period.
It entered into force on 10 December 2024. Reporting obligations under Article 14 apply from 11 September 2026, the rules for notifying conformity assessment bodies from 11 June 2026, and the main obligations from 11 December 2027.
Manufacturers of products with digital elements made available on the EU market, wherever they are based, plus authorized representatives, importers and distributors. Open-source software stewards have a lighter regime. Non-commercial open source, medical devices, type-approved vehicles, certified aviation products, marine equipment and national security products are excluded.
For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a notification within 72 hours and a final report no later than 14 days after a fix or mitigation is available. For a severe incident: 24 hours, 72 hours and a final report within one month of the 72-hour notification.
Yes. Manufacturers must draw up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. It does not have to be published, but must be given to a market surveillance authority on a reasoned request.
Not as such. The CRA covers remote data processing only when the manufacturer designs it and the product needs it to perform a function. Software as a Service is covered by the NIS2 Directive instead.
Not under Article 14 unless there is reliable evidence that a malicious actor has exploited the vulnerability. The Commission's FAQ says a vulnerability found by a testing lab on your behalf, without evidence of prior exploitation, is not subject to mandatory reporting. You still have to fix it, and you may report it voluntarily.
The CRA does not name penetration testing or mandate a test method. It does require effective and regular tests and reviews, release without known exploitable vulnerabilities and test reports in the technical documentation. Penetration testing is one of the most direct ways to produce that evidence.
The Cyber Resilience Act turns product security into a condition of selling in the EU, and its reporting clock has already started. Make sure you can recognize, assess and report an actively exploited vulnerability within 24 hours today, then build the risk assessment, SBOM and test history your technical file will need by December 2027. When you want test reports that map to Annex I and stand up to an authority's questions, talk to DeepStrike about penetration testing for your products and their cloud back ends.
This article explains the regulation and official guidance for general information. It is not legal advice; confirm how the CRA applies to your products with qualified counsel.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
