Product register & support periods
Availability: The product register requires the optional Compliance & Evidence module. The number of active product families is bounded by the quantity in your contract.
The product register gives operational evidence a stable product and version scope. It is separate from billing and separate from deployment: a product family is a manufacturer record, while the contracted quantity only limits how many active families the tenant can create.
Use one Product ID
Use the same stable product_id that appears in your signed Release Manifests.
The console suggests Product IDs and versions already present in signed
releases. This links future release, vulnerability, incident, support, and
evidence records without inventing another product namespace.
The product ID cannot be changed after creation. The customer-facing name can be descriptive, but it is not the cryptographic identity used by a Release Manifest.
Record a reviewed product revision
Each revision captures:
- the manufacturer or other economic-operator role and its rationale;
- the software, hardware, complex-system, and FOSS scope;
- intended purpose, reasonably foreseeable use, operating environment, users, and assets to protect;
- product class, classification rationale, and conformity route;
- standards, declaration, certificate, and technical-document references; and
- support period, expected use, supported versions, upgrade basis, security update references, and end-of-support notification state.
Saving does not edit the previous record. It appends a numbered revision linked to the one it supersedes. Product revision rows and version-support rows are append-only at the database layer and each change is written to the tenant's hash-chained audit history.
undetermined is a valid class or conformity-route value. It means review is
still required. Meshanics does not infer a legal classification from an SBOM,
device type, or deployment configuration.
Support-period review
The product revision records an explicit start and end date, expected use in months, and the manufacturer's rationale. A period shorter than five years is shown with a review warning. The platform does not automatically lengthen or approve the period because expected product lifetime and the applicable CRA analysis remain the manufacturer's responsibility.
Each supported version has its own support window and state:
- supported;
- security updates only;
- end of support; or
- superseded.
When relying on a free upgrade to a supported version, record both the target version and the compatibility and cost basis. A notification marked as sent requires a durable customer reference.
Record market placement separately
Fleet deployment is not treated as EU market placement. Add a placement event only from reviewed commercial or regulatory facts. An event records the product revision, product version, time, market, operator role, reference, and rationale. The version must be declared in the selected product revision.
A new placement must link a signed release and its reviewed change-impact
decision. The API accepts the event only when the release, Product ID, product
revision, version, approved risk assessment, and change decision all match. A
substantial decision can only be used with a substantial-modification
placement event. Historical placement records created before this workflow
remain visible as legacy records without an invented decision.
The current event types are:
- first EU availability;
- subsequent placement; and
- placement following a substantial modification.
Review product risk before a release
Choose Assess risk on a product. Each saved assessment is an immutable, numbered revision linked to the product revision it evaluated. It records the methodology, assumptions, threat or misuse cases, relevant essential requirements, treatment, residual risk, evidence, tests, unresolved gaps, and the reviewer decision.
Only an approved assessment can be used by the release and dependency workflows. Meshanics records the manufacturer's decision and rationale. It does not decide that residual risk is legally acceptable.
Review every signed market release
Choose Review release after a risk assessment is approved. Select the signed release instead of typing its identity. Record which change dimensions were affected, the supporting evidence and tests, and one decision:
- not substantial;
- substantial modification;
- security maintenance; or
- review required.
The decision is versioned per signed release. Recording it does not deploy the release and does not record market placement. Those are separate actions.
Record components, services, and RDPS due diligence
Choose Review dependency for integrated components, external services, remote data processing solutions, and third-party remote functions. The record keeps the supplier and maintainer, product functions and interfaces, security requirements, assurance and certification references, service-level evidence, manufacturer responsibility, due-diligence decision, mitigations, reviewer, and the change that should trigger another review.
This is product scoped. The same service can have a different responsibility or risk boundary in another product.
Review an exact vulnerability finding
Choose Review CVE and select an existing finding. The CVE, artifact, version, and component come from Vulnerability Watch and cannot be retyped in the form. The reviewed record separately captures:
- applicability and reachability;
- VEX status and reference;
- the knowledge source and time;
- the product-placement decision and rationale;
- upstream reporting and fix sharing;
- public advisory and user-notification state; and
- test evidence and the next review date.
Saving another review appends a revision. It does not rewrite the earlier decision.
Link evidence and issue a product dossier
Choose Link evidence to include a signed release manifest, update archive, delivered end-of-support notice, advisory, test result, supplier assurance, VEX document, or technical document. A link records its product revision and version, evidence kind, reference, optional SHA-256, occurrence time, and why it belongs in the product record.
Download preview produces a mutable JSON view of EU CRA profile v2 for only that Product ID and revision. Every readiness row includes its evidence source, freshness, scope, and reviewer state. The dossier includes product revisions, release decisions, dependency reviews, vulnerability reviews, signed Release Manifest archive, linked evidence, and explicit gaps.
When managed issuance is configured, Issue dossier sends those bytes through the sealed evidence pipeline. The action is not shown when the deployment can only provide a mutable preview. Issuance fails closed unless signing, retention-locked storage, external witnessing, and final verification all complete. The issued ZIP can be checked offline with the Meshanics evidence verifier.
What this does not claim
These workflows record reviewed facts, decisions, and references. They do not certify the product, select a conformity route, decide whether residual risk is acceptable, submit to a regulator or CSIRT, or replace the manufacturer's technical documentation.