At some point the sentence comes up: "Have a look at the CRA and what it means for us." That is the EU Cyber Resilience Act, which makes cybersecurity a precondition for CE marking. A colleague sits down with the regulation. Twenty pages later, they are deep in reporting deadlines, conformity assessment procedures, and legal definitions. What to do in the repository on Monday morning is not in there.
That is not a complaint about the regulation. It is a legal text and it reads like one. But it explains why the available reading on the CRA helps most embedded teams so little: guides, slide decks and webinars explain the law. The questions an engineering team actually has are different ones. We have been getting the same three for months.
Which of our products does the CRA actually cover?
This is the question portfolios get sorted wrong on. Three rules answer it clearly, without a consulting project, but more hangs on it than the product category: there are two deadlines, and they trigger different obligations. For grown legacy products, that sorting decides whether any work is needed at all.
Do we have to change code?
No slide deck and no webinar will answer that for you. Your own repository will, in about an hour. Eight checks are enough, all of them with tools that are either open source or already sitting in your stack. Every No points at exactly one place where code, build or process has to change. From our projects, we know that hardly any grown embedded product comes out of that hour with nothing open.
What does this mean for our legacy, our migration, our new project?
The obligations are the same for everyone, the starting point is not. A grown legacy product, an upcoming migration to a new board or framework, and a greenfield project each start somewhere different. Which work packages come first decides how expensive the whole thing gets. Planning a migration without these packages means building tomorrow's retrofit.
Why we are the ones writing this
Felgo is an embedded software engineering company from Vienna with 26 engineers, not a consultancy. We have made our money with architecture and code since 2012, across more than 200 projects, most of them with C++, Qt and QML on embedded systems. Even our co-founders are engineers. The topics behind the CRA are therefore nothing new to us: SBOMs out of the build, signed updates with rollback, hardened production builds and maintainable architectures are things we have shipped for years, because industrial customers ask for them. What is new is only the framework that now makes them mandatory for everyone. So we write about the CRA from the place where it actually gets dealt with: the repository.
What we deliberately leave out is the legal side: risk assessment methodology, conformity assessment, the CE process. That belongs to the manufacturer and their advisors. We cover the engineering half, and only that. Mixing the two would not be serious.
The answers, on five pages
We wrote our answers to the three questions down, for engineering teams and without consultant language. Three rules to sort your portfolio in an hour. A 60-minute self-check against your own release image, to print out and tick off. And an engineering backlog of 14 work packages with acceptance criteria and size estimates, ready to pull into Jira, GitLab or Azure DevOps.
No form, no gate, direct download:
And if you would like to walk through your self-check results afterward, one of our co-founders will happily take half an hour for it. It will not turn into a sales call.
