When a manufacturer has 5 product lines, EU Cyber Resilience Act (CRA) compliance is hard but manageable in a spreadsheet. At 50 variants the spreadsheet starts failing. At 500 variants — typical for industrial OEMs, IoT vendors, and connected-consumer-product manufacturers — compliance without a platform is mathematically impossible. This article explains why multi-product CRA compliance needs a platform strategy, what the platform must do, and how to migrate from manual tooling without losing audit-trail continuity.
Why Per-Product CRA Effort Does Not Scale Linearly
Conformity assessment under the CRA is per-product, not per-company. On the surface this suggests: if compliance for one product takes 100 hours, ten products take 1,000 hours. In practice, the relationship is super-linear — and the reason matters for the platform strategy.
Software composition shared across variants. Most multi-product portfolios share 60–80 % of their software components across variants. The same Linux distribution, the same vulnerability scanner, the same TLS library. If each variant maintains its own SBOM independently, the same component upgrade triggers the same SBOM update 500 times. With shared component tracking, one upgrade flows to all affected variants automatically.
Vulnerability monitoring cross-product. A CVE in OpenSSL 3.0.x affects every product variant using that version. Without a platform, the vulnerability monitoring effort is multiplied per variant. With a platform, the CVE-to-product matching happens once and produces a fan-out alert.
Documentation patterns repeat. Annex VII technical documentation follows the same structure for every product, but with product-specific evidence injected. Manual documentation rebuilds the same skeleton 500 times. A platform stores the skeleton once and renders variant-specific evidence into it.
Substantial modifications cascade. When a substantial modification is made to a shared component (firmware base, communication stack), every product using that component must re-assess conformity. Without a platform, identifying the cascade scope is a manual cross-reference exercise. With a platform, the cascade is automatic from the dependency graph.
What a Multi-Product CRA Platform Must Do
The minimum capability set for multi-product compliance, derived from the operational reality of 100+ variant portfolios:
Product catalog with variant inheritance. A platform that treats every product as fully independent multiplies effort. The catalog should support product families with shared attributes and variant-level overrides. Adding a new variant to an existing family inherits the family-level evidence (SBOM base, vulnerability handling process, support period policy) and adds only what is variant-specific.
Cross-variant SBOM aggregation. Generate SBOMs per build artifact (CycloneDX or SPDX). Aggregate components across variants to identify shared dependencies, version drift, and end-of-life risks. The "which products contain log4j 2.14.x" question must be answerable in seconds, not days.
Per-product risk classification. CRA Annex III classes vary by product. A connected industrial controller may be Class II while its handheld configuration accessory falls under the default category. The platform must support per-variant risk classes and conformity-assessment-module mapping.
Centralized vulnerability triage with product-aware routing. When a new CVE arrives, the system identifies every affected variant, computes severity in the product context (CVSS adjusted for the product's threat model), and routes the resulting tickets to the responsible product owner. Vulnerability handling is a per-product obligation — the platform must enforce the per-product traceability.
Substantial-modification impact analysis. When a developer proposes a substantial change to a shared component, the platform shows which product variants are affected, which conformity assessments will need to be re-validated, and what the cumulative re-assessment effort looks like.
Audit-ready evidence assembly. On demand, generate the complete technical documentation for any product variant — including the EU declaration of conformity, the SBOM, the test reports, the vulnerability handling process description, and the change history. Without a platform, this assembly is the multi-day exercise that becomes a deal-breaker when a market surveillance request arrives.
Migration: From Spreadsheets to Platform Without Audit-Trail Loss
The most common objection to a platform migration is that the existing spreadsheet-and-shared-drive setup contains years of compliance work that cannot be lost. A structured migration protects this history.
Phase A — Snapshot the current state. Before touching anything, export the current spreadsheets and shared-drive folders into a versioned archive. This is the pre-migration evidence baseline. It must remain accessible for ten years per CRA documentation retention rules.
Phase B — Map the data model. Identify the entities in the existing setup: products, variants, software components, suppliers, vulnerabilities, conformity assessments. Map each to the platform's data model. Most spreadsheet setups have one big "products" sheet with mixed columns; the platform separates products, variants, and components into distinct entities with explicit relationships.
Phase C — Migrate the active portfolio first. Move the currently-shipping product variants first. Historical variants that are end-of-life can be migrated as read-only archives later. This phasing limits migration risk to the products that matter most for ongoing compliance obligations.
Phase D — Parallel operation for 30 days. Run the platform in parallel with the existing setup for 30 days. New compliance work goes into the platform; existing reference data stays accessible in the archive. At day 30, retire the spreadsheet workflows.
Phase E — Lock in the audit trail. Generate platform-level audit logs from day one. Every change to a product, SBOM, vulnerability assessment, or conformity declaration is timestamped, attributed, and immutable. This is the audit-trail substrate that the existing spreadsheet world never had — and it is the most concrete compliance improvement of the migration.
The 80/20 of Multi-Product Compliance
For manufacturers with 50+ variants, four practices deliver 80 % of the multi-product compliance benefit:
Componentize early. Identify shared software components across variants and manage them at the component level, not the product level. SBOM updates, vulnerability assessments, and security patches flow from component to product, not the other way around.
Variant inheritance. Define product families with shared baselines and let variants inherit. Adding the 51st variant to a family takes hours, not weeks.
Automate the documentation render. Technical documentation should be generated from structured data, not hand-edited. When data changes, the documentation regenerates. When the documentation must be regenerated, the data has changed — and the audit trail reflects that.
One source of truth per data type. SBOMs in one system, vulnerabilities in one system, conformity assessments in one system. The cost of duplicate sources is paid in every audit, every market surveillance request, and every product launch.
How Kunnus Handles Multi-Product Compliance at Scale
Kunnus is built for this reality. The product catalog supports variant inheritance with shared component management. SBOM aggregation runs across the entire portfolio with one-click identification of shared dependencies and version drift. The vulnerability engine maps CVEs to product variants automatically and routes tickets to the responsible owners. Substantial-modification impact analysis shows the cascade scope before changes are committed. Audit-ready evidence assembly is one click per product, and the platform-wide audit trail records every change with attribution.
For enterprise manufacturers with 100s of variants, the Kunnus Enterprise platform adds role-based access tiers, multi-team workflows, and integration into existing PLM and CI/CD systems.
Start with our CRA readiness assessment — or talk to our team about a portfolio-scale walkthrough sized to your variant count.