Skip to content
ResilicResilic Docs

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 register

Section titled “The register”

The register lists one row per product with its manufacturer, product kind, support period and the date it was added. Pills above the list narrow it: All, Series products, Custom products and No support period — the last one shows where the Article 13(8) determination is still missing. A demo product carries a Demo badge; its row menu offers Remove demo data, with a confirm step before anything is deleted.

The product page

Section titled “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 a register: one row per version with its SBOM state, the number of machines in the field, the worst open finding (CVE, exploited or score, +n more) and the date it was added; the worst version sits on top. Pills narrow the list to versions without an SBOM, with findings or in the field. Add version sits in the page header. A row opens the version page (see below); back returns to the register.
  • 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.

The version page

Section titled “The version page”

A version has an address of its own (#/products/{id}/versions/{versionId}) — the search, the status strip and links from other pages can lead straight to it, and a reload keeps you there. The page opens with the product trail, a four-cell strip and two tabs; the chosen tab is part of the address (?tab=).

  • The strip says what the version is made of and where it is: the SBOM (format, number of components, signature state, date — or No SBOM when machines in the field have no bill of materials), the machines (how many are active, verified by an Edge scanner, decommissioned), the vulnerabilities (open findings and the worst one, not correlated yet without an SBOM) and the end-of-life picture (components without a date, components whose date has passed).

  • Machines lists every machine of this version as a table: customer, site, serial number, how the registered version is backed (Version verified · date, Observed: x when the device runs something else, As of date for a reported version), the as-built capture and the country. Pills narrow the list to active, verified or decommissioned machines; from six machines a search over customer, site and serial number appears. Record deployment is the page’s header action. Each row’s menu holds the rest: edit the site, country, serial number and asset ID; show the as-built inventory (it opens under the row, one at a time, with its device table, the SBOM revisions and the adoption actions); download the customer evidence pack or copy its share link; decommission the machine (never a delete — the row stays, flagged, with a reactivate path and the evidence pack still reachable).

  • SBOM & components starts with the SBOM’s facts in one block — format, source, signature, integrity hash, and the declarations you make (level of detail, SBOM type, version-bearing component, end-of-life count with the CSV import) behind one Edit. The components follow as a table grouped by what they do in the machine (see SBOMs), with pills for components with findings, actively exploited ones and those without an end-of-life date, and a search from nine components. Own software, PC software and supplier SBOMs are groups of the same list, each with its action on the group row. Each component row’s menu leads to that component’s vulnerabilities, to the component register and to its end-of-life date. Download and Replace SBOM are the header actions.

  • Without an SBOM the tab shows the four ways to one side by side: upload a file, take over a confirmed as-built inventory (named after the machine it came from), request it from a supplier, or build it yourself from a component list. Each starts the flow described under SBOMs.

  • 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, in the language of the UI. 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 in the language of the UI that 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.