Field Note: “The Key Is in a Secure Element”. What We Check Next
The most common claim in hardware assessments is true in one narrow sense and silent about everything that matters. The four checks that follow it: debug surfaces, key policy, provisioning history, and what the key actually protects.
Every hardware assessment starts with claims. The most common one in product security: "The key is in a secure element." The sentence is meant to end the discussion. For us, it starts the work, because the sentence is true in exactly one narrow sense (the key material does sit inside that chip) and silent about everything that determines whether it matters. This field note records what we actually check next, in order, and what each step has turned up in real products.
Check 1: the debug surfaces around the SE
The secure element defends its own die. It defends nothing about the processor next to it. First stop: the main MCU. SWD and JTAG pins, UART pads, bootloader shells, test points that happen to speak. If we reach code execution on the host, we don't need the key; we need only the bus. A sign request is a sign request, whoever sends it. Finding: open debug access on the host, SE policy fully open, the expensive chip was doing password storage duty.
Check 2: the key's usage policy
Secure elements let you configure what a key may do: which operations, from which authorization state, with which host authentication. Defaults are permissive, and projects ship pilot configuration to production. We read the policy next: can the key sign arbitrary data? Does the SE require any proof it is talking to legitimate firmware? A key with no policy is a key depot with no gatekeeper, physically safe, operationally public.
Check 3: how the key got there
Provisioning history decides who else might hold the key. Injected at the CM with a script that also wrote a log line? Generated on-chip and certified via attestation? Derived from a serial number? Each answer moves the trust boundary. The worst variant we found: "unique per-device keys" derived deterministically from the MAC address, one flash dump away from every device's identity, secure elements included.
Check 4: what the key actually protects
Last check, and the one that closes the loop: the architecture around the secret. A device identity key in an SE still fails if the backend trusts any bearer of the certificate, if sessions don't bind to the identity, if privileged commands don't re-authenticate. The SE protects a fact ("this device holds key #4711"). Whether that fact means anything is decided by the protocol and the backend, neither of which lives in the chip.
What good looks like
When the claim survives all four checks, it looks boring in the best way: host debug closed and verified, key policy restricted to intended operations, keys generated on-chip with attested provisioning, and a protocol that actually consumes the identity. That combination is not exotic, it is a few weeks of disciplined engineering. It is just that nobody checks whether it happened, which is why we do.