A firmware engineer who will put your CRA paperwork in place — and who can read your code

Compliance consultants cannot open your .elf file. That is the whole difference, and on the Cyber Resilience Act it turns out to matter more than the paperwork does.

The two dates

If your product is in the default category, the conformity assessment may be self-assessed under Annex VIII: no notified body, no certification fee. That is the part most small manufacturers do not know, and it changes what the 2027 deadline costs you from a procurement exercise into a documentation exercise.

Check Annex III before you assume it. Important products — Class I and Class II — include microcontrollers with security-related functionality, network interfaces, routers and switches, and boot managers. For Class I the self-assessment route is narrower, and for Class II a third party is required. Which annex you land in is the first question worth answering, and it takes about ten minutes.

What I actually do

1. Tell you whether you could survive a Monday morning. Someone reports an actively exploited vulnerability in a library you ship. Can you name which units contain it, and reach the people holding them, inside 24 hours? Most small manufacturers cannot, and find out on the day.
2. Generate an SBOM from your build — not from a spreadsheet — with the build configuration recorded alongside it, because a component list without build flags will tell you the wrong thing about whether a CVE applies to you.
3. Set up the disclosure side: a coordinated vulnerability disclosure policy, a monitored contact, and a written procedure with names and a clock against it, so the 24-hour path is decided before it is needed.
4. Write the technical file against Annex VII, take you through the Annex VIII self-assessment, and draft the EU Declaration of Conformity for you to sign — the declaration is yours to make, not mine to issue.
5. Read the firmware. This is where the findings come from that a questionnaire scores as compliant — unsigned update paths, default credentials, cleartext management interfaces.

Evidence, before you talk to me

I put my own STM32 firmware through this and published what failed: eleven findings, one pass, every claim traced to a file and line. It found an unsigned OTA path and a shared default password in my own code. Two of the three code defects are fixed in source; the audit is published as the snapshot it was, not edited to flatter me.

Read the teardown →

If you would rather check the work than read the argument, the full audit is published separately — every finding, the grades, the open items I could not verify, and the commands to re-run it against your own tree. See the evidence →

Who I am

An embedded firmware engineer, established in the Netherlands and working between there and France. I write bare-metal C on STM32 — register-level, my own HAL, my own bootloader with dual-bank OTA — and I run declarative build and deployment infrastructure. I work in English, Dutch and French, and I will take the call in whichever of the three suits you.

I am not a certification body, not a notified body, and not a lawyer. I do not sell audits that end in a certificate. I do the engineering and documentation work that has to exist before any of that is meaningful.

How engagements work

• Free 30-minute gap assessment. No deck, no discovery call about your goals. You tell me what you ship and how you build it; I tell you what would fail.
• Fixed-scope firmware security and CRA readiness audit — from €3,500, priced on the product, delivered as findings with file references plus the documentation set.
• Day rate €900–1,200 where the work is ongoing rather than bounded.