Why secure provisioning belongs in production
A connected device that ships without identity has to be provisioned in the field. Field provisioning means a manual step (or a vulnerable auto-enrollment) at install time. Both create operational pain and security exposure.
Production-side provisioning gives the device a unique cryptographic identity before it ships. The device boots, authenticates, and enrolls without manual intervention.
Secure elements
Microchip ATECC608 and NXP EdgeLock are common secure elements for IoT. Both support:
- ECC private key generation inside the chip (key never leaves)
- Certificate signing and verification
- Counter-based replay protection
- Tamper-evident behavior
The production line generates a key inside the secure element, signs a certificate against the root CA, writes the certificate to the device, and logs the public key against the serial.
X.509 certificate enrollment
X.509 is the standard certificate format. Production-side enrollment typically follows this pattern:
- Secure element generates ECC key pair (private key locked in chip)
- Production system reads public key
- Production system signs certificate using HSM-backed root CA
- Certificate written back to device
- Public key and certificate fingerprint logged against serial
The root CA private key never touches the production line. It lives in an HSM in a controlled environment.
AWS IoT and Azure DPS
AWS IoT supports Just-in-Time Provisioning (JITP) and Multi-Account Registration. Azure Device Provisioning Service (DPS) supports X.509 attestation, Trusted Platform Module (TPM) attestation, and symmetric key attestation.
Both let the production line preregister devices so they enroll automatically at first cloud connection. The production-side workflow:
- Device provisioned with X.509 certificate
- Device certificate fingerprint registered with cloud DPS
- Device boots in field, presents certificate, enrolls automatically
- Cloud assigns device to correct group, downloads configuration
Custom PKI follows the same pattern with internal infrastructure instead of AWS or Azure.
Production-side workflow that works
- HSM-backed root CA in a controlled environment, accessed through signing API
- Per-unit key generation inside secure element on the line
- Certificate signing through API call (no key material exposed)
- Cloud DPS preregistration as part of provisioning step
- Per-unit enrollment record logged in production database
- Optional revocation list management for end-of-life or lost devices
Common pitfalls
- Root CA private key stored on the production line (not in HSM)
- Same key burned into multiple devices ("test mode that shipped")
- Certificate fingerprint logged but not preregistered with cloud DPS
- Provisioning workflow done by hand on a few units, never scaled
Sources
- AWS IoT Just-in-Time Provisioning documentation
- Microsoft Azure Device Provisioning Service documentation
- Microchip ATECC608 secure element documentation
- NXP EdgeLock secure element documentation