The regulation asks what your fleet must be able to say

What the regulation asks

The Cyber Resilience Act (regulation (EU) 2024/2847) applies to "products with digital elements" placed on the European market. If you sell a gateway, a connected unit, a terminal or a controller, you are its manufacturer in the meaning of the text, and its obligations are aimed at you.

• 10 December 2024The regulation enters into force.
• 11 September 2026The reporting obligations apply - this is under way: actively exploited vulnerabilities and severe incidents.
• 11 December 2027All the obligations apply. CE marking at stake.

Four obligations that bear directly on the fleet

Knowing your components, and proving it

Annex I requires identifying and documenting a product's components, by means of a software bill of materials - an SBOM - in a machine-readable format, covering at least the top-level dependencies.

Fixing throughout the support period

Vulnerabilities must be addressed without delay, and fixes distributed free of charge. The support period covers the product's expected lifetime, with a floor of five years.

Reporting fast

An actively exploited vulnerability, or a severe incident, triggers an early warning within twenty-four hours of the manufacturer becoming aware of it, to ENISA and the relevant CSIRT, then a detailed report within seventy-two hours, then a final report. The clock runs from awareness, not from the event - but everything awareness triggers assumes knowing, fast, which machines are affected.

Keeping the documentation

Compliance is demonstrated by documents: risk analysis, bill of materials, vulnerability handling, proof that fixes were distributed.

The real problem is not writing an SBOM. It is knowing what runs.

An SBOM produced when the product is placed on the market describes what you shipped. Three years later, the fleet has received updates, local interventions, boards swapped in the workshop, packages installed by a technician in a hurry. The question the regulation asks on the day an advisory comes out is about the fleet as it is now, not about one version's manifest.

Without an answer to that question, the early warning is written blind: you cannot say whether you are affected, nor on how many devices, nor which ones.

What PipeLinker Hub brings

Each machine's software inventory, continuously

The Linux and Windows agents report the list of installed packages: name, version, architecture, publisher, licence, size, description. On Linux, read directly from the dpkg, apk and rpm databases; on Windows, from the three uninstall locations of the registry - 64-bit, 32-bit, and per user.

Identifiers that actually allow matching

Every package carries a normalised identifier in Package URL format. The name alone is not enough: "openssl" does not mean the same content across distributions, and a backported fix keeps an old version number while fixing the flaw. So the identifier also carries the distribution, its version, and the source package the binary comes from - Debian, Ubuntu and Red Hat publishing their advisories by source, never by binary.

A CycloneDX export, checked rather than claimed

Each machine's bill of materials exports in CycloneDX format, to hand to your matching tool. The check we ran: the document produced for a Debian 13 machine leads Grype to the same 730 vulnerabilities as its direct scan of that machine, with no gap and no excess.

Searching the whole fleet, in one question

This is the question on the day the advisory comes out: who carries this package? The search covers the name as well as the normalised identifier, and therefore finds "libssl3" when you search for "openssl", its source package.

Changes within the second, not at the next morning's wake-up

A package added, removed or updated emits an immediate event. An application installed and then removed within the day is invisible from one daily snapshot to the next; the event arrives within the second.

Distributing the fix, and being able to prove it

Updates are signed, and the agent verifies the signature before installing rather than trusting the server that sends them. The rollout is progressive - canary, test group, 10 %, 50 %, 100 % - and stops on an offline agent or a failed health check. The audit log keeps what was pushed, when, by whom, and onto what.

And on the access side, what can be shown

The regulation asks you to know what runs; it also asks you to know who touched it. The hub keeps what it takes to say so:

• the identity of the person intervening, attached to every session;
• the rights they held, by role, by fleet and by target;
• the audit log: who, what, on which machine, when, for how long;
• revocation, immediate and individual;
• terminal and screen sessions, recorded and replayable;
• all of it kept on your premises, with your own retention.

Why this is worth having in place now

The reporting obligations have applied since 11 September 2026, and they are the most demanding in reaction time. Twenty-four hours for an early warning is not the time to fix: it is the time within which you must be able to say what is exposed. A fleet you can query in seconds makes that deadline workable; a fleet you inventory by hand does not meet it, however serious the team.

• What the fleet's security lets you demonstrate →log, bill of materials, signed updates
• Certificates and keys →one identity per machine, revocable
• Pricing →three offers and a custom one