Our provisioning workflow is rejecting devices that don’t match the firmware baseline version we’ve configured. This is causing significant delays in our device rollout because we have mixed firmware versions in our inventory. The firmware baseline enforcement seems too rigid and we need devices operational quickly.
Provisioning logs show:
FirmwareValidationError: Device firmware v2.3.1 does not match baseline v2.4.0
Provisioning rejected for device ID: SENSOR-8842
Required action: Firmware update to baseline version
Is there a way to relax the firmware version checking during provisioning while still maintaining our automated update workflow? We need to get these devices online and then push updates, rather than blocking provisioning entirely.
The firmware baseline enforcement is actually a security feature, not a bug. Allowing devices with outdated firmware to provision creates vulnerabilities. That said, you can configure a firmware version tolerance range in your provisioning rules rather than requiring exact match to baseline.
I’d recommend against relaxing firmware validation. Instead, implement a two-stage provisioning approach: provisional registration for devices below baseline, followed by mandatory OTA update before granting full operational status. This maintains security while allowing devices to connect for updates. ThingWorx supports this pattern through provisioning state management.
The two-stage approach sounds promising. Can you elaborate on how to configure provisional registration? Our current setup is binary - either the device meets firmware baseline and provisions, or it’s rejected completely. We need the middle ground where devices can connect for updates but have limited operational capability until firmware is current.