Most conversations about CRA, DORA, and NIS2 compliance for IoT hardware boil down to one uncomfortable binary: redesign the board around newer, security-capable silicon, or accept that your existing product line falls out of compliance on a fixed deadline. For a product with years left in its lifecycle and a BOM that took months to qualify, “just redesign it” is rarely a real answer.
There’s a third option that gets far less attention than it deserves: pair the legacy chip with a modern security co-chip that absorbs the cryptographic boundary, while the legacy part keeps doing exactly what it already does well – application logic, peripherals, display, sensor polling. Call it a soft fade-out. The old silicon stays in service until its natural end-of-life; the compliance gap gets closed by a second, much cheaper part sitting next to it, not by replacing it.
The Three Gaps a Legacy Chip Has – and Why a Co-Chip Fixes Them
The regulatory pressure driving all of this isn’t abstract. NIST finalized its post-quantum cryptography standards in 2024, and IR 8547 sets real dates: ECDSA and RSA are deprecated after 2030, disallowed after 2035. Germany’s BSI has gone further – TR-02102-1 (2026 edition) sets a stricter 2030 deadline for high-protection-need data, and treats the migration as “alternativlos” (without alternative) rather than a recommendation.
Older embedded silicon typically lacks three things simultaneously: a hardware-isolated key store (TEE/APM), side-channel countermeasures (DPA protection) strong enough for physical-access threat models, and enough RAM/compute headroom to run lattice-based PQC algorithms in software without starving the rest of the firmware. Redesigning the whole board to fix all three at once is expensive and slow. But none of those three gaps require touching the part that’s already doing its job – they’re all boundary problems. A second, purpose-built chip can own the boundary.
Three concrete pairings
Using the ESP32 family as a worked example (the underlying logic generalizes to any chip family with a security-generation gap):
- Legacy chip + ultra-low-power security gatekeeper. An older chip with no hardware ECC/ECDSA and an RSA-only boot chain gets an upstream chip acting as root-of-trust – verifying firmware images, anchoring device identity, handling key exchange – before the legacy part is even released from reset.
- High-performance chip + isolated crypto coprocessor. A capable application processor (AI/vector extensions, camera, display) that lacks a TEE or DPA protection gets a small, security-hardened co-chip that handles all key storage and signing in a side-channel-protected boundary, isolated from the noisy, complex main firmware.
- Minimal/legacy chip + full network-stack offload. A chip too memory-constrained to run a modern TLS 1.3 + PQC stack alongside its application code gets stripped of crypto duties entirely – it talks to a companion chip over a simple local bus, and that companion chip owns the entire encrypted network boundary.
Each pairing has the same shape: keep the expensive, qualified, field-proven part; add a small, cheap part that owns exactly the gap.
Where this doesn’t help
This pattern solves transport and identity security – TLS boundaries, firmware signing, device attestation. It does not solve data-at-rest confidentiality on the legacy chip itself. If sensitive data is stored unencrypted in the legacy part’s own flash or SRAM, no amount of network-boundary hardening on a co-chip fixes that; you’d need the legacy chip’s own storage path secured, which usually does mean touching the original design. Be precise about which threat model you’re actually closing before treating this as a full compliance answer.
The economic case
The alternative – a full BOM redesign – typically means re-qualifying an entire board: new layout, new certification runs, new firmware bring-up, new supply chain relationships, months of schedule. A co-chip addition is comparatively small: one new part, one interface (SPI/UART/I2C), a defined crypto boundary. For a product with genuine years left in its lifecycle, that’s the difference between a compliance line item and a product-line-ending expense.
One caveat worth stating explicitly: the local interface between the legacy chip and the co-chip is itself part of the threat model, not outside it. If SPI/UART/I2C between the two carries key material or plaintext in the clear, an attacker with physical board access – the same access-class the co-chip’s TEE and DPA protection are meant to defend against – can simply tap that link instead of attacking either chip directly. The interface needs its own authentication (and encryption, if the bus is exposed or the threat model includes board tampering) – a session-key handshake at boot, or a pre-provisioned shared secret, are the usual minimums.
Skipping this step doesn’t just weaken the pattern, it defeats its purpose: the security boundary moves to wherever the internal link is weakest, not to the co-chip.
I’ve written up the full pattern with a specific chip-level matrix (which chips have TEE, DPA protection, dedicated signing peripherals, PQC-viable RAM/clock headroom) and worked application tiers for each pairing, using the current ESP32 SoC family as the concrete example:
👉 Hardware Lifecycle Management & Practical Soft-Fade-out Combinations
Curious whether others doing CRA/NIS2 compliance work are seeing this pattern used in practice, or whether procurement and BOM economics push teams toward full redesigns regardless of the technical option. Would also be glad to hear if this generalizes cleanly outside the ESP32 world, or if there’s chip-family-specific nuance I’m missing
답글 남기기