Products, versions & deployments

Every Resilic feature keys off the product register: versions carry SBOMs, deployments locate fielded machines, and the support period feeds Annex II user information, the technical documentation, and the customer evidence pack.

The product page

A product page opens with a status strip: versions, deployments (and how many an Edge scanner verified), versions with machines in the field but no SBOM, actively exploited findings with the time of the last correlation (and, if an Article 14 report is open, its next deadline), the support period’s end with the time left, and the classification — each with its signing state: signed, not signed or review again. Every cell leads to where its number comes from. Below it sit three tabs; the chosen one is part of the address (?tab=), and back always returns to the register. The numbers are computed live on every visit, never cached.

Status shows the product’s readiness as a list: technical documentation, risk assessment, AI systems, security passport and customer evidence pack, each with a dated state (not started, draft · 3 of 9 sections, approved on …) and one way in. On a new product the list leads with the first three steps: add a version, upload an SBOM, record deployments. Below it, recent activity: the operations the audit log recorded on this product, its versions, SBOMs and deployments — who, what, when.
Versions & machines is the daily work. Collapsed, each version row says what counts: SBOM state, number of machines and the worst open finding (CVE, exploited or score, +n more); the worst version sits on top. Expanded, the deployments follow (filter and pages from 25) and the SBOM with the count of components lacking an end-of-life date. Forms appear only on request: Add version, Record deployment, Request from supplier, an end-of-life date per component.
Master data holds the facts set once, as text: role, product family and product kind in one group, the support period and the classification each as their own. Every group has one Edit and one Save. Signing stays a separate step; a signed group shows its stamp (who, when, what the evidence is for) and warns before editing re-opens the signature.
Support period: record the start/end dates, expected use time, and the determination rationale (CRA Article 13(8) expects the determination, not just dates). A derivation assistant drafts the rationale from the dimensions that bound a support period — usage context, expected field lifetime, component availability (the earliest component end-of-life from the SBOM), update capability, and supplier commitments — applying the five-year floor and the minimum principle. It never sets your dates: you review, edit, and sign the determination, keeping an audit-ready record of who attested it and when. Editing the support window or rationale re-opens it for signing. If something the signed determination rested on later changes — a new actively-exploited match, a component reaching end-of-life before the window, or a revised SBOM — Resilic flags it for re-review while keeping the signed record intact.
CRA register details: record your role for each product — manufacturer (the default), importer, or distributor, since it changes which CRA duties apply — and an optional product family to group related products in the register. These are register facts you maintain, not a conformity determination.
Product kind: a series product (the default) or a custom product built to one customer’s specification, with order number, customer, handover date and platform — see Custom products & projects. Product vocabulary with the same CRA duties either way.
CRA classification: pick the product’s category — default (self-assessment), important (Annex III Class I or II), or critical (Annex IV) — write the reasoning, and sign it, so you keep an audit-ready record of a self-classification an authority may spot-check. A guided classification wizard helps: match your product’s core functionality to the Annex III/IV categories (captured verbatim from the regulation) and it suggests a tier and drafts a justification you review, edit, and sign — integrating a listed component does not by itself make the product important or critical (Article 7(1)). Editing the category or justification re-opens it for signing. If the CRA category lists (Annex III/IV) are later amended, Resilic flags your signed classifications for re-review — your signed record stands until you re-review it against the current lists and re-sign. You own this assessment; it’s a readiness aid, not a conformity determination.
Machine identity & version state: for each deployment you can record the serial number from the nameplate and an asset ID — a stable identifier that survives updates and component swaps, such as your inventory number, an AAS globalAssetId or an OPC UA ProductInstanceUri. The serial number is unique per product, so a security advisory can be followed down to the single machine at the customer. Both appear on the affected machines of a vulnerability, on the customer page and in the customer evidence pack; in the CSV fleet import the columns are SerialNumber and AssetId (a serial number that is already taken skips the row). For each machine Resilic also shows what the registered version rests on: As of … is a reported version — recorded in the register, not read from the device — while Version verified means an Edge scanner read the same version from the mapped device. If the version read differs, the row shows the observed one. These are register facts for your own traceability: CRA Annex II asks for information enabling the unique identification of the product; which identifier you use is your choice. Resilic stores the identifier as entered and does not validate it against AAS or OPC UA.
Customer evidence pack: each deployment row offers a downloadable security evidence pack and an expiring share link for your customer.
Security passport: a stable public page per product carrying the CRA Annex II user information — rotate or revoke it from the product’s page.