openskills.info
Course catalog
Course Preview

IoT Device Provisioning and Identity

IoT device provisioning and identity is the work of giving every device a unique, cryptographically verifiable identity, then connecting it to a management platform on first boot without manual setup. Factory-injected keys, certificate enrollment, and zero-touch bootstrapping replace the shared passwords that fail at fleet scale.

itComputer architecture and hardware

Don't Panic — IoT Device Provisioning and Identity

Somewhere on a factory line, before your device had a case or a firmware version worth trusting, it was given a cryptographic name. This course is about that moment and everything it sets in motion: device provisioning, the process of giving every unit its own provable identity and installing the credentials that let it join a management platform without a human typing anything at all.

Why bother? Because the alternative has a track record. Fleets that ship one shared password out of the factory are one leak away from being somebody else's fleet, which is why consumer security standards ban universal default passwords by name. And a fleet is not a laptop you can walk over to: devices end up in basements and substations, installed by people with no accounts on your systems and no patience for a wizard.

Three ideas carry the whole topic.

First, trust has a birthplace. The chip gets a hardware root of trust during manufacture, often a TPM Endorsement Key whose private half never leaves the chip. On top of that sits the manufacturer-installed identity, IEEE 802.1AR's IDevID, and later the owner-issued LDevID. The factory decision is the security model: whatever was injected on that line is what every later protocol will faithfully transport. Pick devices whose provisioning you can actually vouch for.

Second, enrollment is transport, not magic. The EST protocol lets a device request and renew certificates over plain HTTPS. BRSKI adds the fun part: a brand new device, which BRSKI calls a pledge, meets a stranger network and needs one trustworthy thing to happen. A manufacturer-side service called the MASA signs a voucher saying which server this particular device should believe, the pledge swallows its first trust anchor in a step called imprinting, and from then on everything is ordinary enrollment. FDO solves the same problem with an ownership voucher and a matchmaking rendezvous server, and throws in late binding: build the device first, decide who owns it later. Managed cloud services reassemble these same parts behind an API, with certificates, TPM challenges, or symmetric keys as the proof mechanisms.

Third, strength tracks provenance. A certificate chain that names each device is the strongest proof, a TPM challenge proves real silicon, and a symmetric group key is the cheap knockoff whose blast radius is the whole group. There is no setting that makes the cheap option behave like the good one. The cheatsheet holds the endpoint names and decision rules for the day you actually have to choose.

One thing will surprise you: a freshly powered device cannot tell the time, so it cannot check when certificates expire. The standards know this. BRSKI explicitly lets a pledge skip timestamp checks until it has a clock. The first hours of a device's life are politely lawless by design.

The intro is the full tour, the slides compress it into one screen, the cheatsheet is the pocket reference, and the quiz tells you whether the machinery stuck. Field notes cover what fleets get wrong. Panic is not required anywhere.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources