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, 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 Shared-Key Blast Radius
When the same key authenticates updates, encrypts data, or unlocks features across all units, its compromise is total. There is no containment and no degraded mode. The attacker who pulls it from one device can now sign malicious updates every device will accept, decrypt traffic from any unit, or clone the product at will.
Blast radius is the right way to think about it. A good security design keeps the radius of any single compromise small. A shared key does the opposite: it wires 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. The other units use different keys, so a signature forged with the compromised key is rejected everywhere except the single device it came from.
Containment is the entire point. Security incidents are inevitable in a large enough fleet, and the measure of a design is not whether any unit can ever be compromised but how far that compromise spreads. Per-device keys turn a fleet-wide catastrophe into a logged, contained, single-unit incident you can respond to.
Identity Comes for Free
Per-device keys do more than contain compromises. They give each unit a unique, verifiable identity, which is the foundation for per-device authorization and targeted revocation. You can disable one misbehaving or stolen unit without touching the rest, and you can make access decisions per device rather than per product.
A shared key cannot do any of that, because every device looks identical to every system that talks to it. Unique keys turn the fleet from an anonymous mass into individually accountable devices, which is valuable for far more than incident response: licensing, warranty, fleet management, and trust decisions all benefit.
Revocation Needs Unique Identity
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.
The Provisioning Step
Per-device keys require generating and injecting a secret during manufacturing, ideally on the device itself so the private key exists nowhere else. That extra step is the main reason vendors reach for a shared key instead. The convenience of skipping provisioning is real, and so is the catastrophe when the one shared key leaks.
The step is not as heavy as it sounds. 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 for certification. The investment is in designing the flow once, after which it runs as part of normal production.
Generate the Key on the Device
The strongest provisioning 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, which means no system anywhere holds a copy of the secret.
# 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
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. The device certifies its public half against your trust anchor and keeps the private half forever internal, which is the cleanest possible provisioning outcome.
The Central Key Server Trap
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 that generates keys must be treated as one of the most sensitive systems you operate: hardened, audited, and ideally backed by a hardware security module that performs the generation without exposing the keys in bulk. The convenient version, a plain server writing a database of private keys, is a breach waiting to happen.
Trust the Factory Less
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 key generation removes the most dangerous artifact, a usable secret the factory touches, from the process entirely. The contractor triggers generation and handles only public keys.
Building provisioning this way converts manufacturing from a point of catastrophic exposure into a step that even an untrusted partner cannot turn into a fleet-wide compromise. The factory never holds anything that unlocks the fleet, so a breach of the line, or a dishonest operator, harvests nothing of value.
Certify the Public Key
After generation, the device’s public key is signed by your certificate authority, binding each unit’s identity to your trust anchor. That certificate is what backends and peers check to confirm a device is genuinely yours, and it is what a revocation list references to disable a single unit.
This certify-the-public-half flow is what ties per-device keys into a usable system. The private key stays on the device, the public key becomes a certified identity, and your trust anchor sits at the root. From there, authentication, authorization, and revocation all work per device, which is the capability a shared key can never provide.
What This Looks Like 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 unit. 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. That is precisely why it is worth raising early in a product’s life, before the fleet grows and before the one shared key has been sitting on every shipped unit waiting to be pulled.
The Tradeoff, Stated Plainly
The honest framing is that per-device keys cost a provisioning step and a bit of identity infrastructure, and in exchange they convert your worst-case security 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.
That is a bad bet for anything an attacker would want, because extracting a key from one unit is ordinary work. The provisioning step is the only thing standing between convenient-but-fragile and slightly-more-work-but-resilient, and it is the difference an attacker notices immediately.
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.