How do you manage cryptographic keys in an embedded device?

Key management is arguably the hardest problem in embedded security — the cryptographic algorithms themselves are well-understood, but protecting the keys on a device with limited resources, physically accessible hardware, and a multi-year field lifetime requires careful architectural decisions. The fundamental principle is that private keys and symmetric keys must never exist in readable flash memory. If a key is stored as a constant in firmware, anyone with a JTAG debugger, a flash reader, or even a firmware binary dump can extract it. Once one device is compromised, every device using the same key is compromised — a catastrophic failure mode for IoT fleets.

The preferred approach uses hardware security: a Secure Element (SE, such as ATECC608A/B, OPTIGA Trust M, or SE050) or a Trusted Platform Module (TPM) stores keys in tamper-resistant silicon where they can be used for cryptographic operations but never exported. The key is generated inside the SE and never leaves it — signing and decryption happen within the secure element, and only the result is returned to the MCU. For devices without a dedicated SE, many modern MCUs provide a hardware key store or OTP fuses for storing a limited number of keys (STM32's OTP area, NXP's PUF-based key storage, ESP32's eFuse key blocks). ARM TrustZone provides a software isolation mechanism where keys are stored in the Secure World and crypto operations are performed via secure function calls from the Non-Secure World.

A complete key management strategy for an embedded product addresses the full lifecycle: Provisioning (how keys are injected during manufacturing — ideally in a secure facility using a Hardware Security Module, or generated on-device and the public key exported for registration), Rotation (how keys are updated if compromised — challenging for embedded devices; a key hierarchy with a long-lived root key and short-lived session keys limits the blast radius), Revocation (how the backend stops trusting a compromised device — certificate revocation lists or short-lived certificates), and Attestation (how the device proves its identity to the cloud — using device-unique certificates signed by a manufacturer CA). Common interview mistakes include: storing symmetric keys in source code, using the same key for all devices in a product line, hardcoding API tokens, and failing to protect the debug interface that could be used to dump key material.