The Cyber Resilience Act and the key role of security testing

The European Union's Cyber Resilience Act (Regulation (EU) 2024/2847) mandates that manufacturers of digital products conduct effective and regular security tests, with reporting obligations starting 11 September 2026 and core requirements taking effect 11 December 2027. The European Commission published non-binding implementation guidance on 27 July 2026, spanning about 80 pages with 67 examples, to clarify scope and testing expectations.

The Cyber Resilience Act and the key role of security testing Zoran Gorgiev, Francesco Corti Table of contents Most coverage of the Cyber Resilience Act explains scope, CE marking, and deadlines. Far less of it deals with the sentence that will shape day-to-day engineering work for years. Annex I, Part II, point 3 of the regulation says manufacturers must apply effective and regular tests and reviews of the security of the product with digital elements . One line. No method, no frequency, and no template. Yet that line sits behind the technical documentation a market surveillance authority can ask to see. This article looks at the EU Cyber Resilience Act https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act from that angle: - What the testing duty asks for - How to defend the test cadence you pick - How far it reaches into APIs, web apps, LLM apps, and MCP servers Where CRA implementation stands in 2026 The Cyber Resilience Act CRA , formally Regulation EU 2024/2847, entered into force on 10 December 2024, but its requirements apply progressively . As implementation moves forward, a four key deadlines and provisions are now coming into focus. 11 September 2026: CRA vulnerability and incident reporting begins From this date, manufacturers will be required to report actively exploited vulnerabilities and severe security incidents to ENISA and the relevant CSIRT, using the CRA single reporting platform. The reporting windows are short: - An early warning must be submitted within 24 hours of becoming aware of the issue, followed by a more detailed notification within 72 hours . - For actively exploited vulnerabilities , the final report must be submitted within 14 days after a corrective or mitigating measure becomes available. - For severe incidents , the final report is due within one month of the 72-hour notification . 11 December 2027: Core CRA cybersecurity requirements take effect The CRA’s core requirements take effect, including compliance with the essential cybersecurity requirements set out in Annex I https://www.cyberresilienceact.eu/annexes.html , as well as the conformity assessment procedures required for CE marking https://www.cyberresilienceact.eu/ce-marking.html . CRA reporting obligations for products already on the market There is an important detail that companies can easily overlook. Article 69 3 https://www.european-cyber-resilience-act.com/Cyber Resilience Act Article 69.html extends the reporting obligations to certain in-scope products that were already placed on the market before December 2027, even if those products have not subsequently been modified . In practice, this means that a product may fall outside some of the CRA’s product requirements while still being subject to the reporting obligations under Article 14 https://www.european-cyber-resilience-act.com/Cyber Resilience Act Article 14.html . Products sold years earlier may therefore still be relevant. European Commission guidance on CRA implementation On 27 July 2026, the European Commission approved its guidance on the implementation of the CRA https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation , as required by Article 26 https://www.european-cyber-resilience-act.com/Cyber Resilience Act Article 26.html . The guidance runs to around 80 pages and includes 67 worked examples and five flowcharts addressing some of the questions manufacturers are most likely to face. The guidance is non-binding, and some legal uncertainty remains, particularly around issues such as: - Determining whether a product falls within scope - The treatment of remote data processing solutions - The application of the CRA to free and open-source software Even so, the guidance is likely to become an important reference point for market surveillance authorities and notified bodies. Companies should therefore use it when interpreting and documenting their compliance decisions. At the same time, they need to keep in mind that only the Court of Justice of the European Union can provide a definitive interpretation of the Regulation. What products fall within the CRA’s scope A product with digital elements is a software or hardware product, plus its remote data processing , whose intended purpose or foreseeable use includes a direct or indirect data connection to a device or network. The July 2026 guidance sharpens that definition in ways that matter to anyone who builds software reachable over a public network: Where the software runs carries real weight. Software that executes on the user’s device e.g., a downloaded app, a browser extension, or a locally installed client generally qualifies as a product with digital elements. Software reached only through a browser does not, on that ground alone. Web apps and websites. A browser-only web application, and a site that merely presents information, generally fall outside the CRA. They come into scope where they qualify as remote data processing that supports a product’s function. Remote data processing. Remote processing forms part of a product where its absence would stop the product from performing one of its functions, and where the manufacturer designed that software or holds responsibility for it. Source code in public repositories. Publication of FOSS in a public repository generally does not amount to placement on the market. Open-source software outside commercial activity mostly stays out of scope. However, a legal person who acts as an open-source software steward carries a defined, lighter set of duties, including reporting. What “effective and regular tests” require Three CRA provisions matter most for testing: Annex I https://cyber-resilience-act.com/annexes/annex-i/ , Part I, point 2 a . Products must be placed on the market without known exploitable vulnerabilities.- Annex I, Part II, point 3. Manufacturers must apply effective and regular tests and reviews of product security. - Annex VII, point 6. Technical documentation must include reports of the tests used to verify conformity with the essential cybersecurity requirements. Read together, these provisions require manufacturers to test product security, act on the results, and keep evidence of what they did. That makes certain common practices difficult to defend in the CRA compliance context: - A finding list with no assessment of the significance or exploitability of the issues identified - A report that does not record what was tested or what could not be assessed - A remediation with no verification that the issue was fixed - A one-off prerelease test that is not repeated after meaningful changes How the CRA complements the NIS 2 Directive The two texts work on different objects. The NIS 2 Directive governs organizations , their risk management, their incident handling, and their governance. The Cyber Resilience Act governs digital products , both hardware and software, from design through the whole support period. They meet at procurement. NIS2 Article 21 3 https://www.nis-2-directive.com/NIS 2 Directive Article 21.html tells essential and important entities to weigh the security practices of their suppliers, including secure development procedures. The CRA gives those entities something concrete to ask for: a declaration of conformity, a support-period end date, and evidence of secure development, vulnerability handling, and conformity assessment. Two practical consequences follow: A vendor outside CRA scope will still field CRA-shaped questions from customers who must satisfy the NIS2 supply chain duties. A company inside both frameworks can reuse the same body of product-security testing evidence for CRA compliance and NIS2 supply-chain assurance, as long as that evidence ties findings to products and fixes. How to set a defensible CRA testing cadence The CRA does not define how often “regular” testing must take place. That leaves manufacturers to set a cadence that fits the product and its risks. Article 13 https://www.european-cyber-resilience-act.com/Cyber Resilience Act Article 13.html provides a natural basis for that decision. It requires manufacturers to assess the cybersecurity risks associated with the product and take that assessment into account when planning, developing, producing, delivering, and maintaining it. In practice, testing should follow the product’s risk and rate of change. For software that changes frequently, that means running tests as part of the development cycle and triggering additional testing when security-relevant changes occur https://equixly.com/blog/2026/04/24/what-is-cost-and-how-does-it-relate-to-ctem/ , rather than waiting for the next scheduled assessment. Those changes may include: - Modifications to authentication or authorization - New or significantly changed API endpoints - Changes to remote data processing that the product relies on - New third-party components, model providers, or tool integrations Security updates that affect exposed parts of the product- Evidence of active exploitation affecting a component used by the product - A substantial modification that triggers a new conformity assessment There is no single testing interval that will make sense for every product. What matters is that the manufacturer can explain why it chose a particular cadence and how that cadence responds to changes in the product’s security risk. Equixly and CRA security testing: LLM apps, MCP servers, web apps, and APIs Equixly runs continuous penetration testing https://equixly.com/glossary/continuous-penetration-testing/ against LLM systems https://equixly.com/blog/2026/04/14/the-state-of-llm-security/ , MCP implementations https://equixly.com/blog/2026/08/05/stateless-mcp/ , web applications https://equixly.com/blog/2025/12/01/owasp-top-10-2025-vs-2021/ , and APIs https://equixly.com/glossary/api-security/ . Its agentic AI https://equixly.com/blog/2025/09/28/ai-agents-vs-agentic-ai/ chains requests, validates exploitability, and returns proofs of concept with remediation guidance. Teams can run tests in CI/CD https://equixly.com/blog/2026/04/20/how-to-build-api-security-into-your-ci-cd-pipeline-a-devsecops-playbook/ and against live environments, then retest fixes to confirm that they hold. How that supports CRA compliance depends first on where the system sits in relation to an in-scope product: LLM apps. The CRA creates no separate scope category for LLM-based applications or AI features. The ordinary CRA questions still apply: what software constitutes the product, where does it run, and does an in-scope product depend on a remote component to perform one of its functions? MCP servers. The CRA does not treat MCP as a separate category, so the ordinary software and remote-processing rules apply. A locally installed MCP server may itself qualify as a product with digital elements where the CRA’s general scope conditions are met. A hosted MCP server may instead form part of an in-scope product’s remote data processing where that product depends on it to perform one of its functions. Web apps. A browser-only web app generally falls outside the CRA on its own. It becomes relevant when it forms part of the remote data processing that an in-scope product needs to perform one of its functions. APIs. When an in-scope product depends on a remote back end, its APIs may expose that functionality to users, integrations, and attackers. Testing those APIs can therefore provide evidence about the security of the product and its qualifying remote data processing. For teams preparing for CRA requirements, Equixly can support the testing and evidence side of the work by providing: Evidence from testing for exploitable vulnerabilities before release A repeatable testing cadence that supports the CRA requirement for effective and regular security testing Retest records that connect findings, fixes, and verification Technical findings that developers can act on promptly Equixly does not decide whether a product falls within CRA scope, conduct the conformity assessment, or issue an EU declaration of conformity. Manufacturers still need to make and document those decisions and complete the applicable conformity-assessment process, with legal or notified-body input where appropriate. Final thoughts The Cyber Resilience Act asks a straightforward question of every manufacturer: can you show that you tested and reviewed the security of this product, and that you continue to do so over time? Scope questions will continue to require careful interpretation, but the testing duty itself is clear. Manufacturers need: - A defensible testing methodology - A cadence tied to the product’s cybersecurity risk - Records of the testing performed - Evidence that identified issues were addressed and fixes verified Companies that build that discipline now will reach December 2027 with a documented testing record already in place. Those that do not may find themselves trying to reconstruct one under compliance pressure. Start your pentest https://equixly.com/start-pentest/ with Equixly and build repeatable security testing evidence that supports your CRA compliance program. FAQs Does the Cyber Resilience Act require penetration testing? Not explicitly, as the CRA does not prescribe any specific testing method. However, penetration testing is unquestionably a method that supports the requirement for effective and regular security testing by identifying and validating exploitable vulnerabilities. How often does the CRA require security testing? The CRA sets no fixed interval. Testing cadence should reflect the product’s security risk and respond to changes in the product, its environment, and the cyber threats it faces. Can continuous penetration testing support CRA compliance? Yes. It can provide repeatable security testing, retest evidence, and a documented record of findings and fixes, leaving, however, the manufacturer responsible for the wider CRA conformity process. Do our APIs fall under the CRA if we sell a browser-based web application? Not necessarily. APIs become relevant where they form part of the remote data processing that an in-scope product depends on to perform one of its functions. What testing evidence belongs in CRA technical documentation? Annex VII requires reports of tests used to verify conformity with the applicable cybersecurity requirements. A defensible record should show what was tested, the results, and evidence of remediation and verification where applicable. Zoran Gorgiev Technical Content Specialist Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing. Francesco Corti Head of Product Management Francesco is a product leader who turns deep technology into usable, scalable developer-facing products. He currently works on AI-driven software validation and cybersecurity tooling for engineering teams. He previously worked on cloud and AI developer tooling at Docker as Principal Product Manager and at Backstage at Spotify. Francesco combines technical depth with GTM awareness and a strong connection to developer communities. He is also an international speaker, author, mentor, and long-time open-source contributor.