Modeling your machines

Resilic models your fleet as Product → Versions → Deployments (customer × site). How your machines map onto that depends on how you build — and on who, legally, manufactures what.

Who is the manufacturer of what?

Under the CRA, you are the manufacturer of the machine you place on the market — including your own PLC application, HMI project, and integration. The makers of what you integrate — the PLC vendor for its controller and firmware, the OS vendor, the router vendor — are the CRA manufacturers of their products, with their own duties.

Your duty for integrated parts is due diligence (CRA Art. 13(5), applying 11 Dec 2027): when integrating third-party components — commercial, hardware, and open-source alike — verify they don’t compromise the machine’s cybersecurity: the maker’s conformity status, their security-update track record, screening against vulnerability databases. If you identify a vulnerability in an integrated component, you report it to that component’s maker (Art. 13(6)) and address the impact on your machine. The supplier qualification file, the supplier SBOM portal and signed-SBOM verification are Resilic’s tooling for exactly this.

Standard machines (Serienmaschinen)

One product per machine model — e.g. “VL-500 packaging line”. Versions are your software/configuration releases, each with its SBOM. Deployments are the fielded installations across customers, sites and countries. When a vulnerability matches, Resilic answers the impact question directly: which versions, which customers, which sites.

Special machines (Sondermaschinen)

Two honest options:

• One product per machine (“SPM-2026-047 — bottling line”): one version, one deployment. This maps cleanest to the legal reality — each machine placed on the market carries its own technical file and risk assessment, and in Resilic those documents belong to the product. Right for genuinely unique machines.
• Platform as the product, when your specials share a common base: each customer machine becomes a version of the platform with its machine-specific SBOM, deployed at that customer. Less register noise and shared correlation — appropriate when your technical file genuinely is platform-based with machine-specific annexes.

Either way, the component registry is shared across your whole workspace: the same OpenSSL in thirty machines is tracked and correlated once.

What goes into the machine’s SBOM

Everything with digital elements that you ship: controller firmware, router and vision-system firmware, drive firmware, the HMI/SCADA runtime, the operating system build — and your own software (PLC project, HMI application), because you are its manufacturer. Three ways in:

1. Upload a CycloneDX or SPDX file from your engineering toolchain.
2. Manual components for devices that will never have an SBOM file — a router is three fields (name, version, CPE).
3. Request from the supplier via the tokenized portal — with signature verification when the supplier signs their SBOMs.

Where a vendor publishes CPE identifiers (industrial vendors typically do, in their security advisories), record them — CPEs make vulnerability correlation precise.

How deep? The transitive-component question

If an integrated product internally uses a library (say, OpenSSL inside a controller’s firmware), that library is the component maker’s responsibility, not yours. The CRA’s SBOM minimum (Annex I Part II (1)) covers at the very least the top-level dependencies of your product — the controller firmware is your top-level component; what’s inside it belongs to its manufacturer’s SBOM and duties.

Practically, ingesting a supplier’s deeper SBOM (when they provide one) is a useful early-warning option: an actively-exploited library vulnerability then surfaces on your fleet dashboard immediately, often before the vendor’s advisory — at the cost of more “needs review” matches to triage. Top-level is the obligation; deeper is your choice. Resilic supports both and neither creates a duty that isn’t in the regulation.

The customer directory

Every deployment you record names the customer operating that machine. Resilic groups these automatically into a customer directory (Customers page): one entry per customer (case-insensitive on the name — “ACME Pharma” and “Acme Pharma” are the same customer), with their deployment and product counts. Nothing to maintain — the directory builds itself from deployments recorded by hand or via CSV fleet import.

Today the directory is the read-only “who operates our machines” view. It is also the foundation for informing impacted users about vulnerabilities and incidents (CRA Art. 14(8)) directly from Resilic — per-customer notification subscriptions are on the roadmap.

Applicability note

Art. 13 duties (due diligence, SBOM, secure-by-design) apply from 11 December 2027; the Article 14 reporting obligations apply from 11 September 2026. Resilic frames all of this as readiness — it does not certify compliance.