Updated as of June 2025. Verify CRA dates against the current Official Journal text (Regulation (EU) 2024/2847) and European Commission guidance before relying on them for compliance planning.

The CRA Deadline Is 100 Days Out: Here’s What Your BLE Firmware Actually Has to Do to Comply

You’ve got a regulation written by lawyers open in one tab and your firmware repo open in the other, and the two don’t speak the same language. The CRA says your product needs an “appropriate level of cybersecurity” and “secure-by-default configurations.” Your job is to turn that into commits.

The abstract legal text maps onto a short list of concrete engineering tasks. Most of them you’ve probably heard of (secure boot, signed updates, an SBOM). The trap is the timing. There isn’t one CRA deadline. There are two, and the one most teams ignore lands first.

Here’s the mental model that sorts it out, plus the actual firmware work, BLE-specific, vendor-neutral.

What the CRA Actually Requires (Two Deadlines, Not One)

The Cyber Resilience Act entered into force on December 10, 2024. Nothing was required of you on that day. The obligations phase in.

CRA ENTERS FORCE          REPORTING OBLIGATIONS      FULL OBLIGATIONS
Dec 10, 2024  ───────────  Sep 11, 2026  ───────────  Dec 11, 2027
   |                          |                           |
   Law active            Report exploited           Secure-by-design +
                         vulns & incidents          conformity required

Two cliffs. From September 11, 2026, you must report actively exploited vulnerabilities and severe incidents to the authorities. From December 11, 2027, the full set of product obligations applies: secure-by-design requirements, vulnerability handling over the product’s lifetime, and the conformity documentation that proves it.

Who’s in scope? The CRA covers “products with digital elements,” which is any software or hardware product that connects to a device or network. A BLE sensor, a wearable, a tracker, an industrial tag, all of these qualify. If it has a Bluetooth stack and you sell it in the EU, you’re in.

The obligations sort into three buckets:

• Secure-by-design requirements (Annex I): integrity, confidentiality, access control, secure defaults.
• Vulnerability handling: a process to find, fix, and disclose flaws across the product lifetime.
• Conformity and documentation: technical files, an SBOM, and a declaration of conformity.

The CRA legal explainers from consultancies cover this part well. They stop short of the part you care about: which clause becomes which line of firmware.

The Nearest Cliff: Vulnerability Reporting

Most teams plan for secure boot and forget that the reporting duty comes more than a year earlier.

From September 2026, when a vulnerability in your product is actively exploited, you have to notify the relevant CSIRT and ENISA. The current text sets tight windows: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report later. Severe incidents that affect the security of the product carry similar duties.

This hits firmware teams first because it’s not about shipping perfect code. It’s about having a process that turns “a researcher emailed us about a flaw” into a notification to the right authority inside a day.

A minimal process looks like this:

• A monitored intake channel (a security@ address or a SECURITY.md in your repo) for reports.
• A triage owner who can assess severity fast.
• A documented disclosure path, including coordinated disclosure with the reporter.
• A way to push the fix to deployed devices (which is where OTA comes back in).

You can stand this up in weeks, and you don’t need new silicon for it.

Engineering Pillar 1: Secure Boot

Annex I asks that products protect the integrity of stored and processed data, which for firmware means the code running on the device is the code you signed, not something an attacker swapped in.

+------------------+   maps to   +-------------------------------+
| Secure Boot      | ----------> | Integrity of firmware         |
| Signed OTA       | ----------> | Ability to ship security fixes|
| SBOM             | ----------> | Vulnerability handling        |
+------------------+             +-------------------------------+

Secure boot is the mechanism. The chain runs like this: an immutable root of trust in ROM or fuses verifies the bootloader’s signature, the bootloader verifies the application image, and each stage refuses to run an image that fails verification.

Three things you need to get right:

• Hardware root of trust. The verification key (or its hash) lives in one-time-programmable fuses so it can’t be rewritten. Nordic nRF52/nRF53, Silicon Labs EFR32, and TI CC23xx all expose this.
• Signature verification. ECDSA over the image hash is the common choice. The public key is on-device; the private key stays in an HSM you control.
• Anti-rollback counters. A monotonic counter in fuses or protected flash stops an attacker from flashing an older, vulnerable but validly signed image.

The BLE MCU reality bites here. Flash is tight, and a verified-boot scheme plus two image slots eats space you wanted for your application. Fuse banks are small, so plan your key and counter layout before you burn anything. Silicon vendor app notes help with the chip-level details; just don’t mistake them for CRA guidance. They tell you how, not what the regulation needs.

Engineering Pillar 2: Signed OTA Updates

The CRA requires that you can ship security fixes to deployed products, promptly and for the support period you declare. For a fielded BLE device, over-the-air update is the only practical mechanism. Recalling hardware doesn’t scale.

Signing is the core of it. The same key infrastructure as secure boot applies: sign the image off-device, verify on-device before you commit it.

[New image] -> [Verify signature] -> ok? --no--> [Reject, keep current]
                                       |
                                      yes
                                       v
                            [Write to inactive slot]
                                       v
                            [Boot + anti-rollback check]

Verify before write, write to an inactive slot, then swap. If the new image fails to boot, fall back to the known-good one. The anti-rollback counter from your secure boot design carries straight over.

BLE makes delivery the hard part. Throughput over a connection is modest, the link drops, and a device may be asleep most of the day to save battery. Your update path needs resumable transfers and per-chunk integrity so a dropped connection doesn’t mean restarting a 200 KB image from zero.

Getting an update to one device on your bench is easy. Getting it to thousands of devices scattered across a country, many out of range of any gateway, is the real problem. This is where Hubble’s global BLE network helps: it delivers updates and collects status from distributed fleets without you deploying gateway hardware at every site. The signing and verification stay on you; the delivery and monitoring stop being a logistics nightmare.

Engineering Pillar 3: The SBOM

A Software Bill of Materials feels like paperwork but is the foundation for everything else. You can’t report a vulnerability in a component you don’t know you’re shipping.

The CRA expects an SBOM in a machine-readable format. CycloneDX and SPDX are the two recognized standards; pick one and stay consistent. List your third-party dependencies down to versions: the BLE stack (SoftDevice, Zephyr’s Bluetooth subsystem, the vendor’s link-layer library), crypto libraries, RTOS, bootloader, and any parser handling external input.

Depth matters. “We use Zephyr” isn’t an SBOM. The specific Zephyr version and the modules you’ve pulled in are what counts.

Make it a build artifact, not a Word document someone updates by hand. Generate it from your build system on every release so it never drifts from what you actually shipped. When a CVE lands in a library at 2 a.m., a current SBOM tells you in minutes whether you’re affected. A stale one tells you nothing.

BLE-Specific Attack Surface You’ll Be Judged On

Annex I’s essential requirements aren’t BLE-specific, but BLE gives you specific ways to fail them. Here’s the mapping that matters:

BLE Surface          | Risk                  | CRA Requirement
---------------------|-----------------------|----------------------
Pairing (Just Works) | MITM during bonding   | Secure-by-default
GATT permissions     | Unauthorized access   | Access control
Advertising data     | Info disclosure       | Data minimization
Link-layer privacy   | Device tracking       | Confidentiality

Pairing. Just Works pairing has no MITM protection. If your device handles anything sensitive, use an authenticated method (Passkey or Numeric Comparison via LE Secure Connections). Shipping Just Works as the default is exactly the insecure default the CRA targets.

GATT permissions. Every characteristic with read/write access is an entry point. Require encryption and authentication on the ones that matter, and don’t expose debug or config characteristics in production builds.

Advertising data. Anything in your advertising packets is broadcast in the clear to anyone listening. Don’t put serial numbers, user identifiers, or anything else useful to an attacker in there.

Link-layer privacy. A static address lets anyone track your device over time. Use resolvable private addresses so the device’s identity isn’t trivially followable.

Monitoring a deployed fleet for anomalous behavior also feeds your vulnerability-handling duty: you can’t respond to exploitation you can’t see.

A Realistic 100-Day Starting Order

You can’t do all of this at once, and some of it can’t be retrofitted late. Here’s the order I’d work in:

1. SBOM first. It’s a build-system change, and everything else leans on it. Days, not weeks.
2. Vulnerability reporting process. Intake channel, triage owner, disclosure path. Stand it up well before September 2026.
3. Signed OTA. You need a working update path to deliver fixes the moment your process flags one. Get the signing and verify-before-write flow right early.
4. Secure boot. This is the one you can’t bolt on after tape-out. If your chip selection or fuse layout doesn’t support a hardware root of trust, you find out now or you respin the board. Decide before you commit hardware.
5. Conformity documentation. Technical file, declaration of conformity. Last, because it documents the work above.

The honest warning: secure boot needs hardware support, and OTA needs a bootloader designed for it. Both are cheap if you plan for them in your MCU selection and expensive if you discover the gap after the boards are made.

Where to Start Monday

The CRA rewards teams who start with process and inventory, not the ones who scramble for cryptographic perfection at the deadline. The 2026 reporting duty is closer than it looks, and it’s the easiest to satisfy: a channel, an owner, a documented path.

Generate your SBOM this week. Stand up your reporting process this quarter. Confirm your hardware can do secure boot before you finalize the design. The rest is engineering you already know how to do.

Check the dates against the current Official Journal text and loop in whoever owns compliance at your company before you build a plan around them.

Writer’s note for editor: I held the date claims to the brief’s stated values (in force Dec 10 2024; reporting from Sep 11 2026; full obligations Dec 11 2027), which match the Regulation (EU) 2024/2847 phase-in structure. The 24h/72h reporting windows reflect the early-warning/notification structure in the text but should be confirmed against the final implementing guidance, as exact wording on timelines has been refined in Commission materials.

Hubble Network brings satellite-grade BLE connectivity to devices in the field, so secure boot and firmware updates reach hardware wherever it lives. See how it works →