The EU Cyber Resilience Act (CRA) changes the baseline for products with digital elements. Security can no longer be treated as a post-launch hardening exercise, an optional enterprise feature, or a matter left entirely to customers. For many hardware and software products placed on the EU market, cybersecurity must be designed, documented, maintained, and evidenced across the product lifecycle.
For founders, product leaders, designers, and engineering teams, the important question is not simply, “Does the CRA apply to us?” It is: can we demonstrate that our product is secure by design and remains supported when vulnerabilities emerge?
What the CRA is trying to solve
Modern products are deeply connected: SaaS applications rely on third-party libraries, smart devices expose network services, desktop software auto-updates, and a vulnerability in one component can affect thousands of organisations. Yet product security practices vary widely.
The CRA establishes horizontal cybersecurity requirements for products with digital elements made available in the EU. Its purpose is to reduce known exploitable vulnerabilities, improve transparency, and make manufacturers accountable for security throughout a product’s expected support period.
In practical terms, the regulation moves cybersecurity from a technical aspiration to a market-access requirement.
Does your product fall in scope?
The CRA broadly covers products with digital elements, including software and hardware that is placed on the market separately or as part of a connected system. This can include:
- Web, desktop, and mobile software distributed to EU users or customers
- Connected devices, sensors, gateways, routers, and consumer IoT products
- Firmware, operating systems, and embedded software
- Developer tools, libraries, and commercial software components
- SaaS products where the supplied product itself includes digital elements subject to the regulation
The exact assessment depends on how the product is supplied, who acts as the manufacturer, and whether a specific exemption applies. Open-source software developed or supplied outside commercial activity may receive different treatment, but open source incorporated into a commercial product remains highly relevant to the product’s security obligations.
This is why an early scope assessment matters. It should map the product, its distribution model, its technical dependencies, and the organisation that places it on the EU market.
The obligations in product language
The CRA’s legal requirements translate into a familiar product-security operating model.
Secure-by-design and secure-by-default
Use safe default settings, least privilege, access control, encryption where appropriate, and a deliberately reduced attack surface.
Vulnerability handling
Establish a process to receive reports, triage issues, remediate them, communicate clearly, and issue security updates.
Secure lifecycle management
Maintain the product during its support period rather than treating launch as the end of security responsibility.
Technical documentation
Keep evidence of architecture decisions, risk assessments, testing, dependencies, known limitations, and security controls.
Software transparency
Maintain an accurate software bill of materials (SBOM) and understand the components that enter every release.
Conformity assessment and CE marking
Determine the applicable assessment route, complete the required documentation, and meet market-access requirements before placing the product on the market.
Incident and vulnerability reporting
Prepare for required notifications through defined internal ownership, escalation paths, and evidence collection.
The most consequential shift is operational: a security issue is no longer only an engineering ticket. It can trigger customer communications, regulatory reporting, release coordination, supplier engagement, and executive accountability.
A practical compliance roadmap
Teams do not need to build a perfect compliance programme in a single quarter. They do need a credible, repeatable system that links product decisions to evidence.
1. Establish ownership and scope
Name a product-security owner with authority to coordinate engineering, legal, operations, support, and leadership. Then create a scope register for each product line:
- Product name, version, market, and distribution route
- Legal manufacturer and relevant economic operators
- Data flows, network interfaces, privileged functions, and user roles
- Components, services, suppliers, and open-source dependencies
- Expected support period and end-of-support policy
This register becomes the foundation for risk assessment, documentation, and release governance.
2. Build a threat model into discovery
Threat modelling should start before implementation - not after penetration testing. For each important user journey, identify assets, trust boundaries, likely misuse paths, and high-impact failure modes.
For example, a compliance SaaS may store assessment evidence and generate reports. Its threat model should consider tenant isolation, role escalation, insecure file uploads, API token exposure, report-sharing links, and supply-chain risks in document-generation libraries. Each risk should result in a design decision, a security control, or an explicit acceptance decision with an owner.
Good threat modelling is a design practice as much as an engineering practice. It helps teams decide what should be visible, configurable, logged, or impossible by default.
3. Make the SBOM part of delivery
An SBOM is not a spreadsheet produced just before an audit. It is a living inventory of the components in a specific release.
Automate generation from your build pipeline where possible, use standard formats such as CycloneDX or SPDX, and retain SBOMs alongside release artifacts. Enrich them with component versions, licences, suppliers, hashes where useful, and known vulnerability status.
The operational payoff is immediate: when a critical library vulnerability is disclosed, your team can identify affected versions and customers far faster than by manually searching repositories.
4. Define a vulnerability response service
Create a documented vulnerability-handling process before the first report arrives. At minimum, define:
- A public security contact or reporting channel
- Triage severity criteria and decision owners
- Target response and remediation times
- A process for coordinating fixes with suppliers and downstream users
- Security advisory and customer-notification templates
- A route for regulatory reporting when applicable
- Evidence retention for decisions, timelines, patches, and communications
Treat this like incident response: rehearse it. A tabletop exercise around a dependency compromise or authentication bypass will expose gaps in access, ownership, and communication plans.
5. Turn controls into release gates
Security becomes durable when it is built into the delivery system. Add proportionate gates such as:
- Dependency and secret scanning in CI
- Automated tests for authorization boundaries and critical workflows
- Code review requirements for high-risk changes
- Signed builds and protected release pipelines
- Security review for new integrations, admin functions, and data exports
- SBOM generation and release-artifact retention
- A documented decision when a known risk is accepted
The goal is not to block shipping with ceremony. It is to ensure that risk-relevant choices are visible, deliberate, and traceable.
Evidence beats intention
Many teams already follow good practices, but cannot show it consistently. CRA readiness depends on making security work auditable.
For every material release, aim to retain a lightweight evidence package:
- Product and security requirements
- Threat model and risk-treatment decisions
- Architecture and data-flow documentation
- Test results and security review records
- SBOM and dependency-vulnerability status
- Release notes, version identifiers, and update instructions
- Vulnerability reports, remediation records, and advisories
This documentation should be usable by the team first. If it only exists to satisfy a future audit, it will drift out of date.
Start with the highest-leverage actions
If you are early in your CRA programme, prioritise these actions in the next 30 days:
- Identify the manufacturer(s) and make a product-by-product scope assessment.
- Produce an automated SBOM for a production release.
- Publish a security contact and write a vulnerability triage procedure.
- Run a threat-model workshop on your highest-risk workflow.
- Define the supported-version policy and who owns security updates.
- Add dependency scanning, secret scanning, and release evidence retention to CI/CD.
These steps create the operational backbone for deeper conformity work. They also make the product more resilient today, independent of the regulatory deadline.
The opportunity behind compliance
The CRA raises the bar, but it also creates a product advantage. Customers increasingly worry how vendors handle vulnerabilities, protect data, manage third-party dependencies, and communicate security events. A mature answer builds trust during procurement and reduces disruption when incidents occur.
The strongest approach is to treat CRA compliance as a product-quality system: design for safe behaviour, maintain a clear inventory, respond quickly when weaknesses appear, and leave evidence behind as the product evolves. Teams that build these habits now will be better prepared for both regulatory obligations and the next real-world security event.
This article is educational content, not legal advice. Confirm your product’s specific CRA scope, classification, deadlines, and conformity-assessment obligations with qualified legal and compliance advisers.