OTA Update (Over-the-Air)
An OTA (Over-the-Air) update is the process of wirelessly delivering new firmware, software, or configuration data to an embedded device deployed in the field. In the context of the EU Cyber Resilience Act, OTA update capability is no longer optional — it is a regulatory requirement for any connected product that must receive security patches throughout its lifecycle.
Key Facts
| Detail | Information |
|---|---|
| Full term | Over-the-Air Update |
| Purpose | Remote firmware/software delivery without physical device access |
| CRA requirement | Mandatory secure update mechanism for all products with digital elements |
| Security standard | IETF SUIT (Software Updates for IoT) — RFC 9019 manifest format |
| Typical protocols | HTTPS, CoAP, MQTT, LwM2M, custom TLS-based |
| Bandwidth range | 1 KB (delta patches) to 100+ MB (full firmware images) |
Why OTA Is a CRA Requirement
The Cyber Resilience Act mandates that manufacturers provide security updates for the expected product lifetime (minimum 5 years). For devices deployed in the field — industrial sensors, building automation, smart meters, automotive ECUs — physical access for updates is impractical or impossible. OTA is the only viable delivery mechanism.
CRA Article 13 specifically requires:
- Timely security patches — Vulnerabilities must be remediated without undue delay.
- Automatic or easily applicable updates — Users should not need technical expertise to apply security fixes.
- Notification of updates — Users must be informed when security updates are available.
Secure OTA Architecture
A CRA-compliant OTA update system requires multiple security layers:
┌─────────────────────────────────────────────────────┐
│ BUILD SERVER (Manufacturer infrastructure) │
│ • Compile firmware │
│ • Sign with HSM-stored private key │
│ • Generate SUIT manifest with metadata │
│ • Compute delta patch (optional) │
│ • Upload to CDN / distribution server │
└──────────────────┬──────────────────────────────────┘
│ Signed firmware image + SUIT manifest
▼
┌─────────────────────────────────────────────────────┐
│ DEVICE (In the field) │
│ 1. Download manifest + image over TLS 1.3 │
│ 2. Verify manifest signature using HRoT public key │
│ 3. Check version (anti-rollback counter) │
│ 4. Write to inactive partition (A/B scheme) │
│ 5. Verify integrity (SHA-256 hash) │
│ 6. Atomically switch boot partition │
│ 7. Boot new firmware via Secure Boot chain │
│ 8. If boot fails → automatic rollback to partition A│
└─────────────────────────────────────────────────────┘Critical Security Properties
| Property | Purpose | CRA Relevance |
|---|---|---|
| Code signing | Ensures firmware comes from the legitimate manufacturer | Mandatory — prevents malicious firmware injection |
| Anti-rollback | Prevents downgrade to vulnerable old firmware | Mandatory — monotonic version counter in OTP fuses |
| A/B partitioning | Atomic updates with fallback to known-good image | Best practice — prevents bricked devices |
| Hardware Root of Trust | Signing key verification anchored in tamper-resistant hardware | Mandatory — software-only key storage is insufficient |
| Encrypted transport | TLS 1.3 for download channel | Mandatory — prevents man-in-the-middle attacks |
| Encrypted payload | Firmware image encrypted (optional) | Recommended — protects IP, prevents reverse engineering |
| Delta updates | Only changed bytes transmitted | Optimization — reduces bandwidth for constrained devices |
OTA Without Secure Hardware: The Risk
Many existing IoT devices implement OTA updates with software-only security:
| Aspect | Software-Only OTA | Hardware-Secured OTA |
|---|---|---|
| Signing key storage | Flash memory or file system | Secure Element / HSM / OTP fuses |
| Key extraction risk | High — JTAG/SWD dump, firmware analysis | Physically unextractable |
| Rollback protection | Software flag (modifiable) | Hardware monotonic counter (irreversible) |
| Boot verification | Optional, bypassable | Secure Boot from HRoT |
| CRA compliant | ❌ No | ✅ Yes |
The firmware trap: A device with software-only OTA can receive updates, but an attacker who extracts the signing key can push malicious firmware to every device in deployment. Hardware-secured OTA makes this physically impossible.
Related Terms
- Secure Boot — The boot-time verification process that ensures only OTA-delivered, signed firmware executes.
- Hardware Root of Trust — The tamper-resistant hardware that stores OTA signing key verification material.
- CRA — The EU regulation mandating secure OTA capability for connected products.
- SBOM — OTA update metadata should include SBOM diffs to track component changes.