Key takeaways for engineering teams
The CRA is primarily a lifecycle requirement. You will be asked how you prevent vulnerabilities, how you handle them when they occur, and how you deliver updates over time.
In embedded systems, “security by design” is often decided by configuration, integration choices, and documentation boundaries, not by a single feature.
Auditors and customers rarely ask for slogans. They ask for evidence: versioned releases, known assumptions, integration constraints, and a repeatable vulnerability response path.
SBOM is not just a list. It is only useful if it is tied to versions, build options, and a maintainable update process.
We treat CRA relevant work as an engineering topic across the stack: RTOS foundation, safety and integrity mechanisms, and the integration layer where many real world issues appear.
What changes with CRA in day to day engineering work
A lot of CRA discussions start with definitions and scope. That is useful once. What matters in a project is what changes in your backlog.
From an engineering perspective, CRA pushes three themes to the front:
You must be able to ship updates. Not as a one off “we can do it if needed”, but as a repeatable process that does not break traceability and validation.
You must be able to respond to vulnerabilities. That includes intake, triage, fixes or mitigations, and customer communication.
You must be able to document what you ship. Not only for your own team, but in a way that fits a customer’s product evidence and their own compliance obligations.
If you supply embedded software components, you will feel this through customer questionnaires, supplier audits, and more detailed requests for documentation and lifecycle commitments. In practice, CRA is less about one magic checklist and more about being able to answer the same questions consistently across releases.
CRA deliverables you will be asked for
Below is a pragmatic list of deliverables that tend to show up when CRA related requirements are translated into contracts, supplier assessments, and project gates.
Vulnerability handling and maintenance
At minimum, customers will want to understand:
How vulnerabilities are reported to you. One channel is better than five informal ones.
How you triage. Impact, exploitability, affected configurations, and realistic attack preconditions.
How you respond. Fix, mitigation, configuration guidance, or a supported workaround.
How you communicate. A short advisory with affected versions, fixed versions, and recommended actions.
Common pitfall: teams can implement fixes, but they cannot explain the decision path that led to a fix release. That is where trust is lost, even if the technical change is correct.
What helps: a lightweight, documented workflow with clear ownership, version references, and release notes that are written for integrators.
Updateability and versioning that survives real projects
For embedded components, “we ship updates” is only meaningful if updates can be consumed by a customer without breaking their own evidence.
Practical expectations usually include:
Versioned source releases with traceable change history.
Defined build assumptions such as compiler families and relevant switches that influence behavior.
Configuration compatibility rules so customers know what can be changed safely and what must be revalidated.
Clear boundaries of what is in scope of the component and what is part of the customer application.
Common pitfall: a release exists, but the customer cannot reproduce the build or cannot match it to the exact configuration used in their safety and security evidence.
What helps: explicit “integration constraints” documentation and controlled version lists that customers can reference.
Technical documentation and SBOM inputs
SBOM is often treated as a single file that you generate once. In embedded projects, it becomes useful only when it is connected to versions, build options, and update cadence.
A realistic approach is to distinguish:
Component level SBOM inputs that a component supplier can provide, such as third party libraries used inside a component, their versions, and how they are configured.
System level SBOM that the product manufacturer must assemble, because only they know the full bill of materials including the application, system configuration, and deployment variants.
Common pitfall: SBOM is delivered as a static list without a clear mapping to component versions or without a process that keeps it current when maintenance releases happen.
What helps: an SBOM input that is released per version, with clear scope and boundaries, and that is updated as part of maintenance.
Security by design in embedded systems: where it really lives
In this context, security by design means building components and integrations so that secure configuration, clear boundaries, and maintenance are realistic over the product lifetime. For embedded software components, the security posture is often decided by the following engineering realities:
Configuration becomes part of the product. A secure design can be undermined by a permissive configuration.
Integration is where assumptions break. If boundary conditions are not explicit, the integrator will fill the gaps.
Availability is a security topic. Denial of service in embedded systems is often about CPU budget, scheduling, and resource isolation, not only about network traffic.
This is why we do not treat CRA as a checkbox attached to one component. We treat it as a set of engineering obligations that must be supported across component design, documentation, and integration.
A practical view: the attack surface of an RTOS component
Engineers usually understand “attack surface” immediately, and it is a good bridge between CRA wording and actual technical work.
For an RTOS component, typical attack surface areas include:
API usage patterns. A rich API can be misused. The secure subset and safe usage constraints must be documented.
Configuration inputs. Build time configuration, memory protection settings, scheduling policies, and privilege settings.
Memory protection and isolation. Whether and how tasks are separated, and what happens on violations.
CPU availability. Task storms, priority misuse, or runaway execution that starves critical work.
Two common failure patterns:
Failure mode: a system relies on isolation, but protection settings are inconsistent across builds and variants.
Symptom: integration works on one platform variant but behaves unexpectedly on another, often under stress.
Mitigation: configuration controls, repeatable integration checks, and documentation that defines valid boundaries.Failure mode: a non critical task can starve a critical task through scheduling misuse.
Symptom: timing failures appear as “random instability” under load.
Mitigation: deterministic scheduling behavior, strict resource allocation policies, and monitoring hooks that make violations visible.
The key point for CRA is not that an RTOS is “secure”. The key point is that the component has a design that can be integrated securely, and that the supplier can support maintenance and evidence when issues appear.
How we support CRA related work across products and services
We support CRA related requirements by focusing on two things that matter in real projects: repeatable engineering controls and deliverables that customers can actually use.
Flexible Safety RTOS: foundation with explicit integration boundaries
Our Flexible Safety RTOS is designed for safety critical embedded systems, and many of the engineering properties that matter for safety also matter for a robust security posture when integrated correctly.
What we focus on for CRA related work is not a marketing claim. It is the practical ability to provide:
A well defined component baseline that customers can version and reference.
Clear integration constraints that prevent “silent assumptions” during integration.
Deterministic behavior characteristics that help teams reason about availability and timing under load.
Documentation inputs that fit into customer evidence, including version lists and integration guidance.
Safety Addons: integrity and monitoring mechanisms as building blocks
Security by design is often improved through mechanisms that detect corrupted state, unexpected control flow, or violations of execution constraints.
Our Safety Addons provide building blocks that can be used, depending on the project’s safety and security analysis, such as integrity checks and runtime monitoring mechanisms.
The CRA relevant angle is straightforward: mechanisms are only valuable if they are deliverable, configurable, and maintainable across versions, with documented assumptions.
Integration Service and BSP bring up: where most practical risk lives
In many embedded projects, vulnerabilities and compliance issues do not appear because the RTOS source code is exotic. They appear because integration and platform setup are complex, rushed, or inconsistent across variants.
Integration and BSP bring up work typically touches:
clock, memory, interrupt, and exception initialization
startup and runtime self tests and diagnostics integration
platform specific configuration of protection and monitoring
repeatability across toolchains and build environments
If you want CRA readiness that survives product variants and long lifecycles, this layer matters. It is where we often help teams turn “it works on the eval board” into a versioned, reviewable, and maintainable foundation.
What we deliver, and what stays with you
To keep things clear, we separate deliverables and responsibilities.
We typically deliver:
component releases with version references and documentation inputs
integration guidance, constraints, and support during bring up
mechanisms and hooks that support monitoring and integrity strategies
engineering support for closing documentation gaps around component usage
The product manufacturer remains responsible for:
the system level risk assessment and security concept
system level SBOM and deployment specific evidence
operating the update mechanism in the field
product level compliance declarations and customer communication strategy
This separation is not legal fine print. It is an engineering reality that prevents surprises late in a project.
Quick checklist: CRA readiness for embedded component projects
Use this list as a quick sanity check before a supplier audit or an internal release gate.
Do we have one defined channel for vulnerability reports and intake?
Is triage ownership clear, and do we record affected versions and configurations?
Can we ship a maintenance release without breaking traceability?
Do we publish release notes that name affected versions and fixed versions?
Can we reproduce our build, including relevant compiler assumptions and switches?
Are integration constraints documented so a customer can integrate securely?
Do we maintain an SBOM input per version, with clear scope boundaries?
Are configuration changes controlled and linked to evidence requirements?
Do we have a plan for long lifecycle support, including end of support signaling?
Can we explain what is in scope of the component, and what is system responsibility?
If you cannot answer two or three of these, you are not alone. The fix is usually a small set of process and documentation improvements, but they must be done deliberately.
FAQ
Is CRA only for large companies?
No. CRA obligations attach to products placed on the EU market, not to company size. In practice, SMEs feel it strongly because customers request evidence and lifecycle commitments.
Are some products excluded?
Certain categories can be covered by other regulations or frameworks. In project work, it is best to confirm applicability early, because exclusions can be narrower than teams assume.
What is the minimum SBOM we need?
There is no universal “one file” answer that works for every embedded product. A practical baseline is a versioned SBOM input for each component release, plus a system SBOM owned by the product manufacturer.
How fast do we need to provide patches?
The CRA pushes expectations toward timely handling, but actual timelines depend on the vulnerability and the deployment constraints. What matters most is that you have a documented, repeatable path, and that customers can see which versions are affected and what mitigations exist.
Does using certified safety components automatically satisfy CRA?
No. Safety certification and CRA readiness overlap in useful engineering disciplines, but CRA requires ongoing security maintenance and vulnerability handling that goes beyond a one time certificate.