Crypto-Agility Without a Redesign: The "Soft-Fade-Out" Pattern for Legacy IoT Silicon

Art Keller — Sun, 02 Aug 2026 21:21:27 +0000

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.

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

DEV Community: Art Keller

Crypto-Agility Without a Redesign: The "Soft-Fade-Out" Pattern for Legacy IoT Silicon

The Three Gaps a Legacy Chip Has - and Why a Co-Chip Fixes Them

Three concrete pairings

Where this doesn't help

The economic case