Why DAST Is Critical for Cyber Resilience Act Compliance
As both cyberattacks and the number of digital products are on the rise, the European Union's Cyber Resilience Act (CRA) is a set of cybersecurity standards for any hardware and software products that have digital components. Aiming to protect consumers, the regulation sets clear rules for how companies must ensure security practices are embedded throughout the entire lifecycle of their products.
DAST is crucial to achieving full lifecycle security as per the CRA, and this article will give you, as a product security leader, the key insights you need to get both the CISO's approval and necessary budget approval for a modern DAST.
The CRA comes at a critical time. Cyberattacks are not only becoming more frequent but also increasingly successful, and are set to have a global annual cost of $10.5 trillion by the end of 2025. So following CRA standards is not only a compliance requirement but a vital priority for application security.
To maintain this compliance, and overall have a robust product security strategy, DAST is crucial in all three stages:
- Building security into design and development (which explicitly includes continuous testing)
- Incident response
- Compliance reporting
The European Union adopted the CRA in December 2024, but its full enforcement is set for December 11, 2027. Nevertheless, organizations are strongly advised to begin implementing their security and compliance processes now to ensure compliance readiness and high security standards.
Quick Snapshot: Why DAST Matters for CRA Compliance:
Dive into the article to discover how, why, and where DAST fits into CRA compliance.
What is the Cyber Resilience Act (CRA)
The Cyber Resilience Act is a unified set of cybersecurity standards for any "products with digital elements" (PDEs) in the EU market, which applies to everything from IoT devices, enterprise software and mobile apps, to cloud-based platforms and network equipment. Hence, it's important to note that this Act applies to any company selling in the European Union, not just to companies from EU member states, including manufacturers, distributors, and importers.
These mandatory cybersecurity requirements span the entire product lifecycle, from secure design to development, production, maintenance, and response. Businesses must display proactive vulnerability management in two key ways: fulfilling prerequisites that ensure security during development, and thorough incident response and reporting processes.
The European Union adopted the CRA in December 2024, but its full enforcement is set for December 11, 2027. Nevertheless, organizations are strongly advised to begin implementing their security and compliance processes now to ensure compliance readiness and high security standards.
How is the CRA relevant to application security and how can you ensure compliance?
Building security into development
The purpose of the CRA is to protect consumers from insecure PDEs, so a crucial pillar of the Act is mandating that products are designed as securely as possible to be protected against known vulnerabilities throughout their lifecycle. DAST is paramount here by identifying runtime vulnerabilities as soon as they arise, allowing developers to remediate as efficiently as possible
Annex I outlines multiple requirements that explicitly mandate robust security in development, and here is how DAST can help meet them:
"This is about risk management across the SDLC. As part of the SDLC you're running DAST as one of the default methods to test your product while assessing risks." - Roman Zhukov, Principal Security & Community Architect at Red Hat
Limit attack surface
Annex I Part I 2(j)
"[PDEs must] be designed, developed and produced to limit attack surfaces, including external interfaces"
Modern applications expose numerous interfaces from APIs and web frontends to third-party integrations. In order to ensure your application is secure, you have to know what is exposed. That's where a DAST with automated endpoint discovery, like Escape, can be vital in making sure no exposed endpoint is missed, both internal and external, including shadow APIs and hidden assets.
Other key ways to minimize exposure are:
- Reduce unnecessary endpoints that aren't essential to core functioning.
- Use secure defaults so there is proper authentication, encryption and input validation
Detect and Prioritize Known Exploitable Vulnerabilities
Annex I Part I 2(a):
"[PDEs must] be made available on the market without known exploitable vulnerabilities"
This means applications must be continuously tested for vulnerabilities, and organizations must have robust remediation processes. Taking a proactive approach to security, the CRA requires continuous monitoring and remediation as new threats emerge:
Annex I Part II 3:
"Apply effective and regular tests and reviews of the security of the product with digital elements."
Why is a modern DAST crucial to achieving this effectively?
Incorporating automated testing tools into every stage of the SDLC allows you to alert developers to vulnerabilities as soon as they emerge. Using a SAST to scan source code in the IDE and a DAST from live preview environments through to regularly scanning the production environment, you can be sure to pick up every critical vulnerability.
To make sure your DAST actually helps you comply with CRA, there are three things to look out for:
- Vulnerability prioritization: Unlike legacy scanners, you need to ensure your tool doesn't just send you an endless array of false positives. Equally, security teams are already stretched thin, so to make sure you mitigate exploitable vulnerabilities as required, your tool should prioritize vulnerabilities and only alert you if they are actually exploitable.
- Test for complex vulnerabilities, including business logic: Once again, legacy scanners can fall short in meeting this CRA requirement as they can miss vital vulnerabilities since they are not built to test modern applications. Therefore, to make sure you don't miss any exploitables, you need to ensure your tools are native to modern applications and can test for more complex vulnerabilities, including understanding your application's business logic.
- Code snippets and actionable insights: To enable efficient remediation, scanning tools should give developers actionable insights along with framework-specific code snippets that developers can easily understand and apply, ideally, with fixes they can copy and paste directly into their codebase.
Additionally, the CRA requires risk classification, so your tool needs to be able to identify the risk level of a vulnerability not only to optimize remediation but also to meet the CRA requirements themselves.
"It will be hard to test your app without DAST, which provides additional assurance of meeting these requirements." Roman Zhukov, Principal Security & Community Architect at Red Hat
Prevent unauthorized access
Annex I Part I 2(d):
"ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access"
The key mechanism to achieve this is strengthening access controls with layered defenses, which includes continuous monitoring as well as authorization and session management.
A modern DAST is particularly useful here by testing for access control flaws because, unlike legacy DASTs, it can understand the business logic of an application and mimic attacks that use weak or broken authentication mechanisms, insecure authorization, and misconfigured identity flows.
Using a DAST is therefore essential to uncover broken authorization (BOLAs), secret leaks, and any other means through which hackers can gain access to your organization through runtime flaws. As Part 1 2(a) highlights, the product cannot go to market with such vulnerabilities unaddressed, so a DAST is vital to catching them before production, and even more importantly, release.
Incorporating multi-factor authentication (MFA) and/or role-based access control (RBAC) are two other important ways of reducing the risk of unauthorized access to any data or applications.
Ensure Runtime Data Integrity with API-Native DAST
Annex I Part I 2 (f)
"protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions"
Data integrity applies not only to user data but also to internal communications and configurations (e.g. logs and audit trails, API payloads, etc.). This is particularly pertinent for application and API security, as 83% of web traffic flows through APIs, so they carry significant amounts of sensitive data.
Where does DAST add value here?
- As highlighted above, a modern DAST can monitor access control to ensure only the right people have access to sensitive data, whether in rest or in transit.
- Test for business logic flaws like access control issues, but also SSL certificate misconfiguration, need to be continuously tested for to prevent any manipulation or modification of data that is not authorized by the user.
- Crucially, modern DASTs can simulate attacks like human pentesters at the speed of automation, enabling security testing to be ongoing at scale.
- An API-native DAST is also able to identify APIs or endpoints that don't validate or sanitize input, where attackers could overwrite values or configurations.
Having an API-native DAST is particularly crucial to identify the business logic flaws that a legacy DAST would miss, hugely jeopardizing your compliance position and overall security posture regarding sensitive data management.
Secure Third-Party Components for CRA Compliance
Security is not just limited to what is created in-house, and the CRA recognizes this. Annex I Part II (6) mentions the identifying of vulnerabilities in the product and in third-party components, which is another place a modern DAST facilitates CRA compliance.
DASTs also scan an application's third-party dependencies, ensuring any exploitable vulnerabilities are uncovered by characterizing the logic of an application and how it interacts with third-parties to be able to simulate specific attacks exactly in the way a human pentester would.
Incident Response and Vulnerability Management
So we dove into why DASTs are necessary to meet the CRA's secure by design and continuous testing requirements, but to meet the CRA's incident response requirements of timely fixes, it is crucial to have a modern DAST.
Annex I Part II (7) "provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner
Why? Because legacy DASTs can take hours or days, cannot discover or accurately test APIs, and give no context or remediation suggestions when vulnerabilities are discovered. This means security is forced to operate in silos, with delayed feedback loops as you wait for rescans, wasted security and development hours trying to figure out which vulnerabilities are exploitable and critical, and then further hours wasted creating a solution from scratch.
A modern DAST like Escape not only turns scans from days to minutes, but integrates seamlessly into developer workflows, slotting into the CI/CD. With contextual insights and remediation code snippets, it can turn security from a developer's roadblock to a huge helping hand. Eliminating the endless false positives and sea of unnecessary alerts found in legacy tools, modern DASTs cut through the noise and prioritize vulnerabilities so developers can get straight to remediating real risks without wasting time, ensuring the timely fixes the CRA mandates.
Reporting Requirements Under the CRA
Annex I Part II (4)
"once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities"
Additionally, companies must make their product's compliance with the CRA available to users as part of their EU Declaration of Conformity, with details including what kinds of security support is offered by the manufacturer and where the report can be accessed.
To show both conformity and transparency, companies need to be running regular DAST scans to show that their applications are as secure as possible and that no vulnerability has been missed throughout the entire SDLC. Regular testing and patching ensure that vulnerabilities are handled swiftly, with proper communication to end-users and stakeholders.
Not only is the reputational damage of non-compliance severe, if you have to report a critical breach, but also financially draining, as non-compliance fines can lead to fines of €15 million euros or 2.5% of global annual turnover, whichever is higher.
Final Thoughts on CRA Compliance and DAST Adoption
For businesses selling in the EU, compliance with the CRA is not just a regulatory obligation but an essential part of maintaining robust application security. Implementing a DAST to automate vulnerability scanning, test for more complex vulnerabilities, and automate reporting will be invaluable to making your CRA compliance as efficient and effective as possible.
As December 2027 approaches and the CRA comes into full enforcement, starting your security processes now is the key to ensuring readiness. By implementing a DAST to demonstrate that secure API design and implementation were part of the overall security measures, as the CRA requires, you will not only achieve full compliance but also optimize your developers' remediation processes. The sooner you get started the better, as your business will both adhere to the law but also build greater trust with customers, users, and stakeholders.
Discover how to stay compliant with other standards: