EU Cyber Resilience Act · Article 14
On 11 September 2026 you get 24 hours to report an exploited vulnerability. Can your team do it?
A fixed-fee readiness check for small hardware, firmware and embedded teams that sell into the EU. Two hours of my time, a written memo, and a one-page runbook the engineer on call can actually follow at 2am. €1,200, fixed. Delivered in three working days.
What changes on 11 September
The Cyber Resilience Act (Regulation (EU) 2024/2847) phases in. Most of it lands in December 2027 — but the reporting duties in Article 14 start on 11 September 2026. From that date, if you make a product with digital elements that is on the EU market and you become aware of an actively exploited vulnerability in it:
- 24 hours — early warning to the CSIRT of the country where you are established, via the new Single Reporting Platform.
- 72 hours — full notification, including any corrective measures.
- 14 days — final report, once a fix is available. (A month, for a severe incident.)
Three details catch small teams out. The clock starts when you become aware — including when a researcher emails an address you do not monitor. The duty covers products already in the field, not just what you ship after September. And there is no small-company exemption: a fifteen-person firmware shop has the same 24 hours as Siemens.
What you get
- A scope verdict, per product line. In scope or not. Which conformity path you are on — most products self-assess with no notified body, and knowing that early saves months and a large invoice. If you land in Annex III or IV, I tell you plainly, because that is a different and more expensive road.
- Your reporting chain, written down. Which CSIRT you report to, who inside your company is woken up, who decides that a vulnerability is "actively exploited", and what goes in each of the three submissions. This is the part that fails on the night, not the paperwork.
- A one-page on-call runbook. Printable. The clocks, the decision points, the contacts, the fields you will be asked for. Written so that whoever is on call can follow it without having read the regulation.
- A ranked gap list. Measured against Article 13 and Article 14 — vulnerability handling, coordinated disclosure, SBOM, and your declared support period (at least five years, or the product's expected lifetime). Ranked by what actually breaks first, not by article number.
- Two things you can publish this week. A coordinated vulnerability disclosure
policy and a
security.txt, drafted for your company, ready to paste. These are cheap, visible, and most of your competitors still do not have them.
Plus a 30-minute call to walk through the memo with whoever needs to act on it.
How it works
- Short call, 20 minutes. I check you are actually in scope and that I can help. If not, I say so and we stop — no charge.
- Intake, about 20 minutes of your time. A short questionnaire plus links to product pages, firmware release notes, and any policy you already have.
- Two hours of work. I do the assessment and write the memo.
- Delivery within three working days, then the 30-minute walkthrough call.
€1,200 fixed, invoiced in advance. Not hourly — if it takes me longer, that is my problem.
What this is not
I am a software engineer, not a lawyer and not a notified body. This is an engineering readiness assessment: it tells you what your team has to be able to do on the night, and what is missing. It is not a legal opinion, not a conformity assessment, and not a CE marking. If your product turns out to need a notified body, my job is to tell you that quickly so you can go and find one.
It is also not a subscription, a platform, or a retainer you have to keep paying. One engagement, one memo, done.
Who this is for
Companies of roughly 10 to 250 people that put a product with software or firmware in it onto the EU market: industrial and IIoT sensors, gateways and controllers, connected B2B equipment, embedded instrumentation, on-premise software products. Typically already CE marked for RED, EMC or LVD — and with nobody yet named as the owner of CRA.
Not for: regulated medical devices, large firms that already run a PSIRT, or pure cloud SaaS — SaaS is generally NIS2 territory, not CRA.
Who I am
Ami Heines. Thirty years building software, seven of them as backend architect of a GRC and compliance platform, and this past year an application for the Israel National Cyber Directorate. I built Keelson, a free CRA readiness self-check and Article 14 deadline tracker, because I wanted to understand this regulation properly. Work is invoiced by SharsheretBlockim Ltd. (Israel); VAT applies to Israeli clients only, so clients elsewhere are invoiced without it.
Book it
There are not many working days left before 11 September, and I can only take a handful of these before the date. Book the 20-minute call and we will know quickly whether it is worth doing.
Book the readiness check →Not ready to talk to anyone? Run the free five-minute self-check instead — no signup, no email required. Or write to ami@amiheines.com.