Bootstrap Credential

A contract manufacturer runs three shifts and will not stop the line because your provisioning service is unreachable at 02:00 on a Saturday. So the device has to be able to start its own identity, which means something in the firmware image must be able to say "I am a legitimate unit, issue me a certificate". That something is present in every unit shipped, is readable by anyone with a flash programmer and a soldering iron, and will eventually appear in a teardown writeup.

The pattern accepts that the bootstrap credential will leak and removes almost all of its value in advance. It authorises exactly one operation, for one device, once, and it is never the whole credential: the device generates its own keypair inside a secure element, signs a certificate signing request with it, and the platform binds the issued certificate to that non-exportable key. Possession of the secret alone yields nothing an attacker can use to impersonate a real device.

Why it matters

Identity is the root of every other control in a fleet. Authorisation, telemetry attribution, command routing, billing and firmware targeting all key on it. If one credential can produce an arbitrary number of valid identities, every one of those controls is decorative.

The commercial pressure runs the other way: a per-unit secret needs a line that holds secrets, is audited and is online, while one baked-in secret needs none of that and ships this quarter. The pattern exists because the second option is what actually gets built, and it can be made survivable instead of forbidden.

Implementation patterns

• Enrolment-only authority. The credential authorises POST /enrol and nothing else - no telemetry, no commands, no configuration reads. A leak then costs fake enrolments rather than a fleet takeover.
• Device-generated keys. The private key is created inside a secure element or platform keystore and cannot be exported, so the platform issues a certificate to a key no human has ever seen. A credential you could push to a device is a credential that exists somewhere else.
• One enrolment per serial, enforced server-side. A second attempt for an already-enrolled serial is an alert, not a retry. Make enrolment idempotent on a device-supplied request id so a lost response does not create two identities for one unit.
• Rate limits per serial block, matched to the manufacturing plan. If the plan says 4,000 units a day, an enrolment rate of 400 a minute is an incident.
• Expiry. A firmware image circulates for years, so give the credential an end date and a rotation path tied to the image version, or it is a permanent liability with no owner.
• Attestation as the second factor, where the silicon supports it: the enrolment request carries a boot measurement, so a unit running modified firmware cannot enrol even with the secret.

Industry example

The managed IoT platforms offered by the large cloud providers are built around this split: each distinguishes a provisioning or group-enrolment credential from the per-device credential it obtains, with one-time-use and quota controls on the former. The LwM2M specification (1.2, 2020) carries the idea in its protocol shape - a bootstrap server exists only to hand a device its identity and server details, and is not the server it talks to afterwards. The pattern is standardised because the alternative has failed in public repeatedly, in consumer devices where one hard-coded key covered an entire product line.

Failure scenarios

• Platform-wide authority. The "provisioning" credential also permits telemetry publish and command subscribe, so the leak is a fleet takeover and the only remedy is a firmware campaign.
• Unbounded enrolment. No per-serial limit, so an attacker mints 50,000 phantom devices; your fleet count, billing and dashboards are now fiction, and finding the fakes needs manufacturing records nobody reconciled.
• Server-generated private keys emailed or pushed to devices, making the provisioning database a key escrow. One database compromise impersonates every unit, retroactively.
• No expiry. The credential is still valid eight years later, in refurbished units, in images on download mirrors.
• Revocation before replacement. The secret is revoked on discovery, and devices that have not yet enrolled cannot reach the channel that would deliver the firmware fixing it. The lockout costs a site visit per unit, which for a controller worth less than the visit means fleet write-off.

Trade-offs

The real cost is operational: detection on the enrolment path forever, and a credible rotation story for a secret embedded in hardware you will never touch again.

When not to use it

If the device ships with a vendor-issued hardware identity you can verify, use that and skip the shared secret entirely - the bootstrap credential is a workaround for silicon or supply chains that do not provide one. Skip it too when volumes are low enough that per-unit provisioning is affordable: below roughly a few thousand units a year, injecting a unique credential during test is cheaper than the monitoring and rotation machinery a shared secret obliges you to run. And if a human installer is always present and already authenticated, bind enrolment to that person's session instead, which is stronger and needs no secret in the image at all.

Interview question

Q: Your fleet of 180,000 controllers shares one enrolment secret, and it has just been published. Devices are on cellular, 6% are offline at any time, and a lockout means a site visit. What do you do first, and what is the last thing you do?

What a strong answer covers: narrowing the credential's authority server-side before any firmware ships, because that is hours of work and shrinks the blast radius immediately; detection on the enrolment path; firmware that self-enrols with device-generated keys using the old secret; per-cohort revocation only after enrolment has flattened; the double-enrolment hazard and the registry invariant that answers how many credentials can speak as one device; a time-boxed amnesty followed by a site-visit list; and a permanent, audited break-glass enrolment path with manual approval. Revocation is last because it is the only irreversible step.

Quick check

Quiz: Why must a device generate its own keypair and send a certificate signing request, rather than being handed a certificate and key by the provisioning service? Because a key that can be delivered has existed outside the device, which makes the provisioning system an escrow able to impersonate every unit it ever served.

Flashcard: What three limits make a shared enrolment secret survivable? Enrolment-only authority; one rate-limited use per serial with alerting on reuse; and an expiry - plus a device-generated non-exportable key so the secret is never the whole credential.