Implement Security
What you must know
Security spans identity, transport, and data. Know per-device SAS keys, X.509 certificates, and shared access policies with least privilege. Understand TLS for transport and that IoT Hub requires TLS 1.2 by default. Know Azure Defender for IoT for threat detection and IoT Hub security recommendations.
Know private endpoints and managed identities to remove secrets from code. Understand module identity and the edgeHub security model, and DPS attestation as a security boundary. Know key rotation and the difference between symmetric key and certificate authentication.
Traps
- Granting registry write to a service that only needs service connect - violates least privilege.
- Assuming device keys can be retrieved after creation - they can be regenerated but not read back in all flows.
- Forgetting that private endpoints require DNS configuration to resolve the hub's private IP.
- Confusing Defender for IoT (threat detection) with Azure Security Center recommendations (configuration posture).
Rule of thumb
Use managed identities for service-to-hub access and per-device credentials for device-to-hub access. Never embed a hub-level shared access key in device code; that key can access every device.
Worked example
A backend service reads telemetry from the built-in endpoint. Instead of a hub-level SAS key, assign a managed identity with the IoT Hub Data Reader role. This removes a long-lived secret and limits blast radius if the service is compromised.