Build in 8 weeks
In 8 weeks, build the first complete version of your product’s CRA deliverables and leave with a clear action plan for the technical and organizational changes still needed.
Embedded security experience, applied to the CRA
I work both with technical details of embedded products and with standardization bodies. The CRA Readiness Program brings together that double experience: we can discuss your secure update method, vulnerability processes, and the risk assessment.
Marta Rybczynska – with more than 20 years of experience in open source and over 15 years in embedded systems. She’s a member of the Yocto Project security team, has contributed technical articles to LWN.net… and now is also working on the CRA-related standards.
That combination shapes this program: regulatory language becomes practical product questions. Like:
- What is inside the firmware?
- How do updates reach devices?
- Which supplier information can you rely on?
- Who receives a vulnerability report and who decides what happens next?
Prepare your product to the CRA (Cyber Resilience Act) with all you already know about it
Without the legal jargon. We turn CRA requirements into practical questions and actions for your product.
Without starting from scratch. Build on the documentation, processes, and evidence you already have.
Without exposing confidential information to the group. You decide what you share. Product-specific questions can be handled asynchronously and confidentially.
Without turning the CRA into a compliance checklist. We work on the engineering reality behind the requirements: architecture, updates, vulnerabilities, components, processes and responsibilities. The program combines hands-on embedded security experience with active involvement in the standards shaping CRA implementation.
For an embedded team
For embedded engineers, technical managers and compliance leads.
At least one participant per team needs access to product architecture, technical documentation or source code, and the ability to ask the right people for missing information.
No generic checklists
You have more concrete CRA material than you think. It is scattered across the company.
The hardware team knows the device. The software team knows the firmware and update path. Procurement holds supplier information. Someone handles incoming security reports, perhaps informally. Documentation exists, but it rarely tells one coherent product story.
A generic checklist can tell you that you need a cybersecurity risk assessment or vulnerability handling. But if you do not know how to write a risk assessment? You’re left on your own.
A generic checklist cannot establish how your device is built, which versions you ship, where your updates come from, what suppliers provide, or who will act when you learn about a vulnerability.
The CRA Readiness Program gives your team a sequence for collecting those answers, recording the gaps and drafting the documents while decisions are still fresh. You do not need to write everything from scratch. You do need people who can inspect the product and make decisions… or can ask.
Eight weeks – one product
| Stage | What your team works on |
| Week 1 – Kickoff and product inventory | Choose the product and team, define its scope and support period, category (general, important, critical), decide where the action plan lives and who owns conformity decisions. Map product versions, firmware, software, connected services, production and update paths, and existing information. Find out which standards may apply (if any). |
| Week 2 – Due diligence and logistics | Identify supplier inputs, existing evidence and responsibilities; flag what you still need to request. Check the state of your SBOMs. Decide how you will manage and store documentation. |
| Week 3 – Quick risk assessment | Answer ten practical questions guiding the risk assessment. Work on identifying the product architecture and security features. |
| Week 4 – Full risk assessment | Develop a product-specific cybersecurity risk assessment from your architecture and use cases, including information relevant to applicable standards. |
| Week 5 – Vulnerabilities and updates | Define how people contact your security team, where you publish information and how you receive, assess, act on and report vulnerabilities. And how you are going to produce and deliver updates. |
| Week 6 – User documentation | Write documentation of security features. Assemble version one of the user documentation packs from the work completed so far. |
| Week 7 – Technical documentation | Finish gathering evidence preparing your technical documentation pack in its first version. |
| Week 8 – Review, CE marking, and next steps | Review the drafts and action plan, assign remaining technical and documentation work, and create a roadmap toward conformity assessment and CE marking (if it applies to you). |
NOTE: The sequence guides your work. It does not imply that every engineering change can be completed during the program.
One clear subject each week
Each week includes two group sessions:
- a Monday introduction to the next subject
- a Thursday review and Q&A.
Between sessions, you work with your team on your own product and can send questions for asynchronous guidance, with an encrypted option for sensitive material.
Thursday discussions use anonymized problems, so the group learns without requiring you to expose confidential product details.
This is a practical program. Bring architecture or source access, existing documents and the people who can find answers. No one outside your company can make your product decisions for you.
End results
- A version-one user documentation pack and version-one technical documentation pack for the selected product.
- A documented view of product scope, support period, components, update and production paths, supplier inputs, and vulnerability handling.
- A product-specific gap list and action plan with owners and next steps, including changes to the device or processes that cannot be solved by writing documents.
- A clearer path for your conformity assessment and CE marking work, with decisions still to make made visible.
These are working drafts and a prioritized plan, not a claim that your product is automatically compliant or CE marked after eight weeks.
Bring one product. Leave with a plan your team can act on
The first cohort begins 19 October 2026. Applications close 13 October 2026. Up to three people from the same company working on one product.
You are in control
You keep ownership of your technical decisions and documents. The program provides structure, review of common issues and guidance between sessions; your team supplies product-specific facts and completes its own work. You can bring sensitive questions through the agreed confidential channel (Matrix or GPG-encrypted email).
What Embedded Security participants say
Well structured practical and theoretical with a hands-on approach to demonstrate required security practices with Yocto for the CRA. Marta adds valuable practical insights to the CRA and helps developers and engineers to grasp practical expertise rather than over complicating security with purely technical discussions. The discussions around practical topics with Marta and other participants within an hourly compressed video session are worth it.
Embedded Security training participant, 10 years of experience
Good course to get insights of what is required to comply with the CRA. Besides theory you get to practice yourself with hardening and securing a system.
Embedded Security training participant, 20 years of experience
I would recommend this course to everybody who has only a little knowledge of embedded security, but is expected to deal with CRA requirements in the near future.
Embedded Security training participant, 5 years of experience
I know a lot of people say this but: Security has to be part of the architecture and not the last thing, which is added at the end of the project. Security has to be a default thing to be learned in embedded development as well.
Embedded security participant, 12 years of experience
Argumentation for engineers to promote security with management.
How to consider SOC vendors not only for their technical specs but also with their software solution and support.
Embedded Security training participant, 7 years of experience
A must-have course for anyone involved in the design or implementation of an embedded system.
Embedded Security training participant, 20 years of experience
This course is really important to follow, because we learned _practical_ ways to increase the security of Yocto-based systems. It shows how to increase product security, without big costs, without losing efficiency, doing what is reasonable. What we learned should really be standard practice everywhere.
Embedded Security training participant, 29 years of experience
I would highly recommend the course. It is vendor-neutral and a must for all Embedded Linux/Yocto Project users. Marta knows her stuff and can give you insight into security-related as well as other topics.
Embedded Security training participant, 33 years of experience
Frequently asked questions
Is this for our company?
It is designed for manufacturers of connected devices with an identifiable product team. It works best if at least one person can access the architecture, technical documentation or source code, and someone can obtain decisions on conformity and vulnerability reporting. If you sell several products, choose one for the cohort; you can reuse the method afterward.
We do not cover excluded product classes: automotive, aviation, military, medical.
Do we need to be cybersecurity specialists?
No. You do need to know your product and involve the people who do. The sessions explain the relevant questions in language engineers, technical managers and compliance colleagues can work with.
What if we do not have a compliance team?
The program works for you. Participants need access to people who can take governance decisions, for example: “who will be signing the CE declaration of conformity?”
How much time will our team need?
Plan for the Monday and Thursday sessions plus work between them to inspect your product, gather evidence, make decisions and draft materials. The effort varies with product complexity and how much information you already have. The effort vary between teams and weeks, plan for at least 1 hour every day.
I do not want to share confidential product details
You do not need to. Group reviews use anonymized case studies. You can use the agreed private channel for questions that need more context, including an encrypted option (Matrix private channel, or GPG encrypted email).
Does this make our product CRA compliant?
No program can guarantee conformity without assessing your product and completing necessary changes. You will produce draft documentation and a prioritized plan for the remaining work, including decisions related to conformity assessment and CE marking.
What if we have no SBOM, update system or vulnerability process yet?
You can still start. The quick assessment exposes these gaps early. Your action plan distinguishes what the team can document now from engineering and process work that needs additional time or resources. We will provide templates you can use as a starting point.
What does the price include?
The first-cohort is for up to three people from the same company working on one product, for applications submitted by 13 October 2026. The placement call confirms fit and what is included before you commit.
How do I apply it to other products?
During the CRA Readiness Program you work on one product. Your learn the method that you can apply to all of them.