CRA compliance and cyber resilience platform for embedded devices
Know the software inside your product, see the risk in the field, report on time and ship the fix safely. Four modules work on the same record, from MCUs to embedded Linux gateways.
What is ready today
We state the current status of each capability plainly. Modules marked pilot are offered through our enterprise pilot program.
| Capability | Status | Scope |
|---|---|---|
| Web SBOM scanner with OSV matching | Available | Free web tool, parsing in the browser |
| CycloneDX 1.7, SPDX 2.3 and CSV export | Available | Free web scanner |
| Firmware SBOM engine (CycloneDX 1.6, SPDX 2.3, VEX) | Pilot | Validated on public firmware images |
| Device security events and KEV / EPSS prioritisation | Pilot | Enterprise pilot program |
| Secure OTA (signed, A/B, anti-rollback) | Pilot | Tested end to end on hardware |
| CRA Article 14 reporting assistant | Pilot | Deadline tracking and report drafts; you submit in the ENISA portal |
| Staged rollout and delta updates | Roadmap | Not available yet |
| PUF and hardware-backed identity | Roadmap | Selected microcontrollers |
Modules
01 · Discovery
Dynamic SBOM Engine
Opens firmware images (SquashFS, uImage/sysupgrade, disk images, ESP32 (ESP-IDF) application images and full flash dumps, archives) and identifies the components inside. If a layer cannot be opened or a component cannot be identified, the SBOM is marked incomplete and says why.
- Firmware image and package manifest analysis
- CycloneDX 1.6 and SPDX 2.3 output
- Matching against OSV and NVD, prioritised with CISA KEV and EPSS
- VEX in CSAF 2.0 and OpenVEX; your analyst makes the final call
02 · Prioritization
Field Telemetry and Early Warning
Devices send signed telemetry and report their own security events. Vulnerabilities are ranked by whether they are known to be exploited (CISA KEV) and how likely exploitation is (EPSS), so the urgent ones come first.
- Telemetry signed with each device's own key
- Security events reported by the device: tampering and memory corruption
- Critical device events automatically open an assessment record; your team decides whether they must be reported
- Vulnerabilities ranked with CISA KEV and EPSS
03 · Reporting
CRA Reporting Assistant
The legal deadlines start when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. The platform records that moment, calculates the 24 hour, 72 hour and final report deadlines from it, alerts you before they expire and drafts the content of each report. You submit it in ENISA's Single Reporting Platform and the submission is recorded.
- Deadline tracking with alerts for the 24 h, 72 h and final reports
- Drafts for the early warning, notification, final report and user information (Art. 14(8))
- Affected products and firmware versions taken from the records
- Append-only audit trail
04 · Remediation
Secure OTA Manager
Signs the update with a key that belongs to your company only. Before installing, the device checks the signature, the image hash and the anti-rollback protection; the update is written to the inactive A/B slot.
- ECDSA P-256 signature and hash checks on the device
- A/B slots and anti-rollback protection
- Only firmware that passed CRA analysis can be released
- Every release and device result in the audit trail
Tested on real firmware
We test the platform on public firmware images and on real hardware. Results as of October 2026:
- 6 images · 7 runs
- All analyses completed: open-source embedded Linux router images for several processor architectures, an ESP32 application image and a full ESP32 flash dump. For ESP32, the ESP-IDF version is read from the application descriptor in the image; the versions of the libraries ESP-IDF bundles (mbedTLS, lwIP, FreeRTOS) are not written into the image, so they are completed with the manufacturer's SBOM.
- 174–220
- Components identified in each embedded Linux image.
- ~4,150 → 21–23
- Raw findings reduced to a priority list with CISA KEV and EPSS.
- End-to-end OTA
- On real hardware: enrolment, signed telemetry, CRA analysis of the update, signed release and verified download. This test ran without secure boot enabled.
From the portal
Captured with demo data, October 2026. A real analysis of a public open-source router firmware image; company and product names are fictional.
Fig. 1
Prioritised vulnerabilities
4,135 findings in a router firmware. Vulnerabilities in CISA KEV and with high EPSS come first; each stays under investigation until an analyst decides. Exported as OpenVEX and CSAF.
Fig. 2
Article 14 deadlines
A vulnerability the analyst confirmed as actively exploited. The statutory 24 hour early warning, 72 hour notification and final report deadlines, with the time left. The portal interface is shown in Turkish.
Technical specifications
- On the device
- C99 SDK for microcontrollers
- Firmware analysis
- Embedded Linux images; ESP32 (ESP-IDF) application images (.bin) and full flash dumps
- Device communication
- HTTPS with server certificate validation; each request signed with the device's ECDSA P-256 key
- Update signatures
- ECDSA P-256 (SHA-256), one key per customer
- Output formats
- CycloneDX 1.6 · SPDX 2.3 · CSAF 2.0 · OpenVEX
Recommended hardware security features
Security features we recommend for your product by hardware class. They are recommendations, not requirements of our SDK.
| Profile | Typical memory | Recommended features |
|---|---|---|
| Constrained MCU | 256 KB – 1 MB flash, 64 – 256 KB RAM | Hardware root of trust, secure boot, A/B or dual-bank flash |
| Rich MCU / MPU | 1 – 16 MB flash, 512 KB+ RAM | Hardware crypto accelerator, secure key storage |
| Embedded Linux / gateway | 64 MB+ RAM, eMMC / NAND | Secure element / TPM 2.0 / Arm TrustZone |
How it maps to the CRA
Our guide has a table showing which module serves which CRA obligation. Mapping table in the CRA guide