For a manufacturer with a single product, CRA compliance is a defined project with a clear endpoint. For a manufacturer with a portfolio of products, multiple product versions in simultaneous support, and a development pipeline producing new releases, compliance is a continuous operational function. The tools, processes, and disciplines required are different in both scope and character.
This post addresses the structural and operational questions that arise when CRA compliance is not a project to be completed once, but a programme to be run across an entire product portfolio.
Why Portfolio Compliance Is Different
The CRA's requirements apply per product, not per organisation. Each product with digital elements requires its own risk assessment, its own technical documentation, its own conformity declaration, and its own vulnerability handling records. A manufacturer with twenty products has twenty sets of these obligations, each at a different stage of the product lifecycle, each with different risk profiles, and each with different essential requirement applicability depending on product class.
The challenge is not that any individual product is difficult to manage. The challenge is that the same rigour must be applied consistently across all of them, with the same evidence standards, by teams that typically have competing priorities.
Structuring Compliance Across Product Lines
The most reliable approach to portfolio compliance is to treat the essential requirements as a structured assessment framework and apply it consistently to every product, adapted for the specific characteristics of each product class.
Annex I of the CRA lists 21 essential requirements across two categories: security properties of the product itself, and vulnerability handling obligations. Not all requirements apply with the same weight to every product, but all must be addressed and documented for every product in scope. The practical implementation is a product-level assessment against each requirement, with evidence attached.
Structuring this by product line rather than by requirement has two advantages. First, it makes it possible to delegate assessment work to the teams who know each product best. Second, it produces a compliance status that is visible at the product level, which is the level at which market surveillance authorities and notified bodies will examine it.
Version management is a further complication. When a product is updated, the question is whether the update changes the risk profile sufficiently to require a revised assessment. The regulation does not set a bright line, but updated firmware that introduces new network interfaces, changes authentication behaviour, or adds new data processing almost always requires a review. A portfolio compliance process must have a defined trigger for reassessment when products change.
Translating Essential Requirements Into Guided Assessments
The essential requirements in Annex I are stated at a level of abstraction that is necessary for a regulation but insufficient for an engineer. “Products shall be designed to limit attack surfaces” is a principle. The assessable question is: what specific design decisions has this product team made to limit attack surfaces, and what is the evidence that those decisions were implemented?
Translating abstract requirements into domain-specific assessment questions is the work that makes compliance actionable. For a connected consumer device, reducing attack surfaces means disabling unused network services, closing unnecessary ports, and requiring authentication on all management interfaces. For an industrial controller, it means isolating process control interfaces from corporate network access and enforcing cryptographic authentication on firmware updates.
A well-structured assessment process builds these domain-specific questions into the assessment template for each product class, so that the engineers completing the assessment are answering concrete questions about their specific product rather than interpreting regulatory text.
Using Maturity Scoring to Understand and Track Progress
A binary pass/fail assessment against the essential requirements tells you whether a product is compliant or not. It does not tell you how far away it is from compliance, which gaps are the most significant, or whether the programme as a whole is moving in the right direction.
Maturity scoring addresses this by assigning a graduated score to each essential requirement based on the quality and completeness of the controls in place. A product with no formal risk assessment scores differently from one that has an informal process, which scores differently from one that has a structured, documented, and regularly reviewed process aligned to a recognised standard.
For portfolio management, maturity scoring produces several useful outputs. It allows compliance managers to prioritise remediation work by identifying which products and which requirements have the largest gaps. It provides a progress metric that can be tracked over time and reported to management. And it creates a basis for resource allocation across the portfolio: products closer to compliance require less investment than those at early maturity stages.
Maturity scoring does not replace the binary compliance assessment required for the conformity declaration. It supplements it by providing the visibility needed to manage compliance as a programme rather than a checklist.
Collecting and Managing Evidence Consistently
The technical documentation required under CRA Annex VII must be produced and maintained for each product. The documentation is not a single document but a structured collection of evidence: risk assessments, threat models, test results, vulnerability records, patch histories, and declarations of conformity.
Across a portfolio, consistent evidence collection means that the same types of evidence exist for every product, that the evidence is stored in a controlled location with version history, and that the connection between a specific piece of evidence and the essential requirement it addresses is explicit and navigable.
The failure mode to avoid is scattered files. Risk assessments in one shared drive, test results in CI/CD pipeline logs, vulnerability records in email threads, and declarations of conformity in a folder that nobody has reviewed since the initial certification. When a market surveillance authority requests the technical documentation for a product, or when a serious vulnerability is discovered and the manufacturer needs to understand the product's full risk profile, scattered evidence is the difference between a controlled response and a crisis.
The Value of Audit Trails and Role-Based Collaboration
Compliance programmes require multiple people to contribute to assessments, review evidence, and make decisions about conformity. Audit trails record who assessed what, when they assessed it, and what decision was made. This matters for two reasons.
First, it demonstrates to market surveillance authorities that the compliance process is not a document exercise but an organisational process with real accountability. Second, it supports the internal governance needed to maintain compliance over time. When an engineer leaves, the assessment history does not leave with them. When a product is audited two years after its initial conformity declaration, the evidence of what was done and why is retrievable.
Role-based access in a portfolio compliance tool ensures that product engineers can contribute to assessments without having access to modify compliance records for other products, and that compliance managers can oversee the whole portfolio without needing to be the bottleneck for every individual assessment.
How SMEs Can Reduce Compliance Cost While Staying Regulator-Ready
The compliance overhead described above is real, but it is not proportional to the number of products in the portfolio. A well-structured assessment framework, reusable evidence templates, and a centralised compliance tool reduce the marginal cost of adding each new product to the programme significantly. The fixed investment is in the structure; the variable cost per product decreases as the process matures.
For SMEs, the most important discipline is to start with structure rather than adding it later. A compliance programme built in a shared spreadsheet will eventually need to be migrated to a controlled system, and that migration will happen under time pressure. Starting with controlled, auditable, role-based tooling costs almost nothing extra at the beginning and avoids a significant re-work cost later.
The December 2027 deadline is the hard compliance date for the full portfolio. But the September 2026 deadline for vulnerability and incident reporting obligations arrives first. Organisations that build a structured portfolio compliance programme now have time to both meet the September 2026 obligations and position the broader programme for the December 2027 conformity requirements.