Service · Software development

Complying with the Cyber Resilience Act.

The Cyber Resilience Act places the obligation on the product rather than on your organisation: anyone placing software or a connected device on the European market must be able to show how it was built, deliver updates for years, and report within 24 hours. We set up that process for you and build the software that makes it manageable.

24/72-hour reporting obligationFive years of updatesSBOMTechnical documentation
Arrange an introductory call View related work

What the regulation asks of you, and how we contribute.

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. The reporting obligation for actively exploited vulnerabilities and serious incidents applies from 11 September 2026; the remaining obligations apply from 11 December 2027. It affects anyone who places a product with digital elements on the European market, including software, firmware and connected devices, and therefore many more companies than just hardware manufacturers.

What makes the regulation distinctive is its point of focus. A policy alone won't do: it must be demonstrably built into the product itself and the processes around it. The second peculiarity is the time horizon. Committing to at least five years of security updates for a product you release today means that, five years from now, you still need to be able to build, test and deliver that same version. That is a design question about how you split your software and how you manage versions.

We are not a notified body and do not carry out conformity assessments; for that you go to a notified body or perform the self-assessment yourself. What we do is the work underneath: an SBOM generated automatically, a vulnerability handling process that meets the reporting deadlines, and a delivery pipeline that still gets an update to your customer five years on. For organisations that also fall under the Cyberbeveiligingswet, we set up these processes so that they feed each other.

We offer this as a standalone engagement and as part of custom software development. If your product also falls under AI obligations, see AI Act compliance software; if you are working towards certification, see building ISO 27001 compliant software. Reports from outside come through our CVD policy.

Three types of CRA work we take on.

Which option delivers the most value for you depends on what you make and where you currently stand. In the first conversation we will tell you where the gap is greatest.

First engagement · fixed sprint budget

Component inventory and vulnerability process

The CRA requires an SBOM covering at least the top-level dependencies and a process for handling vulnerabilities. We build the generation of that inventory into your build pipeline so it cannot go out of date, and connect the signal sources to it. We then set up the assessment: which finding affects which released version, who decides, and within what timeframe a fix is delivered. That is the foundation the reporting obligation relies on.

SBOM in the build pipelineSignal sourcesImpact assessmentRemediation timelines
Mid-sized project · fixed sprint budget

Reporting process within 24 and 72 hours

Three deadlines, and the clock starts at detection. We document who sends the early warning, where the information comes from and what the notification looks like, and rehearse it once with a realistic scenario. The rehearsal is the part most often skipped and the one that reveals the most: usually it is not the reporting but the assessment that proves to be the slow step.

Early warningNotification templatesRole allocationTabletop exercise
Larger project · fixed sprint budget

Update delivery with a five-year horizon

A channel through which your customer receives a security update, including for a version that has been running for years. Signed packages, a versioning policy that keeps older releases supportable, a rollback option, and visibility of which customer is on which version. For devices in the field, this includes over-the-air updates, with the assurance that a partially failed update does not render the device unusable.

Signed packagesVersioning policyRollbackVisibility in the field

What you have at the end of an engagement.

Working technology plus the documentation you need at the moment a customer or a regulator asks for it.

  • A current component inventory per versionGenerated automatically with every build, including name, version, origin and licence, so you can trace what was in each released version.
  • A reporting process that meets the deadlinesRoles, templates and a decision tree for the early warning within 24 hours, the notification within 72 hours and the final report, with one rehearsal included.
  • A delivery pipeline for updatesSigned packages, a channel that also reaches older versions, and insight into which customer or device runs which release.
  • A vulnerability disclosure policyA public point of contact and a handling route for researchers who find something, in line with what is customary in the Netherlands around coordinated disclosure.
  • Technical documentation that keeps paceDesign decisions, risk assessment, test results and the justification for the support period, kept up to date where the work happens rather than reconstructed afterwards.
  • Handover to your teamWorking sessions with the people who will run it, so the process keeps going when attention moves on to something else.

When you need to act on this now.

Four situations where the gap between what exists and what the regulation requires tends to be widest in practice.

Product in the field

Your software runs on customers' devices

For software you run yourself, an update is a single action. For software installed on customers' devices, it is a chain you must have set up well before you need it. That is almost always the longest-running part of a CRA project.

No overview

You don't know what is inside your product

A signal comes in about a component, and someone then has to establish whether your product uses it, in which version, and whether the vulnerable function is actually called. With an up-to-date inventory that takes minutes; without one, it becomes a round of phone calls that cannot be completed within 24 hours.

Long product lifetime

Your product outlives your release cycle

You release a new version each year and support the previous one for six months. Delivering five years of updates means revising your versioning policy, not patching harder.

Customers ask for it

It is already in your procurement processes

Even before the obligation fully applies, buyers are asking in their terms for a component inventory and agreements on updates. Those who only start producing these when the first request arrives lose days and look weak on the day.

How a CRA project runs with us.

1

Introduction and scoping

We first establish which of your products fall under the regulation and in which category they belong, as that determines whether a self-assessment is sufficient. We also check whether you are a manufacturer, importer or distributor; each role carries different obligations, and that distinction determines half the scope.

2

Gap analysis on the product

We go through the essential requirements against what exists today: which components are included, how vulnerabilities are currently noticed, how an update reaches the customer, and what has been documented. The result is a list of gaps, sorted by how long they take to close rather than by how alarming they sound.

3

Building in sprints

We work in sprints and start with the component inventory, as everything else depends on it. Then the signal sources and assessment, then the reporting process, then delivery. Your own developers take part; this is process work and cannot sit alongside the organisation.

4

Practising with a scenario

A tabletop exercise with a realistic report: a vulnerability in a component you use, actively exploited, reported on a Friday afternoon. We measure how long it takes to reach a reasoned judgement and where it stalled. That is more valuable than any process description.

5

Documentation and handover

We organise the technical documentation so that it is kept up to date where the work happens. Then a handover to your team and, if you wish, a period in which we review the first real reports alongside you.

Frequently asked questions about the Cyber Resilience Act.

What product managers, CTOs and compliance officers ask us before such a project begins.

From when exactly does this apply?
The regulation entered into force on 10 December 2024. The reporting obligation for actively exploited vulnerabilities and severe incidents applies from 11 September 2026; most of the remaining obligations, including the essential requirements and CE marking, apply from 11 December 2027. So the reporting obligation is the first one that will affect you, and it depends on work that cannot be done in a few weeks: you can only report within 24 hours if you know within 24 hours that something affects you.
Does our software fall under this?
Probably, yes. It covers products with digital elements placed on the European market, which is a broad category: standard software, firmware, connected devices, and also standalone software components that are placed on the market independently. There are exceptions, including for products already covered by specific sector legislation and for open source that is not offered commercially. Bespoke work you build for a single client is more nuanced; we assess that case by case.
We only sell within the Netherlands. Does it still apply?
Yes. The regulation applies to products made available on the market of the European Union, and the Netherlands is part of that. There is no threshold based on turnover or company size. There is some relief for small and micro enterprises on parts of the documentation obligations, and the Commission is working on simplified formats. That does not change the reporting obligation itself.
What exactly does the five-year support period involve?
During the support period you must fix vulnerabilities and make security updates available. That period is at least five years, unless the expected lifetime of the product is shorter; if it is longer, support follows the lifetime. Importantly, this concerns security updates and not new functionality. In practice, it mainly affects your versioning policy: you must still be able to build and deliver an older release.
How does this relate to the Cybersecurity Act?
They target different things. The Cyber Security Act, the Dutch implementation of NIS2, focuses on your organisation and your services; the CRA focuses on the product you place on the market. If you are affected by both, the underlying processes overlap, such as risk management, incident handling and supply chain security, but the evidence you need to provide differs. We set up those processes so that you maintain them once and can use them in two places.
Do we have to make an SBOM public?
No. The obligation is that you have one and can provide it to the market surveillance authority on request, in a commonly used machine-readable format and covering at least the top-level dependencies. What you share with customers is your own decision. In practice we see that customers do ask for it, and including it is an advantage in procurement processes, as it shows that the overview exists.
What happens if we don't report?
Enforcement runs through the national market surveillance authority, and the maximum fines in the regulation are substantial: for breaches of the essential requirements, up to fifteen million euros or two and a half per cent of worldwide annual turnover, whichever is higher. In practice, most conversations weigh more heavily on the fact that a product can be withdrawn from the market and that customers ask about it during their procurement process.
We use a lot of open source. What does that mean?
It means you include those components in your overview, and that the vulnerabilities in them become your responsibility once you place the product on the market. The maker of the open-source component does not bear that obligation, unless it is offered commercially. There is a separate, lighter role for open-source stewards, such as foundations behind major projects. For you as a manufacturer, little changes: you are responsible for what you supply.
Do we need an external body for this?
It depends on the category your product falls into. For most products, a self-assessment with technical documentation and an EU declaration of conformity is sufficient. For important and critical categories, such as password managers, firewalls or operating systems, stricter routes apply, sometimes involving a notified body. We determine that category during scoping, as it shapes the rest of the process.
What is realistic if we start today?
The component inventory and signal sources are the quickest to put in place and deliver the most value, because the reporting deadline depends on them. The reporting process itself is mostly about agreeing responsibilities and rehearsing it once. Delivering updates over the long term is the longest-running part, especially if devices are already in the field. We lock that sequence into the gap analysis, so that what becomes mandatory first is also finished first.
Do you also carry out the conformity assessment yourselves?
No. We are not a notified body and we do not issue CE marking. What we deliver is the work underneath: the engineering, process and documentation you need to go into the assessment, whether it is a self-assessment or handled through a third party. In projects where a notified body is involved, we work alongside the partner you choose and provide whatever they request.

Talk to us about the Cyber Resilience Act.

A no-obligation introductory call of half an hour. Tell us what you make and who you supply it to, and we will say where the gap is likely to be and what needs to happen first, even if we end up not working together.

Book an introductory callOr see our work

Edit content