Why You Should Never Ship One Signing Key
Sharing a single cryptographic key across an entire product line is convenient at manufacturing and disastrous in the field. Recover that one key from one unit, and every device that ever shipped is compromised at once. The fix is per-device keys, and the only real cost is a provisioning step most teams skip.
The Convenience That Becomes a Catastrophe
A shared key is the path of least resistance. One key pair, baked into the firmware image and used to authenticate updates or encrypt data on every unit, means nothing to track and nothing to provision. The build is simpler, the factory does less, and everything works on day one. That convenience is exactly why it is so common.
The catastrophe arrives the first time anyone extracts that key from a single device, which on a typical unit is a bench afternoon’s work. From that moment the key is no longer secret on any unit, because it was never unit-specific. One extraction, one fleet-wide break, and no way to contain it after the fact.
The Blast Radius of a Shared Key
When the same key authenticates updates, encrypts data, or unlocks features across all units, its compromise is total, with no containment and no degraded mode. The attacker who pulls it from one device can sign malicious updates every device will accept, decrypt traffic from any unit, or clone the product at will. A good design keeps the radius of any single compromise small; a shared key does the opposite, wiring every device to the same fate, so the failure of the weakest unit on the most careless owner’s bench becomes the failure of the entire fleet.
How Quickly One Key Falls
The shared key has to be on the device to be used, which means it is reachable by the same techniques that read any secret: a firmware dump, a debug-port read, or a glitch. Finding it in an image is often trivial.
# a shared signing key extracted from a single firmware dump
strings -n 16 firmware.bin | grep -A4 'BEGIN EC PRIVATE KEY'-----BEGIN EC PRIVATE KEY----- MHcCAQEEIHq3...same bytes on every unit...oUQDQgAE -----END EC PRIVATE KEY----- # this key validates updates for the ENTIRE product line
That key, pulled from one unit, is the master key to the fleet. There is nothing device-specific about it, so the same private key signs an attacker’s firmware for every unit in the field. The extraction was ordinary; the consequence is total because of the shared-key choice.
Per-Device Keys Contain the Damage
Giving each unit its own key means a compromise stops at that unit. The attacker learns one device’s secret and nothing more, because the other units use different keys, so a signature forged with the compromised key is rejected everywhere except the single device it came from. Incidents are inevitable in a large enough fleet, and the measure of a design is not whether any unit can be compromised but how far that compromise spreads.
Unique keys also give each unit a verifiable identity, the foundation for per-device authorization and targeted revocation. You can disable one misbehaving or stolen unit without touching the rest, and make access decisions per device rather than per product, which a shared key can never do because every device looks identical to every system that talks to it.
Revoke Just One Unit
When a unit is compromised, lost, or decommissioned, you want to revoke just that one. With per-device certificates tied to your trust anchor, revocation is a list entry, and backends stop trusting that device’s identity while every other unit continues normally.
# revoke a single compromised device by its unique certificate serial echo "R 340A91F2 $(date) compromised" >> revoked.txt # backends reject only that device id; the rest of the fleet is unaffected
That surgical revocation is impossible with a shared key, where the only options are to trust the compromised key, and therefore every unit, or to distrust it and break the entire fleet at once. Unique identity is what makes a proportional response possible.
Provision Keys on the Device
Per-device keys require generating and injecting a secret during manufacturing, and the strongest version has each unit generate its own key pair internally, so the private key never leaves the chip, not even onto the factory line. The device exports only its public key to be certified.
# tell the secure element to generate a keypair in a slot; export only the public key ateccx08 genkey --slot 0 --out device_0.pub # the private key stays inside the secure element and is never exported
Modern secure microcontrollers and secure elements can generate a key pair internally on command, so the line only has to trigger generation and collect the public key. When the private key is born and stays inside the secure element, there is no central database of secrets to breach and no factory artifact to leak, which is the cleanest possible provisioning outcome, and the investment is in designing the flow once, after which it runs as part of normal production.
Do Not Recreate the Problem on a Key Server
The easier-looking alternative, generating keys on a factory server and injecting them, reintroduces the very problem you were solving: that server becomes a single point of failure holding every device’s private key, and breaching it exposes the whole fleet just as surely as a shared key would. If on-device generation is not possible, the server must be treated as one of the most sensitive systems you operate, hardened, audited, and ideally backed by a hardware security module that generates without exposing keys in bulk.
Manufacturing often runs at a contractor you do not fully control, so design provisioning assuming the line itself might be careless or hostile. On-device generation removes the most dangerous artifact, a usable secret the factory touches, from the process entirely, and the device’s public key is then signed by your certificate authority, binding each unit’s identity to your trust anchor. The factory never holds anything that unlocks the fleet, so a breach of the line, or a dishonest operator, harvests nothing of value.
What It Means in an Assessment
When I review a product, a single key across all units is one of the most consequential findings I can report, because its severity is fleet-wide by definition. I look for it by extracting the key from one unit and checking whether the same bytes appear on a second; identical keys confirm the shared-key design.
The remediation is rarely a quick patch, because it usually means adding a provisioning step to manufacturing and reworking how updates are signed and verified. Per-device keys cost that step and a bit of identity infrastructure, and in exchange they convert your worst-case incident from fleet-ending to merely annoying. A shared key saves that work and bets the entire product on no one ever extracting a single unit’s secret, which is a bad bet for anything an attacker would want.
Where This Fits
Designing device provisioning and per-device key management, or finding a shared key before an attacker does, is a core part of a product security assessment. If you want help designing provisioning or auditing how your fleet’s keys are managed, that is the kind of work we do at Berkner Tech.
