Skip to Content

Cyber Resilience Act

What it is — The EU Cyber Resilience Act (CRA) (Regulation (EU) 2024/2847 ) establishes cybersecurity requirements for products with digital elements placed on the EU market. It covers hardware and software products, requiring manufacturers to ensure security throughout the product lifecycle — from design through end of support. The CRA entered into force on 10 December 2024 with a phased implementation timeline.

Appsec relevance — Annex I of the CRA specifies essential cybersecurity requirements including vulnerability identification, security testing, and secure default configuration. For software products — especially web applications and APIs — these requirements map directly to DAST capabilities.

How Detectify Supports the CRA

RequirementWhat it requiresDetectify CapabilityCoverage
Annex I, Part I, (2)(a)Products shall be made available on the market without known exploitable vulnerabilitiesApplication + API + Internal Scanning with payload validation across its test suite identifies exploitable vulnerabilities before releaseFull
Annex I, Part II, (1)Identify and document vulnerabilities and components contained in products, including by drawing up a software bill of materialsVulnerability documentation with HTTP request/response evidence, technology discovery, JSON/XML exportsFull
Annex I, Part II, (3)Apply effective and regular tests and reviews of the security of the product with digital elementsScheduled DAST + API scanning + CI/CD integration via API-triggered scansFull
Article 13(2)Undertake an assessment of the cybersecurity risks associated with a product during planning, design, development, production, delivery, and maintenanceAPI-triggered scanning in CI/CD pipelines + Internal Scanning for pre-production testingFull
Article 13(12)Draw up technical documentation before placing a product on the market, as referred to in Article 31Scan reports with HTTP evidence, historical documentation, OWASP Top 10 categorization, PDF/JSON/XML exportsFull
Annex I, Part I, (2)(b)Products shall be made available on the market with a secure by default configurationDefault credential testing and security misconfiguration detection CWE-16 Partial
Annex I, Part II, (2)Address and remediate vulnerabilities without delay, including by providing security updatesRapid detection with CVSS-based prioritization + re-testing to validate remediationPartial
Annex I, Part I, (2)(d)Ensure protection from unauthorised access by appropriate control mechanisms, including authentication and access management systemsContinuous scanning detects authentication bypass, access control flaws, and authorization vulnerabilitiesPartial
Annex I, Part II, (1) — Third-party componentsIdentify known vulnerabilities in third-party components integrated into the productAlfred AI generates test modules for known third-party library CVEs when public POCs are availablePartial

What Detectify Covers

Detectify addresses the CRA’s core vulnerability identification and testing requirements. It provides evidence that products are tested for known exploitable vulnerabilities (Annex I, Part I, (2)(a)), that regular security tests are performed (Annex I, Part II, (3)), and that results are documented (Article 13(12)). CI/CD integration supports the requirement for security assessment during development (Article 13(2)).

The CRA’s requirements for SBOM generation, coordinated vulnerability disclosure, CE conformity marking, and ENISA reporting are outside DAST scope and require dedicated tools and processes.

Complementary Tools You May Need

  • Software composition analysis (SCA) — For SBOM generation and comprehensive component tracking
  • Coordinated vulnerability disclosure (CVD) platform — For managing external vulnerability reports
  • Conformity assessment tools — For CE marking and compliance documentation
  • SAST — For code-level vulnerability analysis during development
  • ENISA reporting infrastructure — For Article 14 vulnerability notification

References

Last updated on