Who Owns Your CRA Evidence? The Embedded Security Seat Nobody Staffed

Regulatory dates have a way of belonging to somebody else right up until they belong to you. This one has been sitting in a European regulation since 2024, filed under legal, and it lands in the middle of this month.

So What Actually Changes on September 11?

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force in December 2024, and most of what it asks of you waits until December 11, 2027. One piece does not. From September 11, 2026, the Article 14 reporting obligations apply: become aware of an actively exploited vulnerability in a product with digital elements, or a severe incident affecting its security, and you notify your Member State CSIRT and ENISA through the CRA single reporting platform.

The clock is short. An early warning inside 24 hours, a main notification inside 72 hours, then a final report within 14 days once you have a corrective or mitigating measure, or within a month for a severe incident. That simultaneous notification is written into the regulation itself.

Ship an industrial controller, a zonal ECU, a SmartNIC or a gateway into the EU, and that clock is yours now, well ahead of whatever your 2027 project plan says.

Why 24 Hours is Really a Hiring Question

Your compliance team can file a notification. Twenty-four hours is asking for something else.

The embedded engineers we place describe that window as several jobs stacked on each other: reading what came in from the field, judging whether the thing is genuinely being exploited or merely disclosed, establishing which shipped builds and SKUs carry the affected component, and producing a technical basis that survives a regulator reading it later. Then somebody has to say how the fix reaches hardware that may be bolted to a factory floor. They add that tracing a CVE down into a third-party stack that arrived through a vendor BSP is a skill of its own again.

Ask a hiring manager where that sits on the org chart and you tend to get a pause. You have firmware engineers who can fix it and compliance people who can file it. The middle has nobody's name on it.

The Obligation Nobody is Budgeting For

Article 14 gets the attention. The quieter requirement is the one that moves your headcount math: you have to define a support period with a clearly specified end date and handle vulnerabilities across it, alongside risk assessment through design and production, due diligence on third-party components, technical documentation, conformity assessment and CE marking.

The firmware leads we work with keep pointing at that support period. A decade of vulnerability handling on a shipped product behaves like a standing seat, and it competes for the same people as next year's program.

What Does This Person Actually Look Like?

Titles move around by company. Embedded Security Engineer, Product Security Engineer, or a senior Firmware Engineer who has owned the update path. The hiring managers we talk to screen for the combination underneath:

·       A secure boot chain they have implemented and debugged, key rotation included

·       A signed OTA path with rollback, and a real answer for the device that dies mid-update

·       SBOM generation that reflects the actual build, not a spreadsheet kept beside it, in Yocto, Buildroot or Zephyr

·       The ability to map a CVE in a third-party component to specific shipped versions and SKUs, fast

·       Threat modeling that lands on the Annex I essential requirements instead of a generic checklist

Candidates who have worked inside NIST SP 800-218, the Secure Software Development Framework, tend to interview well on the documentation half of this job.

Put a Bad Monday In Front of Them

Describe the morning. A customer reports odd traffic from a fielded unit, the component at fault arrived through a vendor BSP two releases ago, and you have a day. What do they do first?

The useful answers get specific fast: how they would establish which shipped builds carry the component, what they would want from the field before calling it exploitation, and how a signed update reaches a device that may fail mid-flash. A/B partitions and recovery images tend to come up unprompted.

Then one follow-up, which earns its place. Who wrote the security evidence on your last audited product, and what did the auditor push back on? Somebody who has been pushed back on has done the job.

Where the Pool Gets Thin

You are hiring between two shortages here: firmware engineers who can carry a security argument, and security people who can read a schematic. Narrow pool, and every team shipping into the EU is reaching into it this quarter.

Two things you can do about that. Write the req around the update path and the evidence instead of a certification acronym, because the acronym screens out good engineers who did the same work under a different standard. And if a permanent line is not approved yet, run the first year as a contract engagement. Two in three of the engineers we put in front of a hiring manager receive an offer, on shortlists of five to seven rather than volume, which matters when you are filling a seat against a deadline instead of a fiscal year.

September is the easier half of this, honestly. The support period behind it is where the real headcount argument lives, and the teams making that argument now are the ones who get to treat 2027 as paperwork.

If you are working out who owns this on your program, tell us what you are building and where the evidence gap sits, and we will tell you honestly whether that profile exists in the pool right now.