Insights · cetome.com
Five objectives: a framework to simplify CRA compliance
The Cyber Resilience Act sets out its essential requirements as two lists in Annex I, supported by obligations spread across several articles and further annexes. That structure suits a legal text. It does not suit a product team trying to work out what to build, in what order, and who is responsible.
In our work with manufacturers, we restructure the regulation around five objectives that follow the life of a product. Everyone from engineering to the board can understand them, and every CRA requirement has a place in one of them.
The five objectives
- Create secure products Security starts before the first line of code. This objective covers the risk assessment, including threat modelling, and the cyber security requirements that follow from it, such as encryption, data protection and access control. It continues through the secure development lifecycle, the choice of secure hardware and software components, a secure architecture across cloud, APIs and the networks the product joins, and requirements placed on suppliers of components and services.
- Make the release of products secure A securely designed product can still reach the customer in an insecure state. This objective is security by default: secure provisioning, secure boot, and a configuration that protects users who never open the settings.
- Keep products secure Obligations continue for the whole support period. This is the largest objective and the one where most manufacturers have the least in place: a coordinated vulnerability disclosure policy, vulnerability management, secure updates, threat intelligence, security monitoring and incident management. It also includes the properties the product must keep in the field, namely data protection and resilience, including degraded modes and protection against denial of service.
- Create relevant documentation Compliance is demonstrated on paper. Product documentation brings together the software bill of materials, the description of cyber security capabilities, data flows, test plans, the compliance assessment and the market access requirements. Alongside it sits risk management: risk levels, risk acceptance decisions and issue tracking, kept current as the product and its threats change.
- Don’t release products with known exploitable vulnerabilities This is the gate before every release, including updates. Security assurance combines automated and manual testing, and certification where relevant, to confirm that what ships is free of known exploitable vulnerabilities, and that any remaining known vulnerability has been analysed and its risk accepted knowingly.
Governance holds it together
Across all five objectives sits cyber security governance: the strategy, policies, processes and standards that make product security repeatable. Without it, each product team solves the same problems separately, and compliance depends on individuals.
Where to start
Twenty building blocks cannot be built at once. Five come first, because the others depend on them.
- Cyber security governance defines who decides and how.
- Risk assessment determines which essential requirements apply to each product.
- Cyber security requirements translate the risk assessment into something engineers can build.
- Vulnerability management supports the reporting obligations, the first to apply, from September 2026.
- Product documentation is the evidence for the declaration of conformity.
A manufacturer with these five in place has a defensible position and a clear view of what remains.
How to use the framework
As a gap analysis. Rate each building block per product or business unit, and the priorities become visible.
As a roadmap. Sequence the blocks by dependency and by product launch dates, and the budget discussion becomes concrete.
As a common language. Engineering, compliance and management rarely describe the CRA in the same terms. Five objectives on one page give them a shared picture.
Summary
| Objective | Building blocks | Start here |
|---|---|---|
| All objectives | Cyber security governance | Yes |
| 1. Create secure products | Risk assessment; cyber security requirements; secure development lifecycle; secure components; secure architecture; supply chain requirements | Risk assessment; cyber security requirements |
| 2. Make the release of products secure | Security by default | |
| 3. Keep products secure | Coordinated vulnerability disclosure policy; vulnerability management; secure updates; threat intelligence; security monitoring; incident management; data protection; cyber resilience | Vulnerability management |
| 4. Create relevant documentation | Product documentation; risk management | Product documentation |
| 5. Don’t release products with known exploitable vulnerabilities | Security assurance |
If you want to assess your products against the framework, use CRAted, see how we approach CRA readiness or talk to us.
About cetome
cetome is an independent product cyber security advisory, in London and Lyon since 2017. We help connected-product manufacturers ship secure products on time, in compliance with the Cyber Resilience Act, RED and other regulations, and we publish our research and tools for the community.
This article: https://cetome.com/insights/cra-framework-five-objectives/ · More insights: https://cetome.com/insights/ · Talk to us: https://cetome.com/contact/