How it works
Warnbell links three things small makers rarely link in time: what’s in each firmware build, what’s being exploited right now, and what the EU Cyber Resilience Act needs you to say about it, and when.
In detail
Six steps, running around the clock. Each one adds to a single evidence record.
STEP 01 / 06
Upload a CycloneDX or SPDX SBOM per firmware version, or point us at build output from Yocto, Buildroot, Zephyr or ESP-IDF.
We read the kernel and RTOS configuration as well as the package list. A CVE in a Linux driver you never compile in should not wake anyone up.
Each firmware version becomes a record: components, versions, enabled features, and the product lines it ships in.
Works with
STEP 02 / 06
Article 14 is triggered by actively exploited vulnerabilities, so we watch exploitation signals, not just new CVEs.
Every 15 minutes we pull CISA KEV, VulnCheck KEV, ENISA’s EU Vulnerability Database (EUVD), CIRCL / GCVE sightings, EPSS scores and OSV.
New entries are matched against your inventory straight away. Anything that touches a component you ship goes to step 3.
Works with
STEP 03 / 06 AI agent
An AI agent compares affected version ranges, patches and backports against your exact build, then checks whether the vulnerable code is enabled and reachable in your configuration.
It answers one of three things: affected, not affected, or needs a human. Each answer lists its reasons and the evidence behind them.
If it is unsure, it says “needs a human” and does not guess. Your engineer confirms or overrides, and the decision is logged.
Works with
STEP 04 / 06
Optional, and read-only: connect your MQTT broker, AWS IoT Device Defender, Azure IoT Hub or Memfault.
For devices running affected versions, we look for crash loops, bursts of authentication failures and unusual outbound connections. Any of these may show the vulnerability is being exploited against your own fleet.
Telemetry only adds evidence. Everything else works without it.
Works with
STEP 05 / 06 AI agent
Every finding goes into a single evidence record. All documents are drafted from that record, so they never contradict each other.
Drafts: the 24-hour early warning, the 72-hour notification, the 14-day final report, a plain-language customer advisory, and machine-readable CSAF advisories and VEX statements.
Every sentence links to the evidence behind it. A reviewer can check any claim in one click.
Works with
STEP 06 / 06
The 24-hour and 72-hour clocks start when you become aware, not when something is submitted. Escalations go to whoever is on call.
ENISA’s Single Reporting Platform is web forms only, with no API. So we give you a field-by-field checklist that matches the form, ready to copy and paste.
Every decision, edit, approval and submission goes into a hash-chained audit log, so you can show later who knew what, and when.
Sources: no API at launch ENISA SRP FAQ (source, opens in a new tab); deadlines run from awareness CRA Art. 14(2) (source, opens in a new tab)
Works with
Reports filed on time, with a record you can show a regulator.
Then: your approvalTHE GATE · HUMAN IN THE LOOP · ALWAYS
Nothing reaches ENISA, a CSIRT or your customers without your sign-off. You file it, or on the Managed plan we file it on your instruction.
Product previews are illustrative, with example data.
Data sources
Public feeds of exploitation evidence, matched against your inventory.
Public sources · linked below
US government catalogue of vulnerabilities known to be exploited in the wild.
A broader known-exploited catalogue, often earlier than CISA’s, with links to evidence.
The EU Vulnerability Database, including its list of exploited vulnerabilities.
Reports that a vulnerability has been seen exploited or discussed.
FIRST’s daily estimate of how likely a vulnerability is to be exploited. Used for triage, not as proof.
Precise affected version ranges for open-source packages, matched against your SBOM.
Your data
Read-only, and only what the decision needs. See Security & trust for how we handle it.
Your side
CycloneDX or SPDX SBOMs, or build output from Yocto, Buildroot, Zephyr and ESP-IDF, including kernel and RTOS configuration. For FreeRTOS and other stacks, upload an SBOM.
From each build we read
Inside Warnbell
Fleet data only adds evidence. Everything else works without it.
Limits
So you can decide with the full picture.
We don’t install an agent on your devices or block attacks on them. We watch, decide, draft and keep the clock. Fleet signals come only from systems you already run, via read-only connectors.
We need an SBOM or your build output. We don’t unpack closed firmware images or vendor blobs to guess what’s inside. If a supplier only gives you a binary, ask them for an SBOM.
ENISA’s platform has no API at launch, and even if it did, nothing would be filed without your approval. Today you file using our field-by-field checklist.ENISA FAQ (source, opens in a new tab)
Monitoring and drafting run around the clock. Human review around the clock, and filing on your behalf, come with the Managed plan, which isn’t available yet.
Questions about scope? Talk to us as a design partner
Design-partner programme
Help shape Warnbell while it’s being built. You get the product early at £99/month, and the founder on the other end of the line. We get your honest feedback.
Design partner pass
Nº 01–05
£99/ month
Places open