Device Provisioning Flow Visualizer

Map an IoT device from factory identity to operational identity and see where each trust gate can fail

animation
security
provisioning
onboarding
device-identity
iot-security
interactive
An interactive device provisioning journey map with stage gates, method profiles, failure injection, Play/Back/Next/Reset controls, technical accuracy notes, quick references, and practice prompts.
Animation Device provisioning Trust gates Onboarding

Device Provisioning Flow Visualizer

Follow one IoT device from factory identity to operational identity. Each stage asks one trust question: what evidence is checked, who checks it, and what happens if that gate is skipped.

BRSKIProvisioning profile
1. FactoryActive trust gate
IDevIDEvidence in focus
baselineInjected failure

Device provisioning flow controls and outputs

BRSKI provisioning journey

A pledge uses factory identity, registrar authorization, MASA voucher handling, and EST enrollment to join a domain.

Current trust gate

Step 1 checks whether the device has a unique factory identity before it ever joins an owner network.

Device provisioning flow diagram A swimlane diagram showing the active provisioning stage, actors, message, evidence, and failure injection.

Journey score

Trust
90
Friction
42
Recovery
24

Trust question

Did the device leave the factory with unique bootstrap evidence?

Pass condition

A unique hardware-protected IDevID is traceable to a manufacturer CA.

Failure mode

No failure is injected. The device can continue if each gate is checked.

Provisioning should reduce trust debt at every step.
If a bootstrap secret becomes a runtime secret, compromise follows the device for its lifetime.
Active actorManufacturer CA -> Device
EvidenceIDevID certificate and serial record
Channelsecure manufacturing
Audit tracefactory record links device identity to product lot

Flow Controls

Choose a provisioning profile, inject a realistic problem, then step through the trust gates as a learner would.

Provisioning Gate Quick Reference
Factory identity

Give each device a unique bootstrap identity or voucher seed. Shared secrets make later checks weak.

Owner binding

Bind the physical device to the correct owner, account, or domain before issuing runtime access.

Device proof

Check cryptographic proof such as an IDevID, certificate chain, voucher, or protected claim code.

Runtime identity

Replace temporary bootstrap evidence with scoped operational credentials, policy, and lifecycle controls.

Profile Notes
QR/app

Best when a human is present. The app must authenticate the user and avoid treating a copied setup code as ownership.

Certificate

Strong for fleets when each device has a unique certificate and the platform can validate issuer, subject, and revocation state.

BRSKI

Useful for automated domain onboarding with pledge, registrar, MASA voucher handling, and EST enrollment.

FDO

Useful when final owner or platform is not known at manufacturing time and ownership is transferred by voucher.

Technical Accuracy Notes
BRSKI

RFC 8995 defines pledge, registrar, MASA, voucher, and EST integration concepts for remote secure bootstrapping.

EST

RFC 7030 defines Enrollment over Secure Transport for CA certificate distribution and certificate enrollment.

NIST baseline

NISTIR 8259A frames device identity, configuration, data protection, update, and cybersecurity state capabilities.

FDO

FIDO Device Onboard supports secure late binding of devices to management platforms through ownership vouchers.

Practice Prompts
Find the first trust gate

Select each profile and identify the first place the system decides whether the device is real.

Inject a redirect

Use the discovery redirect scenario. Which later gate should detect the wrong endpoint?

Separate temporary and runtime

Move to runtime identity. Which credential should be burned, replaced, or tightly scoped?

Plan recovery

Select a failure and list the audit evidence needed to safely retry provisioning.