From a shipped connected-product release to an evidence record of what the manufacturer knew, decided and did, and when.
A finding, a KEV listing, a supplier notice.
Internal assessment of the product.
The manufacturer's assertion: factual time, basis, author. The clock starts at this point.the clock runs from the factual time, not from the recording
Reportable / not reportable, with the stated ground; recorded by a named person.
Draft → submission recorded.
The Cyber Resilience Act (CRA) sets a reporting duty and, from a later date, administrative fines. Any claim about one date is incomplete without the other.
From this date manufacturers must report an actively exploited vulnerability in their product, or a severe incident having an impact on the security of the product: an early warning without undue delay and in any event within 24 hours of becoming aware, a notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available (one month after the notification for incidents). It applies to in-scope products already on the market.
From this date infringements of Art. 13, Art. 14 and Annex I can be fined up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher.
What a manufacturer should be able to show, if asked, from 11 September 2026
When the manufacturer became aware, on what basis, what was decided, who took the decision, and what was reported when, with the evidence behind each step.
Four steps from a shipped release to a record you can hand over. Real screens. No mock data, no customer data.
Generate the SBOM locally. Upload the evidence, not your source code.
Build the software bill of materials in your own infrastructure with the open-source crAcken SBOM tool, or upload SPDX / CycloneDX from your pipeline. Each release is kept as its own version.
./cracken-sbom generate --target-type rootfs --target /work/firmware/rootfs --target-id firmware-2026.10.04 --output /work/evidence/firmware-2026.10.04sbom.cdx.jsonminimized CycloneDX inventory, the file you uploadprovenance.jsonhow and when it was generated, kept locallyquality.jsonpackage counts and identified gaps, kept locallyAccepted uploadsSPDXCycloneDX
Know which shipped release is affected when vulnerability intelligence changes.
Findings from OSV, GitHub Advisories, NVD, CISA KEV and EPSS, mapped to the releases you shipped. A KEV listing appears as an exploitation signal: known exploited elsewhere, assess your product. EPSS appears as a probability. Neither starts a clock. Release-to-release comparison shows what changed between the versions you shipped.
Turn a signal into an owned CRA decision, recorded by a named person.
A finding is a signal, never awareness. A reporting case opens with an internal review target, labelled as internal. The manufacturer records when it became aware and on what basis. The statutory clock runs from that factual time, not from the moment it was recorded; recording late shows the time already elapsed.
Prepare the required reporting workflow from the same evidence record.
Drafts for early warning, notification and final report, exported as PDF and JSON. Submission is recorded, never implied. The case history keeps what was known when, so someone who was not in the room can follow the record.
What did the organisation know at time T? crAcken records when each finding was first seen in your product and every case decision with its time, so you can show what was known then, not what the system knows today.
The output is a record for an auditor, a customer or an authority: who knew what, who decided what, and when.
Awareness starts the clock, not a CVE publication, a CVSS score or a KEV listing. crAcken separates detected, aware and recorded. Recording awareness later does not move the clock.
The AI memo retrieves evidence, explains and drafts. It may recommend. It never decides awareness time, deadlines, reportability or conformity. A named person records every determination.
Manufacturers of products with digital elements: embedded, industrial and connected devices.
The engineer who maintains the SBOM, triages findings and needs to know which shipped release is affected.
The product owner who decides what a signal means for a product on the market and owns the reporting case.
The person who signs who approves the report and must be able to show on what basis it was made.
Hardware under the CRA: same requirements, mostly met by firmware.
The Cyber Resilience Act sets one list of requirements for a connected product, whether it is a device or a program. Most of those requirements are met by the device's firmware: known vulnerabilities in software components, secure default settings, logging of security events, data minimisation. crAcken tracks the software components of your device, including its firmware, from an SBOM you generate on your own machines, and keeps the record of what you knew, decided and did for each shipped release. Hardware properties such as secure boot, key storage and closed debug ports are confirmed by you or your laboratory. crAcken does not test devices and does not decide conformity.
Behind crAcken is a European team of practising engineers in embedded systems, cybersecurity and post-quantum security. crAcken began when we had to meet the CRA for our own connected products. We use it in our daily work, and every case we handle makes it better, because we want connected products, and the world around them, to be cyber-secure.
Co-founder, crAcken
“We built crAcken because we had to answer the CRA for our own developments. I did not want a tool for formal compliance. I wanted one that helps us make a genuinely secure product.”
Co-founder, crAcken
“After 25 years in semiconductors I know how much security matters, and how much harder it gets to keep up with it every year. crAcken helps teams stay on top of it.”
Next
Bring one shipped release and one finding you are not sure about. We walk through the case together: signal, awareness, decision, report.
crAcken team
Earlier
crAcken was shown at NXP Tech Days Stuttgart in May 2026, at the Avnet stand, by invitation of NXP and Avnet.
Tell us whether you want to meet at it-sa 2026 or try crAcken, and we will answer by e-mail.
Thank you. Your message has been sent.
Some fields need your attention. Check the form and send it again.
Sending failed. Write to us at alex.v@mcsq.tech or on LinkedIn (opens in a new tab).
