The CRA (the Cyber Resilience Act, the EU regulation on the cybersecurity of products containing software) is an obligation. We suggest turning it into an opportunity: improving your software supply chain (component inventory, continuous integration, monitoring and code fixes when needed) to retain your CE marking and deliver better software, for the long run.

On 11 September 2026, Article 14 takes effect: any actively exploited vulnerability in one of your products (including those you have already shipped) must be reported to ENISA, the EU cybersecurity agency, within 24 hours of the moment you become aware of it. Preparing for it costs little; the bulk of the technical requirements only arrives in December 2027. Do you know which products would be affected?

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

Already know you’re in scope? Get a first read → One hour, free, no strings attached.

Manufacturing in Switzerland? Start with what the CRA means for a Swiss company: your obligations by case and the Swiss bill in preparation.

This page speaks to three readers, and each will find their part:

The coloured column to the right of each section reuses these three tints: spot at a glance the sections that speak to you.

What changes, and when

Regulation (EU) 2024/2847, the CRA, sets cybersecurity requirements for any product carrying digital elements, application software and embedded firmware alike.

Complying with it means:

keeping your CE marking, and with it access to the European market;
improving your software supply chain, and everything that follows from it: a reliable inventory of your components, reproducible releases, delivery speed, fast response to a bug or a security flaw.

Two points tend to go unnoticed: reporting also covers what you shipped four years ago, and the CRA exempts no small or medium-sized enterprise, Swiss headquarters or not. Being ready means keeping your access to the European market and staying clear of the penalties provided for (up to 15 million euros or 2.5% of worldwide turnover). Manufacturing in Switzerland and selling into the EU? What the CRA means for a Swiss company: your obligations by case and the Swiss bill in preparation.

Since 27 July 2026, Commission guidance clarifies the scope and confirms the 11 September deadline without adding to it: reporting is triggered when you become aware of active exploitation, not before. The details are in the references at the end of the page.

A vulnerability is a business event before it is a technical one

A critical vulnerability, assigned a CVE identifier, can surface on a Friday evening in a library nobody has touched in two years. The question that night is: how many of your products are affected, in which shipped versions, and for which customers? With a current inventory, you answer within the hour: the 24-hour early warning goes out with facts, the 72-hour notification and the fix follow, and your customers get an answer instead of silence.

That is what the CRA invites you to build: less a legal file than an operational capability, one that then serves you at every bug and every delivery.

From detection to correction

That capability is what we build with you: we work directly in your development chain and in your code to make CRA compliance operational. Three distinct engineering capabilities, forming one cycle:

1 · Industrialise

CI/CD, SBOM & vulnerability detection

We plug CRA security into your development chain: an SBOM (Software Bill of Materials, the inventory of your product's software components) generated at every build, CVE scanning, Dependency-Track, checks built into your CI/CD. We do the integration ourselves; we don't just recommend it.

OutcomeEvery released version is automatically inventoried and checked.

2 · Monitor

Continuous CVE monitoring

A continuous service, not a one-off audit: we monitor the vulnerabilities affecting the components and versions of your products in the field. Every relevant CVE is qualified, prioritised and fed into the CRA handling process.

OutcomeYou know quickly whether a new CVE really affects your product, and what to do about it.

3 · Fix

Bringing the code into compliance

When a compliance gap or a vulnerability requires changing the software, we work on the code, the dependencies, the architecture and the build chain. We support or carry out the fixes, all the way into your development cycle.

OutcomeWe don't stop at the finding: we go as far as the technical fix.

Every shipped fix feeds back into the chain: SBOM regenerated, monitoring up to date. The cycle continues.

A recent example: for a client, we implemented the security recommendations: encryption of persisted data and network communications, token-based API authentication, integration of SBOM scanning into its CI/CD pipeline, then publication of the SBOM to the continuous CVE monitoring system. Its quality department verified that these implementations met its requirements.

Assess my product → Get a first read →

One simple offer: your industrialisation plan

For software vendors, makers of connected products (industrial equipment, connected devices and medical technology) and integrators selling on the European market.

One principle: your software chain already exists (build, continuous integration, deliveries). We connect what the CRA requires to it, with no parallel chain, and everything we install stays with you.
A single fixed-fee offer to get started: your industrialisation plan, a snapshot of your software chain and its levers, costed, result within 1 week.
What follows, point by point: each lever in the plan is costed separately, and you stay in control.

The industrialisation plan, fixed fee

Within a week, with your technical team, we establish:

your scope: product in or out, your role (manufacturer, importer, distributor), your class;
the obligations that follow and their timeline (reporting from 11 September 2026, Annex I in December 2027);
the state of your chain (build, continuous integration and delivery, releases): what can be connected as is, what is missing;
the prioritised list of levers to pull, your industrialisation plan, costed point by point.

Several products? We start from the pilot product, the one you choose, and the plan estimates the effort and budget for the others.

Deliverable: the written, costed industrialisation plan. It is a snapshot of your software supply chain and the levers you can pull to gain performance: reproducible releases, a reliable inventory, a fast response to a vulnerability. Gains that hold with or without a regulation. You remain free to pull them with us, with your team, or both.

Indicative budget

Stage	Budget	What you get
First read	Free	One hour for a first framing: likely scope, likely class, next steps
Industrialisation plan	CHF 6,000	Snapshot of your software chain and a prioritised, costed action list, for one pilot product
Implementation	From CHF 18,000	Development chain tooled up, about four weeks if your continuous integration already exists
Support	From CHF 1,800 / month	Team follow-up through the first year, vulnerability watch included, 12-month commitment

The plan is not billed if your product is out of scope; it is deducted from implementation if you continue. A real incident report is billed by the day.

The necessary building blocks (component inventory, vulnerability detection, procedures, fixes, secure updates and team training) are selected and costed in your plan. For the fixes, we implement the required features or support your team in designing them, your choice.

You choose what we deliver and what your team keeps; everything is set in the quote, with no surprises along the way. The technical detail of these work packages is described further down, for your developers.

And what you fund does not end with the engagement: the automatic inventory, the monitoring, the procedures and the good practices stay with you and serve your teams at every release. The CRA sets the deadline; the software quality stays with you.

Get a first read → Assess my product →

Compliance becomes an engineering problem

For your technology leadership, the questions become very concrete:

Do you know exactly what is inside every released product?
Can you identify the affected versions when a new CVE appears?
Can you trace them to deployed products and to your customers?
Do you have a written vulnerability-handling process?
Can you produce the required evidence continuously, without manual work?

That’s why we don’t approach the CRA as a paperwork exercise. Embedded engineering, continuous integration and software quality are our daily craft: we start from your products, your source code and your build chain, not from a questionnaire.

For your developers, it fits into the work they already do

We integrate the foundations into your existing engineering workflow, with no parallel chain: the SBOM comes out of your build (CycloneDX or SPDX), the CVE scan runs in your pipeline, false positives are handled with VEX, Dependency-Track monitors continuously, a published security.txt and a disclosure channel keep you reachable, and the PSIRT process (dry-run included) is written with the team that will run it. That also covers the components package managers miss, including bare-metal and RTOS firmware.

And rather than taking our word for it, judge us on the work: our article SBOM and CVE auditing in CI/CD for bare-metal embedded describes the method, our take on the CRA explains why we start from engineering, our projects show where it comes from, and the freely available CRA & Dev wiki documents the tools that secure software.

Let’s talk

One hour, free and with no strings attached: we read your situation together, and you leave with a first idea: likely scope, likely class, next steps. The written, costed industrialisation plan remains the job of the fixed-fee week.

Get a first read →

Phone: +41 76 639 30 70

ADNT Sàrl, Rue du Pont 8, 2400 Le Locle (canton of Neuchâtel). We travel across French-speaking Switzerland: Neuchâtel, Vaud, Jura, Bern, Fribourg, Geneva.

References

Regulation (EU) 2024/2847 (Cyber Resilience Act): official text on EUR-Lex
The regulation explained and the reporting obligation (Article 14), on cyberresilienceact.eu
Commission guidance of 27 July 2026 (Decision C(2026) 5252): scope, open source, substantial modification, support periods, with an analysis
Does the CRA apply to Swiss companies?: our article on the Swiss case
CRA & Dev: our technical wiki, open access