CRA · product security
Manage product security from design to end of support
We help device and software manufacturers connect CRA requirements with their teams’ work, release documentation and product maintenance.
Who we work with
For manufacturers of connected devices, embedded and IoT products, and software products with digital elements. We support R&D teams, product owners, and people responsible for quality and security.
A new release, an architectural change, a review of dependencies or plans for long-term support are good starting points. We assess the applicability of the CRA and the organisation’s roles for each specific product.
What we organise across the lifecycle
Each stage produces information needed for the next release. We help establish who prepares it, when it is reviewed and how the basis for a decision can be traced.
- Scoping: product families, roles, system boundaries and preparation priorities.
- Design: threats, risks, security requirements and architectural decisions.
- Development and releases: components, SBOMs, test results and evidence identified for a specific version.
- Suppliers: information on dependencies, updates, vulnerabilities and support periods.
- Maintenance: receiving reports, assessing vulnerabilities, fixes and reporting readiness.
- Changes and end of support: risk reviews, documentation updates and communication with users.
Three ways to get started
Assessing one product family
A review of current practices and materials. Outcome: a gap map, priorities and the scope of further work.
Establishing a process
Working together on responsibilities, release documentation and vulnerability handling. Outcome: a process and a set of templates for the team.
Supporting subsequent releases
Reviews of changes and evidence at agreed intervals. Outcome: continued organisation as the product evolves.
We agree the scope, criteria and working arrangements before starting. A readiness assessment does not constitute certification or a product conformity decision.
Evidence linked to a specific release
An SBOM is an inventory of software components. Its value increases when it can be linked to a product version, vulnerability assessment, test results and release decision.
We organise the chain: requirement → action → evidence → owner → review. This tells the team what to update when a component, architecture or risk changes.
CRA: preparation is already under way
Reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security apply from 11 September 2026. The main CRA obligations will apply from 11 December 2027.
The deadlines and scope are described by the European Commission — Cyber Resilience Act. We will assess what they mean for the product and organisation and identify priorities for managing CRA compliance.
Cryptography is part of product decisions
Long support periods require an understanding of where a product uses cryptography and how it can be changed. Update signatures, communications and key management connect the security of the current version with future changes.
Related websites
Additional resources and initiatives on working with product information throughout its lifecycle. Each website describes the content and features currently available.
nis2cra.com
Resources, analyses, qualification tools and initiatives on NIS2, the CRA and OT cybersecurity.
cratrace.com
cratrace — a project for managing information and evidence throughout the product lifecycle in the context of CRA requirements.
Let’s discuss your product family
Tell us what you manufacture, the product’s stage of development and the area you want to address. We will exchange technical documentation once the scope is agreed.