Compare IoT onboarding methods by security, scale, user friction, and operations effort
animation
security
provisioning
device-identity
comparison
interactive
An interactive provisioning decision animation with scenario presets, method scoring, Play/Step/Reset controls, quick reference, technical accuracy notes, and practice prompts.
animationsecurityprovisioningcomparison
Device Provisioning Method Comparison
Compare common IoT onboarding methods by matching them to a deployment scenario. The score is a teaching heuristic for tradeoff discussion: a real architecture still needs threat modelling, supply-chain controls, credential lifecycle planning, and vendor-specific constraints.
Manufacturer certBest current method
91%Scenario fit
operations effortMain tradeoff
1. scenarioReview step
TryRaise Fleet scale from 1 / 5 to 5 / 5 and use Step, keeping the scenario and operational-maturity choices fixed.
ObserveAt large fleet scale, the fit score favours automated certificate or voucher onboarding over methods that require per-device manual setup.
Technical boundariesFor Device Prov Comparison checkpoint 25, treat 5 / 5 as a bounded input because vendor pricing, staff skill, regional regulation, supply-chain trust, protocol interoperability, and measured enrolment failure rates remain outside this model.
Colour keywifi mobile identitycurrent / primaryreference / datasuccesscautionerror / failure
--
--
--
--
Scenario Controls
Start with a realistic deployment, then adjust what matters: fleet size, security need, user setup tolerance, operations maturity, connectivity, and certificate lifecycle.
Higher means thousands of devices or remote installation.
Higher means strong device identity, auditability, or regulated data.
Higher means installers or users cannot handle complex manual steps.
Higher means the team can run PKI, templates, logs, and rotation.
Higher means devices can reach a cloud or bootstrap service early.
Higher means rotation, revocation, decommissioning, and audits matter.
Provisioning Quick Reference
QR / app setup
Good for consumer onboarding with local user presence.
QR code normally carries a setup payload, not the final long-term secret.
Security depends on the protocol and verifier, not just the QR code.
X.509 certificates
Strong device identity when private keys are protected.
Needs CA policy, issuance, renewal, revocation, and monitoring.
Often used with mutual TLS and fleet management.
Zero touch
Best when devices must enroll without manual steps.
Still depends on factory trust anchors and secure bootstrap services.
Operational readiness is the main cost.
JIT provisioning
Creates device resources when a trusted device first connects.
Requires strong claim matching and safe provisioning templates.
Useful for flexible cloud-native fleets.
Technical Accuracy Notes
Decision model scope
The score is a learning heuristic. Real selection depends on hardware trust, manufacturing process, cloud platform, protocol, regulation, and threat model.
PSK caution
Token or PSK methods can be useful for prototypes and constrained deployments, but shared or long-lived secrets create rotation and compromise problems at scale.
Supply chain matters
Zero-touch and manufacturer-certificate methods are only as strong as credential injection, private-key protection, factory controls, and enrollment policy.
User friction is security-relevant
A method that is too hard to use can cause skipped checks, reused credentials, or support workarounds. Usability is part of the security design.
Practice Prompts
Factory fleet
Select industrial fleet. Lower operations maturity. Which methods lose fit, and why?
Consumer product
Select smart home kit. Raise security need. Which QR/app assumptions must be strengthened?
Prototype trap
Select lab prototype and raise fleet scale. Why does token/PSK become less attractive?
Cloud onboarding
Select cloud platform. Lower first-boot connectivity. What breaks in a JIT-style design?