Device Provisioning Security Analysis
Inspect provisioning trust boundaries, attack surfaces, and the controls that keep bootstrap trust from becoming production risk
Device Provisioning Security Analysis
Move through provisioning trust boundaries and see why a device is not safe just because it can connect. The lab shows the asset at risk, the required control, the attack path, and the remaining risk after controls are applied.
Device provisioning security controls and trust-boundary outputs
BRSKI trust-boundary analysis
Inspect the pledge, registrar, MASA voucher, EST enrollment, and runtime domain boundary.
Trust boundary map
Factory-root security decides whether the device starts with unique, verifiable identity evidence.
Security score
Asset at risk
Factory identity and manufacturer root of trust.
Required control
Unique per-device identity, protected key storage, and auditable manufacturing records.
What can go wrong
No attack focus is injected. The selected controls keep this boundary in the baseline state.
Security Controls
Select the deployment scenario, choose an attack focus, then toggle controls to see how residual risk changes.
Trust Boundary Quick Reference
Protect private keys, bootstrap identity, firmware, secure boot state, and local storage from cloning or extraction.
Treat discovery, DNS, local radio, and first internet contact as hostile until authenticated by the provisioning method.
Separate real device proof from authorization to join a specific account, tenant, owner, or domain.
After onboarding, enforce scoped credentials, renewal, revocation, logging, update support, and decommissioning.
Control Checklist
Use unique per-device identity or ownership evidence. Avoid shared fleet secrets and unaudited setup codes.
Verify who may claim the device before production access is issued. A genuine device can still join the wrong tenant.
Replace temporary bootstrap evidence with scoped operational credentials and a policy matched to the device role.
Keep a path for renewal, revocation, update, monitoring, and recovery after a provisioning failure or compromise.
Technical Accuracy Notes
RFC 8995 defines pledge, registrar, MASA, voucher, and EST integration concepts for bootstrapping remote secure key infrastructure.
RFC 7030 defines certificate enrollment and CA certificate distribution over secure transport.
NISTIR 8259A frames device identification, configuration, data protection, update, and cybersecurity state as core IoT capabilities.
OWASP IoT highlights weak credentials, insecure interfaces, insecure update, and insufficient device management as recurring IoT risks.
Practice Prompts
Select each scenario and name the first point where an untrusted zone is allowed to influence identity.
Disable mutual authentication or owner authorization. Which attack becomes easier, and why?
Select leaked bootstrap and compare scoped runtime with lifecycle disabled. What would you revoke?
Choose a failure and list the telemetry needed to prove whether it was device, owner, network, or service side.