The Cyber Resilience Act (CRA) addressed years of unpatched IoT devices, weak firmware, and poorly maintained software flooding the EU markets.

It’s a thorough directive aimed specifically at shifting software security from an afterthought and optional task usually done right before launch to a crucial step done as early as possible. In the development process for existing projects, the aim is to embed security into the analysis and design stages of the product lifecycle.

CRA is enforcing a different, better view: more security-centric, with base requirements such as the “secured by design” principle. Regulators realised the need for better voluntary security guidelines by seeing cases such as hackers targeting critical infrastructure or hospitals, through smart sensors or routers that leaked admin panels.

The new paradigm sees consumer apps shipped with default credentials not only facing product security risks, but also legal risks. It’s a breach of conformity requirements under Annexe I, which mandates secure default configurations, active vulnerability management, and timely patching.

As part of the Cyber Resilience Act directive, developers will have to ensure that:

• The team reports critical vulnerabilities within 24 hours of discovery (Article 14).

• Detailed technical reports follow within 72 hours.

• The team provides and documents corrective product security patches within 14 days.

A Security-Centric Design Philosophy

The CRA introduces a clear technical baseline for software security. You can translate that baseline into code or design choices, or even into automated pipelines.

Knowing that applications and connected devices must now ship with secure-by-default configurations, meaning that developers must harden all exposed services, APIs, and authentication layers from the initial release. Built-in vulnerability management processes must also be included to ensure that continuous scanning, triage, and remediation are embedded into normal development workflows.

Security update mechanisms need to push patches automatically or by design, while still allowing users to opt out if needed. Finally, products require long-term support, providing security updates for at least five years after launch.

Supply Chain Concerns

CRA is immensely inspired by the expansion of IoT and software-defined infrastructure, where products depend heavily on third-party components and open-source code. One vulnerable library or misconfigured API can compromise thousands of devices overnight. One weak link could affect the security of the entire product, and the examples here are endless.

In development terms, this means maintaining a continuously updated list of product third-party libraries, or software bills of materials (SBOMs). Ideally, maintain a list of the SBOMs for the live environment and for the development stage. To assess whether a library is marked as vulnerable, we will need to continuously scan libraries in real time, not only during development but also in the live environment. There are multiple ways to achieve that: either generate, scan, and integrate the results into an existing monitoring tool, or leverage existing tools such as mend.io.

“Ship now, patch later” needs to become a thing of the past. CRA demands visibility, auditability and traceability.

The Cyber Resilience Act in the CI/CD

Impact Areas

• Traceability: every binary and component must be attributable to its source.

• Transparency: proof of what runs in production through SBOMs, SCA data, and signed attestations.

• Responsibility chain: clarity on who owns which part of the software supply chain.

The Cyber Resilience Act is finally important to more than just compliance officers. One of the biggest changes that CRA adds to EU-marketed products is that security must not be promised, but proven. That means that for every build, code included, and dependency used, it will need to go through security gates.

Ideally, we should change the focus when building to also keep security and quality management in mind, rather than just thinking about tools and products that slow down development. Although automated tools are necessary, they do not offer complete security. They offer additional layers of scanning for vulnerabilities or similar traces of malicious code. To improve security, we will need to be mindful during the analysis phase, even evaluating it against common attack vectors specific to the software type and medium, such as OWASP Top 10 for Web or Gen AI.

Another necessary step to achieve CRA compliance is to ensure traceability: linking code, build artefacts, and risk data to a verifiable chain of trust.

Automating CRA Controls

Here, the objective is clear: replacing manual reviews and static reports with pipeline logic that enforces and records CRA requirements automatically. Turning the CI/CD pipeline into a continuous verification system.

Stage Enforcement

After setting up the security scans, we will need to make sure that they are fined-tuned, cleared of excessive reporting with the risk of false positives, making sure that each tool will offer data type that can be integrated into a common monitoring tool, or correlating tool. Usually, the JSON approach and CycloneDX data types are a good first step.

Setting up the scans:

• Run static analysis (SAST) after code merge. Fail the pipeline if critical or high-severity findings exceed a threshold.

• Execute secret scanners during build time to detect exposed credentials or API keys.

• Use dependency and container scanners (SCA/OSV feeds) before packaging to identify vulnerable or outdated libraries.

• Include Infrastructure-as-Code checks to detect weak configurations (like open security groups, default passwords, or missing encryption flags).

• Add DAST stages that run lightweight runtime scans on temporary environments before deployment.

Note: SAST & DAST could be replaced with IAST for a better scanning tool that can corelate and eliminate false positives with better success. However, keep in mind that it’s still relatively new technology, and replacing SAST altogether might hide some of the vulnerabilities that it catches, especially in code that will only be used further in the future.

Each job should have clear rules: pass or fail. If only it were that simple, because going too drastic or too positive might delay the development process or altogether provide little security benefits.

Artifact-Based Evidence

As mentioned earlier, generate SBOMs and SCA outputs as machine-readable artefacts. Attach metadata, such as the component hash, version, and scan timestamp, for audit traceability. Now, the results should be centralised in tools such as vulnerability management or incident response systems.

Correlation

Automatically aggregate scan results into consolidated compliance packages (JSON, PDF, or dashboard output). Each package must link directly to the build or deployment event that produced it.

Continuous Verification

Trigger automatic re-scans when dependencies, configurations, or runtime conditions change. Feed the findings into ticketing or service management systems for security patches and real-time response.

Production Monitoring

Trigger periodic SBOM scans to identify existing vulnerabilities in released versions of your product. Monitor real-time logs and events to ensure a suitable incident response. Integrate within SIEM and SOC if possible.

Securing the Environment and Containers

The product is not secure only by ensuring the app itself is secure. Even with perfect code and clean dependencies, a weak runtime environment can break CRA compliance instantly. And the application security posture as well.

Understanding that the environment is part of the product is necessary, and in this way we can treat runtime as an extension of the supply chain.

We can ensure container protection with:

• Containers should be built, scanned, signed, and deployed across environments without changes. Rebuilding in production introduces uncertainty and breaks traceability.

• Employ cryptographic signing, such as Cosign or Sigstore, to verify that the deployed containers’ build artefacts align.

• Continuously scan running containers for vulnerabilities, outdated images, or unauthorised changes.

• Implement minimal permissions: no root access, limited syscalls, and namespace isolation.

• Define strict communication paths between services through network segmentation.

• Ensure default credentials, unused services, and exposed management endpoints are removed or disabled for environment hardening.

What comes next?

The next step is extending these controls to AI and machine learning systems, where model data, dependencies, and training components are tracked through AI-BOMs and verified trust chains.

If you’re looking to align your development process with CRA requirements or automate compliance checks, get in touch with our security specialists and identify the right implementation path for your product.