crAcken keeps a record of what you knew, decided and did, and when, for each connected-product release you ship.
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. Recording late shows the time already elapsed.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) introduces a reporting duty first. Administrative fines apply later.
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. The early warning is due without undue delay and in any event within 24 hours of becoming aware. The notification is due within 72 hours of becoming aware. The final report is due within 14 days after a corrective or mitigating measure is available (one month after the notification for incidents). This also covers in-scope products already on the market.
From this date, non-compliance with the essential cybersecurity requirements of Annex I or with the obligations of Art. 13 and 14 can be fined up to EUR 15 million or, for an undertaking, up to 2.5 % of its total worldwide annual turnover for the preceding financial year, whichever is higher; Member States lay down the rules on penalties (Art. 64(1), (2)). These fines do not apply to micro and small manufacturers that miss the 24-hour early-warning deadline, or to open-source software stewards (Art. 64(10), as corrected by OJ L 2025/90555).
What a manufacturer should be able to show, if asked, from 11 September 2026
When did the manufacturer become aware, and on what basis? Who decided what? What was reported, and when? Keep the evidence behind each step.
Guides, calculator, glossary and SBOM generator
Enter when you became aware. Get each deadline in UTC and your Member State's time, plus a calendar file.
A preliminary check of product scope, your role and the assessment route. About 3–5 minutes. No account needed.
Four steps to keep the evidence for each release you ship. Real screens. No mock data, no customer data. The app's interface is in English.
Generate the SBOM locally. Upload the evidence, not your source code.
Build the software bill of materials on your own infrastructure with the open-source crAcken SBOM tool, or upload SPDX / CycloneDX from your pipeline. Each release stays a separate version.
./cracken-sbom generate \
--target-type rootfs \
--target /work/firmware/rootfs \
--target-id firmware-2026.10.04 \
--syft /opt/verified-tools/syft \
--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
See which shipped release is affected when new vulnerability information arrives.
crAcken maps findings from OSV, GitHub Advisories and NVD to your shipped releases, with CISA KEV and EPSS data. A KEV listing means known exploited elsewhere: assess your product. EPSS gives a probability. Neither starts a clock by itself. The clock starts when the manufacturer becomes aware of an actively exploited vulnerability in its product. Compare releases to see what changed between the versions you shipped.
Assess the signal. Have a named person record the CRA decision.
A finding is a signal. On its own, it does not establish 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 when it was recorded. Recording late shows the time already elapsed.
Use the same evidence record to prepare the required reports.
Prepare drafts for early warning, notification and final report. Export them as PDF and JSON. Submission is recorded as a separate step; a draft does not mean it was sent. The case history shows what was known when, so someone outside your team can follow it.
crAcken records when each finding was first seen in your product. It also records each case decision and its time. You can show what was known then, not what the system knows today.
An auditor, customer or authority may ask to see who knew what, who decided what, and when. That is the record crAcken gives you.
Awareness starts the 24-hour and 72-hour clocks. A CVE publication, a CVSS score or a KEV listing does not start them by itself; it can lead to awareness once the manufacturer knows that its product contains the vulnerability and there is reliable evidence that it is actively exploited (Art. 3(42)).
The AI memo retrieves evidence and helps explain it and draft text. It can make recommendations. 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 keeps the SBOM up to date, reviews findings and needs to know which shipped release is affected.
The product owner who decides what a signal means for a product already on the market and takes responsibility for the reporting case.
The person who signs who approves the report and needs to show the evidence behind it.
Hardware under the CRA: the same requirements, many of them implemented in firmware.
The Cyber Resilience Act sets one list of requirements for connected products, both devices and programs. Many of the product requirements of Annex I Part I are implemented in firmware: no known exploitable vulnerabilities, a secure by default configuration, recording and monitoring of relevant internal activity, data minimisation. The manufacturer's processes meet the vulnerability-handling requirements of Annex I Part II. You generate an SBOM on your own machines. crAcken uses it to track your device's software components, including firmware, and keeps a record of what you knew, decided and did for each shipped release. You or your laboratory confirm hardware properties such as secure boot, key storage and closed debug ports. crAcken does not test devices or decide conformity.
Behind crAcken are the two founders below and a European team of engineers in embedded systems and cybersecurity.
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 our developments secure.
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.
Earlier
crAcken was shown at it-sa 2026 in Nuremberg.
Earlier
crAcken was shown at NXP Tech Days Stuttgart in May 2026, at the Avnet stand, by invitation of NXP and Avnet.
Want to meet at it-sa 2026 or try crAcken? Write to us here. We will reply by e-mail.
Start a free trial in the app: all features except single sign-on and on-premise installation; 30 days or 10 analyses, up to 3 users, 3 active products, 5 active releases and 5 AI generations; scheduled monitoring does not count; no payment details.
Until the operating company is registered, crAcken is provided by Aliaksandr (Alex) Varabyou personally (see Impressum).
Thank you. Your message has been sent.
Please 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).
