Device Identity & Provisioning

Why device identity matters¶

Without a verified identity, every device is a potential attacker. The Mirai IoT botnet infected hundreds of thousands of devices via default credentials. A camera, a sensor, a gateway — anything without identity is an open door into your network.

Device identity is not an optional security feature. It is the foundation of the entire IoT stack. Without identity you cannot: authorise access to data, deliver configuration to the right device, audit who did what, or remotely manage your fleet.

Zero-touch provisioning¶

How it works¶

1. Manufacturing: A unique identifier and enrolment credentials (bootstrap certificate or registration token) are written to the device on the production line
2. First boot: The device powers on, connects to the provisioning service and presents its enrolment credentials
3. Verification: The provisioning service verifies credentials against the enrolment database
4. Certificate issuance: After verification the device receives its runtime certificate and configuration
5. Operational: The device is fully operational — communicates with the backend via mTLS

Entire process under 30 seconds. No technician, no laptop, no manual steps. Unbox, power on, it works.

Enrolment flows¶

Different scenarios require different enrolment methods:

Manufacturing provisioning: Certificate or seed written on the production line. Most secure — identity is in the device from birth. Requires integration with the manufacturing process. Suitable for own hardware.

Field provisioning: Technician holds a phone near the device, scans a QR code, device activates. Simpler deployment, suitable for retrofitting existing hardware. Mobile provisioning app with offline support.

Self-provisioning: Device registers itself via an enrolment service. Operator confirmation in the management console. Suitable for BYOD scenarios or dev/test environments.

Group enrolment: All devices from one production batch share a group certificate. After first connection they receive an individual runtime certificate. Simplifies manufacturing while preserving individual identity.

X.509 certificate infrastructure¶

PKI architecture¶

Three-level hierarchy for enterprise IoT:

• Root CA: Offline, in HSM. Signs intermediate CAs. Validity 10-20 years.
• Intermediate CA: Signs device certificates. Separate per environment (prod, staging) or per region. Validity 3-5 years.
• Device certificates: Unique per device. Validity 1-2 years. Automatic rotation.

HSM (Hardware Security Module): The Root CA private key never leaves the HSM. Azure Key Vault, AWS CloudHSM, or on-premise HSM (Thales, Utimaco).

Mutual TLS¶

Every device ↔ backend communication is mutually authenticated:

• Device verifies the backend certificate (protection against a rogue server)
• Backend verifies the device certificate (protection against a rogue device)
• Encrypted channel (TLS 1.3)
• No shared secrets, no plaintext API keys

Certificate lifecycle¶

Issuance → Rotation → Revocation

• Automatic rotation: Device requests a new certificate before the old one expires. Overlap period — both certificates are valid. Zero downtime.
• Revocation: A compromised certificate is revoked immediately. CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol). Backend rejects connections with a revoked certificate.
• Emergency rotation: Mass rotation of the entire fleet in response to a security incident. Staged rollout — not all devices at once.

Fleet management¶

Device twin / Device shadow¶

Virtual representation of the physical device in the cloud. Two states:

• Desired state: What we want — configuration, firmware version, parameters. Set by the operator.
• Reported state: What is — current configuration, firmware, sensor status. Reported by the device.

Difference between desired and reported = action. Desired firmware v2.1, reported v2.0 → OTA update triggered automatically.

Fleet-wide operations¶

• Grouping: By location, device type, firmware version, customer. Dynamic groups (query-based).
• Bulk operations: Change configuration for an entire group with a single command. Firmware update for all devices in a region.
• Monitoring: Fleet-level metrics — how many devices online, offline, in error state. Drill-down to individual devices.
• Lifecycle: Provisioning → Active → Maintenance → Decommissioning. Automated workflow per state.

Alerting¶

• Device offline longer than threshold → alert
• Certificate expiring within 30 days → auto-rotation or alert
• Firmware version below minimum → forced update
• Anomalous behaviour (unusual traffic, unexpected location) → security alert

Cloud and on-premise¶

Azure IoT Hub DPS¶

Device Provisioning Service for Azure:

• Automatic enrolment from manufacturing
• Load balancing across multiple IoT Hubs
• Re-provisioning when devices move between IoT Hubs
• Custom allocation policies (geolocation, workload balancing)
• Integration with Azure Key Vault for certificate management

AWS IoT Core¶

• Thing registry with thing types and thing groups
• Fleet provisioning templates
• Just-in-time provisioning (JITP) — certificate registered on first connection
• Bulk registration via S3

On-premise / hybrid¶

For isolated networks (production halls, critical infrastructure):

• HashiCorp Vault as PKI backend — certificate issuance, rotation, revocation
• Custom provisioning service running in the local network
• Cloud sync via secure gateway for centralised fleet management
• Air-gapped provisioning for highest-security scenarios

Technology stack¶

PKI: HashiCorp Vault, Azure Key Vault, AWS Certificate Manager, step-ca, OpenSSL.

Provisioning: Azure IoT Hub DPS, AWS IoT Core, custom enrolment service.

Fleet management: Azure IoT Hub, AWS IoT Core, custom fleet dashboard (Grafana).

Infrastructure: Terraform, Ansible, Docker, Kubernetes.

Security: HSM, TPM, Secure Boot, IEC 62443 compliance.

Souvisí s