Fundamentum — Core Capability

The $37.5M incident
that never happens.

In an ungoverned system, a firmware update is a publish operation. Anyone with credentials can push anything to any device. In Fundamentum, a firmware update is a four-stage authorization workflow — one where the system can say no, and prove it did.

Discuss your governance requirements → ← Back to Fundamentum
$37.5M
Median OTA incident (Forrester)
34th
Percentile — not an outlier
$300–600
Per-device field dispatch cost
Auto
Rollback on health check failure

Why OTA is the highest-risk routine operation

The over-the-air firmware update is the most consequential routine operation in a connected device fleet. A defective update deployed to 10,000 devices simultaneously can brick every device — requiring field dispatch at $300–600 per unit, totaling $3–6M for a modest fleet, before accounting for operational downtime, customer SLA penalties, and reputational damage.

The $37.5M Forrester figure is not a maximum — it is a 34th-percentile outcome. More than two-thirds of major OTA incidents cost more than this. The incidents that reach this scale typically involve not defective code but defective process: an update that was authorized by a credential that should have been revoked, deployed to devices that were in a state where the update was contraindicated, with no rollback mechanism in place.

The four-stage governed workflow

01 · PREPARE
Package & Sign
Firmware signed, integrity verified. Target scope, rollout parameters, health thresholds defined.
02 · AUTHORIZE
Identity Check
Requesting identity verified. Lifecycle state validated per device. Second approver engaged if policy requires.
03 · DELIVER
Staged Rollout
Canary → cohort-based delivery. Health metrics validated at each stage before expansion.
04 · VERIFY
Audit & Confirm
Automatic rollback on failure. Cryptographic proof: who authorized, when, which policy version.

Stage 2 in depth: Authorization

The Authorize stage is where ungoverned OTA processes most commonly fail. Fundamentum's authorization workflow checks:

  • Requesting identity: Is the identity requesting this deployment authorized to deploy firmware to this device category? Is its credential current and unrevoked?
  • Target lifecycle state: Is every targeted device in a lifecycle state that permits a firmware update? Devices in maintenance mode, pending a previous unconfirmed update, or in a customer-defined restricted state are automatically excluded.
  • Policy compliance: Does the deployment conform to the current policy version? Does it require a second approver? Is the target scope within the authorized blast radius for this identity?
  • Cryptographic proof: Every authorization decision — whether grant or denial — is recorded in the tamper-evident audit trail with the full context of why the decision was made.

Stage 3 in depth: Staged rollout

  • Canary deployment: 1–5% of fleet receives update first. Health metrics collected over a defined window before expansion.
  • Configurable cohort size: 10%, 25%, 50%, 100% — or custom percentage with manual approval gates between stages.
  • Health check thresholds: Operator-defined metrics (connectivity, error rate, sensor readings). A cohort that fails health checks halts the rollout automatically — no operator intervention required.
  • Automatic rollback: Devices that fail their health check window revert to the previous firmware version. The rollback is itself a governed operation with an authorization record.