Embedded & IoT security · Service overview
The Cyber Resilience Act asks two different things of you, on two different clocks. From 11 September 2026 you have a live reporting obligation — a process question, answerable in days. By 11 December 2027 your products themselves have to meet the essential requirements — an engineering question, answerable through assessment and remediation.
Around those two obligations sit two more services: hands-on engineering to close what an assessment finds, and ongoing monitoring once your products are in the field. Four services in all — each scoped and priced on its own, used in whatever combination fits where you are.
Reporting Readiness → · Readiness Assessment → · Engineering Support → · Vulnerability Monitoring →
Service 01 — From 11 Sept 2026 · Article 14
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents within 24 hours of becoming aware — with a fuller notification at 72 hours and a final report after that. The obligation covers products already on the market. No CE marking, no conformity assessment and no harmonised standard is needed to be caught by it.
Three days to put the process in place: awareness and triage criteria, notification templates pre-filled for your products, your CSIRT routing determination, ENISA Single Reporting Platform registration, and a tabletop exercise with your team. No prior assessment required.
Ten artefacts, in the format that matches what each one is for — policy documents editable and in your name, registers as a working tracker, professional determinations signed and fixed.
Out of scope, by design: SBOM generation, fleet visibility, OTA and update security, and product conformity with Annex I. Reporting readiness makes the process work; those are engineering questions, and the tabletop is usually what makes clear which of them you need. That is the assessment below, or engineering support.
Service 02 — By December 2027 · Annex I
Three engagement depths, one methodology. Every tier maps findings to CRA Annex I and ETSI EN 303 645. What changes between them is not the checklist — it is how deep the assessment goes into the device, and therefore how strong the evidence behind each finding is.
Network posture and published-firmware analysis. No case opened.
Quick Scan, plus active interception and firmware reverse-engineering. No destructive hardware.
The full engagement: hardware attack and demonstrated exploitation. Priced on variant count and physical depth.
All prices exclude VAT · Valid through 30 June 2027
Evidence strength
You are buying certainty and demonstrability — the difference between “appears unsigned”, “is unsigned”, and “we installed a modified image.”
| Finding class | Quick Scan | Standard | Extended |
|---|---|---|---|
| Exposed services & network postureattack surface, TLS | Direct-tested |
Direct-tested |
Direct-tested |
| Known-vulnerable componentsSBOM / CVE currency | Triaged |
Reachability-checked |
Reachability-checked |
| Transport confidentialityproprietary protocol crypto | Inferred |
Decrypted / proven |
Decrypted / proven |
| Firmware signing & secure bootupdate authenticity, root-of-trust | Inspected |
Confirmed (code) |
Demonstrated |
| Embedded keys & stored secretskey management, secure storage | If in image |
Extracted (soft) |
Extracted (flash) |
| Debug interfaces & physical accessUART / JTAG, console gating | Out of scope |
Identified |
Opened / proven |
| Exploitable memory / code bugsnative-code vulnerabilities | Out of scope |
Pattern-level |
Triaged / PoC |
Scroll the table sideways to compare tiers →
Quick Scan and Standard depend on obtaining a firmware image non-destructively — a vendor download or an over-the-air capture. For many products this is straightforward. Where no image can be obtained without opening the device, the firmware-analysis findings become contingent: they either move to an Extended engagement (off-chip acquisition) or are delivered with a stated limitation.
Reverse-engineering effort is inherently open-ended, so the RE component of Standard is time-boxed — findings are bounded by the agreed effort, not guaranteed to reach a specific result. Extended engagements involving live re-flashing require a client-owned unit and written authorisation for destructive testing.
Service 03 — Follow-on · scoped per project
An assessment tells you what to fix. This is the fixing. We stay on as hands-on engineering help to close the gaps we found — or ones your team already knows about — rather than handing over a report and walking away. Scoped per project against a written estimate.
Remediation implemented, not just recommended. We work alongside your engineers to build in the fixes — secure boot, signed updates, SBOM tooling, hardening — and then re-test to prove each finding is actually closed. Every engagement starts from a written scope and a fixed estimate — not an open-ended meter. Rates depend on the depth of the work and are quoted with that estimate.
Usually follows a Readiness Assessment, but available on its own if you already know what needs doing.
Service 04 — Ongoing · monthly retainer
CRA duties don't stop at launch. New vulnerabilities in your components keep surfacing after a product ships — and the 24-hour reporting clock applies to products already on the market. We watch your products' software bill of materials against new disclosures, so a relevant vulnerability reaches you as an alert, not as an incident.
Continuous CVE watch against your SBOMs, filtered down to what actually affects your products. Priced per product, scaled by how large its bill of materials is — from €490 per product per month, with portfolio rates above three products. Cancellable; no long lock-in.
Needs a current SBOM to watch — produced by a Readiness Assessment, or we establish one at onboarding.
Four services across the CRA lifecycle — get reporting-ready, assess the product, fix what's found, and keep watch once it ships. Each is scoped and priced on its own; combine them however fits where you are.
Discuss your roadmap