← Blog

The Cyber Resilience Act is won in your delivery chain, not in a binder

Opinion: the CRA is first an engineering story, one of good practices. What it changes for the business, where the budget should go, and what audits bring to the table.

· 12 min read
crasecuritysbomembeddedfirmware

By Florian Mahon, founder of ADNT Sàrl (opinion).

In short. The Cyber Resilience Act (CRA) is an obligation; the point is to turn it into an opportunity to improve your software supply chain. You are in scope as soon as you place a product containing software on the EU market, with narrow exceptions. Two dates: 11 September 2026 for reporting actively exploited vulnerabilities, 11 December 2027 for the full set of requirements. The manufacturer answers for it, not its subcontractor or its development team. And the real decision is a budget one: fund paper compliance, or consolidate the chain that builds and ships your software.

The Cyber Resilience Act lands as one more regulatory constraint: obligations, deadlines, evidence to produce.

I see it differently. What the CRA asks for, knowing what runs in your product, detecting when a vulnerability affects it, fixing it, and shipping the update quickly, is exactly what an engineering team that masters its software supply chain is already trying to do.

The Regulation simply turns it into a market requirement.

Agile brought software development shorter feedback loops and the ability to evolve a product without breaking what exists. In practice it rests on continuous delivery, automated tests, code review, observability, and an automated, reproducible software supply chain.

For companies that seize it, it is a chance to consolidate their practices and turn them into an advantage: ship faster, ship more safely, and be able to prove it.

The General Data Protection Regulation (GDPR) brought data protection into the design of web services. The CRA can bring security and maintainability into the design of software and firmware.

WHAT THE CRA REQUIRES Technical documentationand software inventory Vulnerability handlingand reporting Fixeswithout undue delay Secure updatesduring the support period Know what runs Detect that a vulnerability affects you Fix without regression Ship a reliable update WHAT THE DELIVERY CHAIN PROVIDES Inventory generatedwith every build Vulnerability monitoring,rehearsed response procedure Automated tests,reproducible builds Signed updates,continuous delivery the loop restarts with every release, with every vulnerability
What the CRA requires, a well-run delivery chain already provides.

What the CRA changes for the business

Regulation (EU) 2024/2847 introduces two key dates.

From 11 September 2026, manufacturers must report actively exploited vulnerabilities. From 11 December 2027, the full set of requirements applies: secure design, vulnerability handling, security updates throughout the support period, a software component inventory (an SBOM), and conformity assessment.

The notification details and product categories are set out in the Regulation. The important fact is elsewhere: the obligations attach to the product and to the organisation’s actual ability to maintain it. Documentation is necessary, but it does not replace that ability.

Good practices already reduce the gap

The CRA does not ask teams to invent security alongside their software.

A team that knows what it ships, detects vulnerabilities, fixes them without regressions, deploys reliable updates, and responds in an organised way has already built most of what is needed.

A software component inventory (an SBOM, Software Bill of Materials), monitoring published vulnerabilities and their CVE identifiers, tests, reproducible builds, signed updates, and a vulnerability-response process (a PSIRT) are therefore not boxes to tick. They are the practices that make a product maintainable and enable an effective incident response. For implementation details, see our article SBOM and CVE auditing in CI/CD for bare-metal embedded.

Want to go from principle to implementation? We document the technical side — SBOM, VEX (Vulnerability Exploitability eXchange, the document that states whether a product is actually affected), signing, integrity, security — in CRA & Dev, our wiki for developers. It shows how these questions translate into development practice; it replaces neither the conformity assessment nor the decisions described below.

Conformity work remains: retain evidence, document decisions, and, depending on the product category, complete the appropriate assessment. But the starting point is not an empty binder; it is a production chain that already works. That reduces compliance risk, time, and cost.

A well-run delivery chain makes the CRA achievable

This is not about sprints or a tracking tool. The essential contribution of these practices is shortening the loop between an observed problem, a decision, and a delivery. Applied to security, that loop lets the team understand a vulnerability’s impact, choose a response, ship a correction, and learn from it.

Automated tests, continuous integration, and frequent releases let teams fix issues without paralysing the business. Reproducibility adds a decisive assurance: a historical version can be rebuilt and examined rather than merely assumed. The CRA gives that operational capability market importance.

Security protects the user and the business

These practices do not only satisfy a market-surveillance authority. They protect user data, product availability, and trust in updates.

Reducing exposure, limiting access to what is necessary, and fixing problems quickly are how security becomes a quality of the product and a source of trust for the business.

Audits have a useful role: they verify that the capability exists and that its evidence is available. They should not replace it.

Turn an obligation into a lasting investment

The CRA budget can fund parallel bureaucracy, or durably improve how software is built and delivered.

The latter creates value after the regulatory deadline: faster fixes, fewer regressions, better control of versions in production, and less operational risk.

The value is not in the ritual or the document. It is in the team’s ability to learn, fix, and deliver. The CRA makes that capability visible and enforceable.

A company responsibility, not just a team’s

It is an engineering story, but it is not played out among engineers alone. The technical team can build the capability to know, detect, fix, and ship. Three decisions, however, cannot be made from the build chain:

  • Own the effort, don’t just delegate it. Name an owner, give them engineering time, and track progress like any other product project.
  • Demand evidence from the build, not documents. An SBOM generated with every release, CVE scanning in continuous integration, and a rehearsed incident response are worth more than a signed policy.
  • Decide the support period per product. It is a commercial and financial commitment: how long each product will receive fixes, and with what resources.

None of these choices requires technical skill. They require treating software security on the same footing as the physical safety of the product.

The CRA sets the timeline; it’s up to you to turn it into a lever for software quality

After December 2027, what remains will not be a binder. It will be a better-equipped team, a more reliable product, and better-protected users. The Regulation sets a date; good practices stay with you. The decision to fund them is yours.

Going further: from opinion to diagnostic

We support software vendors and makers of embedded products through the whole journey, starting from their build chain: our CRA compliance service.

➡️ Check whether your product is in scope: 3 minutes, no email

References