Every product with digital elements must be free of known actively exploited vulnerabilities at the moment of placing on the market — per individual unit, not per product line. For Swiss manufacturers with long inventory cycles, this decouples the production date from the compliance state: anyone manufacturing in 2026 and shipping in 2028 must guarantee the 2028 patch state on every single device.
What does the per-unit principle in the EU CRA mean?
The Cyber Resilience Act ties the central security obligations to placing on the market — the moment a product is first made available on the EU market (Art. 3(21)). What counts is not the production date, but the state of the individual device at handover to the next economic operator or end customer.
Annex I §2(a) explicitly requires products to be made available "without known exploitable vulnerabilities". Art. 13(8) obligates the manufacturer to "address risks within their responsibility" throughout the support period — at least five years from availability, or the expected service life if longer.
In practice this means: a device manufactured in 2026 that sits in inventory for two years is not automatically compliant in 2028 — even if it was at the then-current security level when produced. New vulnerabilities in software components used in the device can become known between production and shipment. The device must then be updated before placing on the market.
Why does this hit Swiss machinery and embedded manufacturers especially hard?
Swiss industry is disproportionately affected by this rule — for three structural reasons.
Long product development and inventory cycles. Machine controllers, industrial sensors and embedded systems in Switzerland have typical time-to-market cycles of 12 to 24 months, plus inventory that can age one to two years for specialised products. A manufacturer of PLCs or CNC controllers produces in lots and holds configurations that are later shipped customer-specifically.
High software complexity per product. A modern industrial controller contains firmware with dozens of open-source components — crypto libraries, TCP/IP stacks, web servers, bootloader components. In CycloneDX or SPDX SBOMs of typical embedded devices we see between 80 and 400 components. Every single one can receive a CVE disclosure between production and sale.
Third-country manufacturer status. As detailed in our article on the Cyber Resilience Act for Switzerland: Swiss manufacturers must appoint an authorised representative in the EU who retains the technical documentation for 10 years. When market surveillance authorities of an EU member state later draw samples from older shipment batches, it must be demonstrable per serial number which patch state was installed at placing on the market.
How does this work in detail?
Three CRA articles work together here:
| Article | Obligation | Per-unit consequence |
|---|---|---|
| Art. 13(8) | Ensure security risks are addressed during the support period | Patch availability for every shipped serial number |
| Art. 14 | 24h notification of actively exploited vulnerabilities | Know which serial numbers are affected |
| Annex I §2(a) | Placing on the market without known exploited vulnerabilities | Pre-shipping check per unit |
| Annex VII | Retain technical documentation for 10 years | Patch state history per batch demonstrable |
The connection is clear: if the manufacturer does not know which software version is installed on which serial number, neither Annex I §2(a) at the moment of shipment nor a credible Art. 14 notification to ENISA is possible.
What breaks with manual Excel tracking?
In practice we see three typical Excel-based workflows at Swiss SMEs — and all collapse under the per-unit principle.
Variant A: One SBOM per product line. The manufacturer maintains a central SBOM for "Model XY" and updates it on major releases. The problem: when 60 units of Model XY are produced between May and October, the software state differs across each one — bug fixes, minor patches, library updates. The central SBOM is accurate for none of the shipped units.
Variant B: Excel sheet with serial number and patch date. Classic solution: one row per serial number, one column per component, manual entry on patches. We see sheets with 200 rows × 80 columns. Whenever a CVE becomes known, someone has to check which components in which devices are affected. With 50+ devices per month and 300+ components per device, this becomes a full-time job — that nobody has budgeted.
Variant C: "We patch before shipping." Charming in theory, fails in practice for lack of triggers. Without automated monitoring, patch needs only surface at customer order, under time pressure. For specialised machines this is a one-week validation and test cycle — schedule slips become the rule.
Special case: components without supplier SBOM
A related problem: many suppliers — especially from non-EU countries — currently do not release detailed SBOMs. The integrator remains liable. When supplier documentation is missing, manufacturers must demonstrate the component's security themselves: through binary analysis, vulnerability scans or analysis of publicly known vulnerabilities. In practice this means every opaque third-party component creates additional pre-shipping-check effort that explodes under manual processes.
What happens during an audit if the patch state doesn't match?
EU market surveillance authorities (e.g., the Federal Network Agency in Germany, ANSSI in France) can draw risk-based samples from current shipments or from inventory held by EU importers. The check has two stages:
- Conformity check on the individual unit — read software version, check against CVEs known at shipping time. Hit = violation of Annex I §2(a).
- Consistency of technical documentation — if the patch history does not match the actual software version on the device, this is a documentary violation of Annex VII that is independently sanctionable.
Fine ranges run up to €15M or 2.5% of global annual turnover. More common in practice are temporary sales bans, recall obligations and reputational damage — for Swiss machine builders with B2B customer bases these hit harder than the fine itself.
What does a scaling process look like?
A CRA-compliant pre-shipping check for every individual unit rests on four connected steps — all of which can be automated:
1. SBOM generation per serial number. Every device receives its own CycloneDX or SPDX file at the production build with exact component versions. This is standard in CI/CD pipelines using tools like kunnus-scanner.
2. Continuous vulnerability matching. The SBOM is matched against NVD and OSV databases — daily, not ad-hoc. When a new CVE affects a used component, an alert per affected serial number arrives.
3. Pre-shipping gate before delivery. At every shipment, the SBOM tied to the serial number is checked against the current CVE state. If the check finds an open vulnerability, shipment is blocked until either the patch is applied or a documented risk assessment exists.
4. Audit trail per unit. Every action — SBOM generation, CVE match, patch application, pre-shipping check — is logged with timestamp and responsible person. This is the technical documentation Annex VII requires.
When Annex I §2 cannot be met 1:1
Complex industrial systems — elevators, large machinery, long-lived embedded platforms — often run on architectures designed before the CRA entered into force. Certain Annex I requirements may be technically disproportionate there. In such cases the CRA permits alternative or compensatory measures such as network segmentation or defence-in-depth — provided the overall security level is maintained and the rationale is documented in the technical documentation. What counts as "appropriate" compensation is not yet conclusively defined in current guidelines; clean, traceable documentation of the assumptions made is therefore central.
Manual implementation of the four steps is still feasible for a single-digit product portfolio. For a mid-sized Swiss product portfolio of 50–80 devices and 300+ components per device, the effort typically rises to 3–6 full-time staff annually — with a documented savings potential of 60–75 % compared to an automated SBOM and vulnerability pipeline. The error rate in the pre-shipping check additionally rises with every variant level.
Which steps make sense now?
For Swiss manufacturers with inventory and EU export, three actions are time-critical.
Take stock of current inventory. Which products sit on the shelf today that might be shipped after September 2026 or after December 2027? Which SBOM data exists for these devices — and at what granularity (product line vs. serial number)?
Build a per-serial-number-capable SBOM pipeline. The next production lots should now be built with an individual SBOM per unit. This is not only CRA compliance, but also a prerequisite for credible Art. 14 notifications from September 2026.
Integrate a pre-shipping gate into the logistics process. Before every EU shipment, a technical check should compare the CVE state against the serial number. In Kunnus, this check runs as an automated workflow before every shipment release.
A free CRA readiness assessment shows in a few minutes whether your current process covers the per-unit principle — and where the gaps between production and shipment lie that become problems at the first audit.
Frequently asked questions
Does the per-unit principle also apply to already shipped devices? No. The CRA applies to placing on the market. Already shipped devices are not retroactively affected — as long as no substantial modification (Art. 3(40)) occurs that triggers re-assessment.
What counts as a "known exploited vulnerability" per Annex I §2(a)? CVEs actively exploited in the wild, as listed for example in the CISA Known Exploited Vulnerabilities Catalog or comparable ENISA lists. Theoretical vulnerabilities without proven exploitation are subject to less strict requirements — but still fall under the general vulnerability management process.
We ship to an EU importer, not directly to end customers. Who bears the per-unit risk? Both. The EU importer must check before market placement that the individual device is compliant (Art. 19). In practice, from 2027 onwards EU importers increasingly require SBOM and patch evidence per shipment as a condition for acceptance.
Are there reliefs for micro and small enterprises? The SME reliefs in Art. 33(5) concern the form of documentation, not the security requirements themselves. A Swiss SME may submit simplified technical documentation but must still demonstrate per individual unit that no known exploited vulnerabilities were present.
How does this relate to Motion 24.3810 in Switzerland? The Swiss cybersecurity law arising from Motion 24.3810 will likely establish similar principles for the domestic market. Anyone implementing the EU CRA today is already largely prepared for the Swiss regulation.