Device Provisioning

Compare bootstrap credentials, ownership proof, operational identity, and provisioning attack controls

animation
security
provisioning
credentials
device-identity
iot-security
interactive
An interactive IoT device provisioning credential lab with credential pattern presets, attack scenario controls, lifecycle stages, assurance scoring, quick references, technical accuracy notes, and practice prompts.
animation device provisioning credentials IoT security onboarding

Device Provisioning Credential Lab

Compare the credential used to bootstrap a device, the proof used to bind it to an owner, and the operational identity it should receive before normal service. The main lesson is that bootstrap credentials should not become long-term runtime secrets.

--Credential pattern
--Active stage
--Assurance score
--Teaching risk

Provisioning Credential Workbench

Per-device certificate provisioning

A unique key pair and X.509 certificate identify the device to an enrollment or cloud service.

Provisioning assurance

--

What happens here

--

Evidence to collect

--

Common failure

--

Credential Controls

Choose a provisioning pattern, add an attack or failure scenario, then turn controls on or off to see how the trust decision changes.

Provisioning Credential Quick Reference

Bootstrap credential

  • Used to prove the device can enter provisioning.
  • Can be a factory certificate, voucher credential, or one-time claim token.
  • Should be replaced or constrained after onboarding.

Operational credential

  • Used for normal service after provisioning.
  • Often a device certificate for mTLS, a scoped key, or a platform identity.
  • Needs renewal, revocation, and inventory tracking.

Ownership proof

  • Binds a real owner, tenant, or domain to the device.
  • Can use vouchers, registrar authorization, claim records, or supply-chain evidence.
  • Prevents devices joining the wrong account.

Protected key storage

  • Prefer non-exportable private keys where the device class supports it.
  • Protect bootstrap state from modification and replay.
  • Audit failed provisioning attempts.
Attack Vectors and Mitigations

Cloned secrets

One shared token or key across many devices lets a single extraction impersonate the fleet. Use unique per-device credentials and inventory binding.

Rogue owner

A device can be claimed into the wrong tenant if owner proof is weak. Require server/domain authentication and a trustworthy ownership decision.

Bootstrap MITM

An attacker on the first network can redirect or inspect onboarding if the device cannot authenticate the enrollment endpoint.

Expired lifecycle

Provisioning works once but fails later if bootstrap identities, certificates, revocation, and decommissioning are not planned together.

Security Best Practices

Make credentials unique

Never ship a fleet with the same long-term secret. Use per-device keys, per-device certificates, or one-time tokens that are burned after use.

Authenticate both sides

The service must know the device, and the device must know the service or owner. One-way trust leaves room for rogue provisioning.

Replace bootstrap state

After a device is accepted, install operational credentials with the right scope. Do not keep using factory or claim credentials for production traffic.

Design for recovery

Record serials, owners, issuers, token state, key protection, renewal status, revocation reason, and decommission records.

Technical Accuracy Notes

NIST baseline

NISTIR 8259A describes an IoT device cybersecurity capability core baseline. Device identity, configuration, and secure update support provisioning decisions.

EST enrollment

RFC 7030 profiles certificate enrollment over secure transport for PKI clients acquiring client and CA certificates.

BRSKI

RFC 8995 describes automated bootstrap for new devices with an Initial Device Identifier installed at the factory.

FIDO Device Onboard

FIDO Device Onboard frames onboarding as secure transfer of ownership and supports late binding of a device to an IoT platform.

Practice Prompts

Compare bootstrap patterns

Switch between certificate, token, FDO voucher, and BRSKI. Which one best protects against the rogue owner scenario?

Break a control

Turn off server authentication during the MITM scenario. What changes in the warning and why?

Plan operations

Move to Operate and rotate. What evidence should an operations team keep so that future compromise response is possible?

Choose for constrained devices

If hardware key protection is not available, which remaining controls become most important for reducing fleet-wide risk?