A CRA implementation roadmap for product engineering teams
Start with one product and one release. Establish its scope, produce a software inventory, assign vulnerability and reporting owners, then connect every remediation task to evidence that the team can reproduce.
Define a release you can actually inspect
A programme becomes difficult to estimate when “the product” means every device, application and service the company has ever shipped. Choose a representative build and record its firmware, companion software, dependencies and necessary remote services. Note who can reproduce that build and which parts belong to suppliers.
The principal CRA requirements apply from 11 December 2027; manufacturer Article 14 reporting obligations already apply from 11 September 2026. Treat reporting readiness as a current workstream, while confirming product applicability and transitional rules with qualified counsel.
Build the work around five outputs
- A product boundary diagram with versions and responsible teams.
- A generated SBOM linked to the selected release.
- A security contact and an intake-to-remediation workflow.
- A reporting runbook with an accountable owner and deputy.
- An evidence index linking requirements, decisions, tests and release artefacts.
Prioritise by risk and dependency
Our suggested planning method is to record the risk, affected product versions, available evidence, owner and blocking dependency for each gap. A short task list with accountable owners is easier to execute than a score alone.
Separate work that can be completed in the repository from decisions requiring product management, supplier input or regulatory interpretation. A developer can change a pipeline; they cannot independently decide the manufacturer’s entire support commitment.
Use acceptance criteria your team can demonstrate
| Work item | Evidence of completion |
|---|---|
| SBOM automation | A clean build produces a versioned inventory; its limitations are documented. |
| Disclosure intake | A test report reaches the responsible team and gets a tracked acknowledgement. |
| Reporting workflow | A tabletop exercise identifies who submits, what they need and where records are stored. |
| Remediation | A reviewed change, test result and affected-release record are linked. |
Keep the programme in the delivery workflow
Review readiness when a product boundary, dependency, security assumption or support commitment changes. Make the evidence update part of the release checklist, with a named owner.
Dotgrey Continent’s assessment starts with one agreed product/build and produces initial working artefacts plus a fixed-price proposal for the remaining scope. It does not replace the manufacturer’s conformity decision.
Official sources and references
The suggested workflows are Dotgrey engineering recommendations. Official texts determine obligations; applicability must be checked for each product.