Product register
The register lists the products with digital elements you place on the market. It serves two very concrete purposes: attaching each case to the right product, and having at hand — when time is short — the identifiers the authority asks for.
The fields
| Field | What to enter |
|---|---|
| Name | The commercial name under which the product is placed on the market. |
| Version | The version or version line concerned. If you maintain several, consider one row per line. |
| Serial number · Part number | The identifiers that pin down the unit or the batch. |
| Barcode · MAC | For physical and connected products, where applicable. |
| Category | Your internal classification (or the one relevant under the Regulation). |
| Release | Date of placing on the market. |
| End of support | End of the support period. The Regulation treats this as relevant, and it pays to have it explicit. |
| State | On the market, end of life, withdrawn. |
| Bill of materials | Reference to the product's SBOM: format and origin. See SBOM. |
Importing and exporting CSV
The register can also be populated from a file, which helps when the products already live in an ERP or a spreadsheet. From the Products screen: Export CSV downloads the current list, Import CSV loads one. The exported file re-imports unchanged.
ID,Nome,Versione,Categoria,SN,PN,Barcode,MAC,Rilascio,FineSupporto,StatoAt the end the screen reports how many products were added and how many skipped; skips happen when the subscription is read-only. Every imported product carries the note «importato da CSV» in its history, and the operation leaves a registry row.
Good practice. Before a bulk import, export the existing list: you then have a comparison file to spot duplicates, and a restore point if the content is not what you expected.
Components
For each product you can list the relevant third-party components, with maintainer and licence. This is the list you need when a vulnerability sits upstream: the report to the maintainer starts here, and having the maintainer recorded saves a frantic search for the security channel while the clock runs.
Good practice. Do not replicate the whole bill of materials by hand. List the critical components — those whose defect compromises the security of the product — and connect the SBOM tools for the rest.
Notes and changes
The history is particularly useful on the «end of support» field: if a date is moved, the change stays visible with its reason.
Plan limits
There is no cap on the products you can register: the number of active Managed Products sets the price, not a permission. Account area › Subscription › Plan shows how many you are managing. Archiving a product no longer on the market removes it from the active perimeter and from the count without deleting its history: see Subscription and billing.
How complete it should be
For the setup checklist, four products with complete identifiers are worth more than twenty rows carrying only a name. In a notification, the authority expects to identify the product unambiguously: name, version and at least one stable identifier.
If a case is opened on a product missing from the register, the notification carries a generic product field and in an audit it is a visible gap. Register first, not during the emergency.
The link with cases
Every case states the product involved; the product card shows how many cases are attached to it. That is the view revealing which products give you the most trouble — information that serves risk management as much as compliance.