The Cyber Resilience Act (CRA) is often presented as another compliance layer.
For teams working on embedded systems and connected devices, it is something else entirely.
It formalizes a shift that was already happening: security is no longer a point-in-time activity; it is a continuous operational process.
For many IoT manufacturers, this is not a minor adjustment. It is a structural change.
A regulation that targets real weaknesses
The CRA is not abstract. It directly addresses well-known failure points in connected products:
- lack of visibility on software components
- poor vulnerability tracking over time
- inconsistent patching practices
- unclear ownership of security issues
These are not edge cases. They are common across small and mid-sized manufacturers.
The regulation forces organizations to move from implicit security to explicit, traceable processes.
The core shift: from static compliance to continuous exposure management
Historically, many teams approached security as a validation step.
A product was reviewed, tested, and then shipped.
This model no longer holds.
Under the CRA, the responsibility extends across the entire lifecycle:
- from design
- to deployment
- to post-market maintenance
What matters is no longer whether a product was secure at release,
but whether vulnerabilities are identified, assessed, and remediated over time.
This introduces a new operational burden:
security becomes a living system, not a milestone.
Where embedded teams are structurally disadvantaged
Teams working on embedded systems face a different reality than pure software organizations.
They deal with:
- long product lifecycles
- constrained update mechanisms
- heterogeneous stacks (firmware, OS, third-party components)
In many cases, visibility is partial. Dependencies are not fully mapped.
Vulnerability information is fragmented across tools, advisories, and internal knowledge.
This creates a gap between regulatory expectations and operational capacity.
The CRA does not account for this complexity, but it enforces outcomes regardless.
The SBOM is not the solution, it is the starting point
The regulation implicitly pushes toward better software transparency, often through SBOMs.
However, an SBOM alone does not solve the problem.
It answers a static question:
“What is inside the product?”
The CRA introduces a dynamic requirement:
“What is currently vulnerable, and what is being done about it?”
This requires correlation, prioritization, and tracking over time.
In practice, most teams underestimate this gap.
The real bottleneck: operationalizing vulnerability management
The difficulty is not detecting vulnerabilities.
It is managing them in a way that is:
- consistent
- traceable
- actionable
In many organizations, the process still relies on:
- manual triage
- disconnected tools
- informal communication
This works at small scale. It breaks under regulatory pressure.
What the CRA exposes is not a lack of intent, but a lack of structure.
Tooling is part of the problem
Existing solutions were not designed for this context.
Most vulnerability management platforms:
- assume large security teams
- require significant configuration
- are optimized for cloud or enterprise software environments
They rarely map well to embedded workflows.
As a result, teams either:
- over-engineer their processes
- or bypass tools entirely
Neither approach is sustainable under CRA constraints.
What a compliant system actually requires
A CRA-aligned approach is less about adding controls and more about reducing ambiguity.
At minimum, teams need:
- a clear view of components and dependencies
- a reliable way to monitor vulnerabilities over time
- a structured method to assess impact
- traceability between detection, decision, and remediation
The key is not sophistication.
It is clarity and consistency.
A predictable failure mode
Without changes, many teams will converge toward the same pattern:
They will implement partial processes to satisfy audits,
while keeping their existing workflows unchanged.
This creates a disconnect between:
- documented compliance
- actual security posture
Over time, this becomes a risk in itself.
Conclusion
The Cyber Resilience Act does not introduce new technical challenges.
It makes existing weaknesses impossible to ignore.
For embedded and IoT teams, the question is not whether to comply.
It is whether their current processes can sustain continuous, structured vulnerability management.