Deep Dive: CRA Requirement (a) – No Known Exploitable Vulnerabilities

The first essential cybersecurity requirement under the EU Cyber Resilience Act (CRA) establishes a foundational expectation: connected products must not be released to the market if they contain security vulnerabilities that are already known and technically exploitable.

“(a) be made available on the market without known exploitable vulnerabilities;”

This requirement sets the baseline for security assurance. It forces manufacturers to adopt a structured approach to vulnerability identification and mitigation before any product reaches users. Under CRA, overlooking a known vulnerability is no longer just a quality issue, it becomes a legal obligation.

What This Requirement Means

At its core, this requirement prohibits the release of any digital product if the manufacturer is aware of exploitable security flaws. This includes issues discovered through internal testing, as well as those published in public vulnerability databases or disclosed by external researchers.

For non-technical stakeholders, think of this as ensuring that no “unlocked doors” are knowingly left open in a connected device. Just as a car manufacturer cannot ship vehicles with a faulty brake system that they’re aware of, digital product manufacturers are prohibited from shipping devices that contain known exploitable security flaws.

As we move into more technical ground, this requirement implies the need for a repeatable vulnerability management process that spans both internal and external components. It covers not only the manufacturer's own code but also third-party software, libraries, firmware components, and even the configuration defaults used at the factory. Known vulnerabilities refer to any issues already identified as exploitable in publicly accessible vulnerability databases, internal bug trackers, or threat intelligence feeds. It is not sufficient to say the product was “secure to the best of our knowledge”, the burden is now on manufacturers to prove it was checked.

Relevant Standards and Guidelines

Although the CRA does not prescribe specific technical standards, several well-established frameworks and guidelines can support compliance with this requirement:

• ISO/IEC 27001 and 27002 provide a comprehensive management system and control framework for handling information security risks, including structured policies and processes for vulnerability tracking and response.

• IEC 62443-4-1 is highly relevant for industrial IoT and OT systems. It includes practical steps for security testing, including vulnerability and penetration testing, though it is tailored specifically to industrial environments.

• ISO/IEC 30111 and ISO/IEC 29147 provide guidance on handling and disclosing vulnerabilities. These are central for structuring internal vulnerability management and external coordinated disclosure processes.

• ISO/IEC 18045 (Common Criteria methodology) outlines how to conduct structured vulnerability assessments. It focuses on pre-release testing but does not address remediation.

• ETSI EN 303 645 includes expectations for vulnerability management in consumer IoT devices but does not explicitly require pre-market vulnerability resolution.

• MISRA C and CERT C/C++ offer secure coding guidelines, particularly relevant in embedded software development.

• OWASP SAMM and OpenSSF Scorecards help assess software security maturity and support process improvement.

• SPDX and CycloneDX are widely used SBOM formats. While not security standards themselves, they play a critical role in identifying known vulnerabilities in software components through automated CVE matching.

These standards offer strong building blocks, but as highlighted by the ENISA CRA standards mapping report, they mostly focus on detection rather than remediation, and few address embedded or constrained environments adequately. Manufacturers should therefore go beyond these frameworks, ensuring that discovered vulnerabilities are not just identified, but demonstrably fixed or mitigated before product release, as required by the CRA.

How to Approach Implementation

Meeting this requirement starts with integrating vulnerability assessment into every stage of the product lifecycle. This begins at the design phase, where security principles should guide architectural choices, and extends through development, integration, testing, and release.

Modern secure development workflows typically combine several tools and techniques:

• Static and dynamic application security testing to identify vulnerabilities in custom code

• Software composition analysis to detect flaws in third party components by referencing known vulnerability databases such as the CVE (US) or the recently established EUVD (EU)

• A machine readable SBOM to provide visibility into all software dependencies and allow for fast correlation with new CVEs as they emerge

To make this effective, security must be built into the development process itself. Automated vulnerability testing should be embedded into the Continuous Integration and Continuous Delivery (CI/CD) pipeline. Tools for static and dynamic analysis, composition analysis, and SBOM generation should be automatically triggered as part of every build and release, rather than being applied manually at the end. This approach helps identify known vulnerabilities early, ensures repeatable quality checks, and produces the traceable evidence required for compliance. Any decisions to accept or mitigate risks must be clearly documented, linked to specific components and builds.

The specific implementation depends on the type of system. Industrial solutions often run on full operating systems and use technologies like Docker to host software in containers. These systems benefit from well-established DevSecOps tools that work with container registries, scan operating system packages, and support automated deployment pipelines. Embedded systems, by contrast, typically run low-level firmware developed in languages like C, C++ or Rust. These require a different set of tools focused on build-time checks, secure coding practices, and memory safety. Vulnerability scanning for embedded devices must reflect their static structure, limited resources, and tightly integrated components. Regardless of system type, the objective is the same: to ensure that products are thoroughly tested, free from known exploitable vulnerabilities, and compliant before they reach the market.

Once the software for a product has been developed, thoroughly tested, and all identified vulnerabilities have been either resolved or properly mitigated, the results must be clearly documented. This includes recording the vulnerability assessment process, decisions made regarding risk acceptance or mitigation, and references to the tools used. Additionally, the final software bill of materials (SBOM), listing all third party components and versions, must be included. Together, these elements form a key part of the product’s technical documentation (as outlined in Annex VII) and are required to demonstrate compliance under the Cyber Resilience Act.

This topic builds on all key aspects of the CRA, explore our CRA Guide to access all related resources.

Compliance and Strategic Considerations

For many companies, the Cyber Resilience Act marks a turning point, not just in how security is managed, but in how development and security teams work together. Historically, security has often been treated as a separate function, stepping in late to flag issues after most development work was done. This approach not only slows down delivery, it creates tension between teams and results in costly rework.

The CRA demands a different approach. To meet the requirement of shipping products without known exploitable vulnerabilities, security must be built into the software development lifecycle from the start. That means setting up a secure development process that is automated, traceable, and tightly integrated into how developers already work.

This is not just about compliance; it's about working smarter. When security becomes part of the developer workflow, rather than an external gate, it reduces friction, saves time, and prevents issues before they become expensive to fix. It turns what used to be a bottleneck into a quality accelerator.

Ultimately, this requirement is not just a box to check. It’s a mindset shift.

Security and development must operate as one team, using the same tooling and sharing responsibility for product quality. Organizations that adopt this approach will not only meet CRA requirements, they’ll be able to build more secure products faster, with fewer surprises and lower long-term costs.

In our next post, we will explore Requirement (b): Secure by Default Configuration, a principle that redefines how connected products behave straight out of the box.

Next Blog CRA Requirement (b):https://www.tributech.io/blog/cra-requirement-b-secure-by-default