Device Provisioning at Scale with Intermittent Connectivity

For TPM 2.0 devices, use individual enrollments with TPM attestation. The device proves possession of the endorsement key and produces a quote signed by the TPM; DPS validates against the enrollment's endorsement key. This satisfies the requirement that attestation be tied to a hardware root of trust and avoids embedding shared secrets. Individual enrollments are appropriate because each device has a distinct hardware identity and the fleet is large but managed per-device at manufacture.

For legacy devices without TPM, the realistic options are symmetric key attestation (individual or group enrollment) or X.509 certificate attestation if a per-device certificate can be injected. Symmetric key group enrollment scales well but means a shared group key; individual symmetric key enrollment limits blast radius if one key leaks.

The judgement: the security constraint (no embedded shared secrets, hardware root of trust) is satisfiable only by TPM or X.509 for those devices. Legacy devices are a documented exception - the team must decide whether they are acceptable risk with symmetric keys scoped narrowly, or whether they should be excluded from the fleet until replaced. Do not claim TPM attestation works on devices without a TPM.

Duplicates arise because each commissioning attempt creates a new registration. Fixes:

1. Derive a deterministic registration ID from the hardware serial number (for example a hash or normalized serial). DPS registration IDs are the identity key in the enrollment list; re-running with the same derived ID updates rather than duplicates - provided the enrollment type supports reuse (individual enrollment) or the device's attestation maps to the same registration.
2. Use individual enrollments keyed to hardware identity for TPM devices, so a repeated attempt matches the existing endorsement key rather than creating a second record.
3. Make commissioning idempotent: query the enrollment/registration state before creating, and treat "already registered" as success with reconciliation of desired properties.
4. Handle the allocation outcome: if the device is already registered to the intended hub, return success; if registered to the wrong hub, use the documented re-provisioning path (deprovision and re-enroll) rather than creating a parallel record.

Judgement: the root cause is non-deterministic identity plus create-only logic. Fixing identity derivation and making the workflow idempotent is more robust than cleaning up duplicates afterward.

Regional assignment belongs in DPS allocation policies, not in device firmware. Options:

• Custom allocation via an Azure Function that inspects device data (for example a deployment-region tag reported at registration) and returns the target hub. This fits "closest to deployment region" when region is known at commissioning.
• Static allocation per enrollment if factories always ship to known regions.
• Lowest latency allocation if the device can be placed by measured latency.

For failures mid-assignment: DPS retries and the device should retry with backoff. If the device registers to the wrong hub because of a stale tag, the team must deprovision from the wrong hub and re-enroll; you cannot silently move a registration. Design the custom allocation function to be idempotent and to log the decision so misassignments are diagnosable.

Judgement: keep allocation logic server-side and versioned, make the function deterministic for a given device, and plan an explicit remediation path for misassignment rather than assuming re-registration is free.