Table of Contents
Let's talk

When manufacturers first engage with the EU Cyber Resilience Act (CRA), almost all of them follow the same instinct: They find the Annex 1 requirement for “no third-party exploitable vulnerabilities” and reach immediately for software composition analysis (SCA). SCA is the obvious starting point—it identifies known vulnerabilities in open source and third-party dependencies, it maps to the SBOM requirement that underpins supply chain transparency, and it’s already part of the AppSec toolkit for most mature organizations. The problem is that it’s incomplete, and the CRA’s requirements don’t stop where SCA’s coverage ends.

Genuine compliance—the kind that stands up to market surveillance—supports downstream customers in their own compliance journeys and actually reduces your exposure to the exploitation events the CRA was designed to prevent, but achieving it requires a layered testing strategy. SCA addresses your dependencies. Static application security testing (SAST) addresses your code. Dynamic application security testing (DAST) addresses your services. Each layer covers ground the others cannot, and the CRA’s scope demands all three.

Component visibility and SBOM generation

SCA is still the right place to start, for a simple reason: You can’t manage what you can’t see. Every product in scope for the CRA contains a supply chain—open source libraries, commercial components, third-party SDKs, upstream dependencies—and the regulation requires you to have complete, accurate visibility into all of it. An SBOM is not a documentation exercise; it is the operational foundation on which your vulnerability management program runs.

But getting SCA right under the CRA requires addressing some specific technical challenges that go beyond scanning a source code repository. For embedded products and firmware-based implementations, the complexity increases substantially. Yocto builds, commercial real-time operating systems, and firmware images don’t lend themselves to straightforward source-level analysis. Modern SCA tools address this complexity with binary analysis—examining compiled artifacts to identify component fingerprints even when source code isn’t available—and SBOM import capabilities that let you pull supplier-provided component inventories into your central monitoring environment.

The integration model matters enormously here. “If you’re receiving an SBOM from a supplier that includes commercial libraries, we can import those and monitor them,” explained Tim Mackey, head of software supply chain risk strategy at Black Duck.

Your compliance posture is only as strong as your weakest supply chain component, which means your SCA program needs to reach every component your product contains—including the ones you didn’t build yourself.

In Linux-based firmware implementations, Mackey continued, “because you can update a component independent of the Linux kernel, that level of detail at the component level becomes really important.” And that specificity supports two CRA requirements simultaneously: The ability to identify exploitable vulnerabilities at the component level, and the ability to remediate them without wholesale system updates.

Container-based deployments have a simpler but related story. “With a Docker container, being able to assess whatever vulnerabilities might be present is relatively straightforward,” said Mackey. “The way Docker images are supposed to work is that you can always update them on the fly, enabling you to automate the majority of CRA obligations.” The key is ensuring that your container scanning and update workflows are integrated into your CRA compliance pipeline, and not operating as a separate, disconnected practice.

SBOM format and interoperability

The CRA’s SBOM requirements are format-agnostic at the regulatory level, but practical interoperability demands multiformat fluency. Your supply chain partners may generate SBOMs in SPDX, CycloneDX, or other formats. Your customers will have their own format preferences. Your vulnerability-tracking workflows need to consume SBOMs regardless of their original format. Support for SPDX, CycloneDX, CSAF, VEX, and VDR across the full supply chain ecosystem is not a nice-to-have. It is the operational prerequisite for scalable CRA compliance.

When SAST becomes mandatory

Here is where many organizations’ initial CRA compliance plans hit their first significant speedbump. The requirement in Annex 1 to eliminate “exploitable vulnerabilities” covers all your code, not just your dependencies. Meeting that bar requires running SAST scans on your proprietary source code, not just the open source components sitting alongside it.

The supply chain dimension makes SAST non-negotiable for many manufacturers. If your software is a component in someone else’s CRA-regulated product, your security defects become their compliance problem. The downstream accountability pressure is real, and SAST is the technical discipline that addresses it.

Static analysis addresses the “secure-by-design” mandate that runs throughout the CRA’s requirements. The regulation isn’t asking you to secure a product after it’s built. It’s asking you to eliminate defects during development. SAST integrated into the CI/CD pipeline is the most direct implementation of that principle: Catching code-level security defects at the point of introduction, before they propagate to production and become vulnerability-handling obligations.

The practical integration point is your development pipeline. SAST scans should be run on every code change, not just at release gates. They should be configured to detect the specific defect categories—injection flaws, authentication weaknesses, insecure data handling, cryptographic errors—that the CRA Annex 1 requirements implicitly demand you to eliminate. And the findings should feed into the same compliance documentation system that captures your SCA results, your SBOM artifacts, and your vulnerability management records.

The DAST imperative for connected products

The third testing layer addresses a category of product architecture that is increasingly common and specifically within the CRA’s scope: Products that deliver functionality through cloud services, APIs, or network-connected back-end systems. For these products, SCA and SAST together still leave a significant attack surface unexamined.

“If part of what is being delivered is itself a cloud service, then penetration testing, red teaming, and DAST-type solutions all have a role to play—because it’s not just the product, it’s the system,” Mackey said. DAST examines running applications and services for exploitable vulnerabilities that static analysis cannot detect: Business logic flaws, authentication bypass conditions, runtime injection vulnerabilities, and API security issues that only manifest when the system is operational.

The CRA’s scope explicitly includes the cloud services and remote data processing capabilities that accompany regulated hardware and software products. If your product’s CRA scope includes a connected service component, DAST is not supplemental. It is the required testing methodology for that layer of your architecture, and its coverage needs to be documented with the same rigor you apply to your SCA and SAST programs.

Moving beyond point-in-time scans

The CRA’s vulnerability reporting timeline—24 hours for initial notification, 72 hours for confirmation, 14 days for a comprehensive report—operates on a continuous basis. A vulnerability discovered in a component you’ve been shipping for two years triggers the same obligations as one found in code you just committed. That reality makes periodic security scans fundamentally incompatible with CRA compliance. You need continuous monitoring across your entire product portfolio.

Exploitation window data makes the urgency concrete: In 2018, the average time from vulnerability discovery to active exploitation was two years. By 2026, that window has collapsed to less than 24 hours, with forecasts suggesting it will reach one minute by 2028. The CRA’s aggressive reporting timelines are a direct response to this reality. Your monitoring infrastructure needs to be equally fast.

Automation is not optional here. Manual processes—triaging new CVEs, cross-referencing component inventories, generating notifications, routing reports—cannot operate at the speed the CRA requires. Your compliance program needs automated workflows that can identify a newly disclosed vulnerability, determine which products are affected, initiate a notification, and route the response through your defined process within the 24-hour window. Organizations that are still running manual vulnerability management programs at the September 2026 deadline will face a structural inability to meet their reporting obligations.

Matching your testing strategy to your product architecture

The practical synthesis of everything outlined here comes down to a product-specific analysis of your security testing requirements. Not every product requires equal investment in every testing layer, but the CRA creates a clear framework for thinking about it.

  • SCA and SBOM are non-negotiable for every product in scope. Every product contains software. Every software supply chain requires a complete component inventory. Every component inventory needs to be continuously monitored for new vulnerability disclosures. This layer applies universally.
  • SAST is required for any product that contains proprietary source code, which in practice means nearly all of them. If you’re building functionality, not just integrating it from third parties, your code must be analyzed for security defects. Products whose output becomes a component in other manufacturers’ supply chains face particularly high accountability pressure here.
  • DAST is required for any product whose CRA scope includes cloud services, APIs, network-connected back-end systems, or any runtime-accessible attack surface that static analysis alone cannot exercise. As more products incorporate connected service architectures, this testing layer applies to an expanding share of the market.

The documentation angle is essential throughout. Testing is only half the compliance equation. You also need to be able to demonstrate that testing occurred, describe its scope and methodology, and show that findings were tracked and remediated. Every testing activity should generate artifacts that support your compliance narrative, from the SBOM and scan reports to the triage records and remediation evidence.

Building the infrastructure before you need it

The most common mistake organizations make at this stage is treating CRA security testing as a compliance project rather than an operational investment. The difference matters enormously in how you build and resource it.

A compliance project mindset produces point-in-time artifacts—a scan here, an SBOM there—designed to satisfy a regulatory checkpoint. An operational investment mindset produces infrastructure: Continuous monitoring pipelines, automated triage workflows, integrated SBOM management, and SCA/SAST/DAST tooling embedded in your development process. The CRA’s continuous obligations require the latter. By September 2026, your infrastructure needs to be operational, not in planning, not in pilot, but running at production scale across the products that are subject to reporting requirements.

The manufacturers that will navigate this transition most effectively are those building now, with the right tool stack: Comprehensive SCA for dependency visibility, SAST for code-level defect elimination, DAST for service-layer coverage, and continuous monitoring infrastructure that can keep pace with the shrinking window between disclosure and exploitation. Prioritize the infrastructure investment. The compliance outcomes follow from it naturally.