Fictitious example. ACME Embedded GmbH, its products, records and document IDs are invented for illustration. Use this as a structural model, not as a template to adopt unchanged — and not as legal advice.
ENG-REC-032 — Storage Encryption Feasibility (Data at Rest)
| Document ID | ENG-REC-032, rev. 1.0 |
| Product | SensorNode S300 (project P-2026-04) |
| Reference | CRA Annex I I(4)(e) (protection of stored data, state of the art); risks R-01/R-08 (SEC-RA-S300); threat T-05 (SEC-TM-S300) |
| Prepared by | HW Engineer with Team Lead Firmware, 2026-07-22 |
| Approved by | Product Security Lead |
| Why pre-development | Data-at-rest encryption is a mandatory essential requirement. If the target MCU cannot support it within the power and cost budget, the hardware must change now — retrofitting after board layout is a project-killer. |
1. What must be protected at rest
| Data | Confidentiality need | Location (planned) |
|---|---|---|
| Mesh network keys, device identity key | High | MCU key storage (never external) |
| Firmware image | Medium (IP + tamper) | Internal flash |
| Measurement buffer (≤ 72 h) | Low–medium | External SPI NOR flash |
| Configuration (thresholds, calibration) | Medium | External SPI NOR flash |
Requirement: keys in hardware-isolated storage; external flash content encrypted (AEAD) with keys that never leave the MCU; internal flash protected against readout.
2. Candidate evaluation
Constraints: battery target 5 years (average current budget 45 µA), BOM delta ≤ €0.80 vs. baseline, industrial temp range.
| Criterion | MCU candidate A (Cortex-M33 class) | MCU candidate B (Cortex-M33 class, security-focused SKU) |
|---|---|---|
| AES hardware engine | Yes, AES-128/256, DMA-capable | Yes, incl. AES-GCM |
| Hardware key storage | Key registers, no dedicated vault; keys derived at boot from PUF-like fuse — limited | Dedicated key vault + secure key ladder, keys non-exportable |
| Internal flash readout protection | RDP-style levels, known bypass history on older family — current family assessed OK | Debug authentication + permanent lock, no published bypass |
| On-the-fly encryption for external flash (XIP/OTFAD) | No — encryption in software before write | Yes, transparent AES on QSPI |
| TRNG | Yes | Yes |
| Measured energy cost of encrypted buffer writes (bench, 4 KB/5 min) | +6.2 µA avg (software AES) → exceeds current budget reserve | +1.1 µA avg (HW engine) → within budget |
| Secure boot chain | Supported (vendor SDK) | Supported, incl. anti-rollback counters |
| BOM delta | ±0 (baseline) | +€0.62 |
| SDK longevity | Until 2034 (see ENG-REC-031 C-2) | Until 2040 |
3. Bench verification performed
Prototype measurement on both vendor dev kits, firmware stub with representative write pattern (encrypted 4 KB buffer flush every 5 min, AES-GCM): logs and power traces archived at P-2026-04/feasibility/enc-bench/. Candidate A's software-AES path misses the power budget by ~4 µA average; achievable only by reducing buffer flush frequency, which conflicts with the product requirement of ≤ 5 min data granularity.
4. Conclusion — hardware decision forced
Annex I I(4)(e) is feasible only on MCU candidate B within the product's power and functional budget. Combined with the SDK longevity result (ENG-REC-031) and the open radio-stack issue for candidate A, the recommendation is:
> Select MCU candidate B as the S300 target hardware. BOM increase +€0.62/unit accepted; approved in project steering meeting 2026-07-24 (minutes P-2026-04/M1).
Consequences: board layout starts on candidate B reference design; SR-S300-01 is marked "feasible, HW-backed"; risk R-01 residual drops from 12 to 4 (design measure in place, to be verified at release).
5. Records
This record, the bench data, and the steering decision are part of the technical documentation (design decision trail for essential requirement I(4)(e)).