From the factory floor to the last update — one trust chain.

OnBoardTM IoT Security (OBIS) extends the trust chain established at manufacturing into the device's full 5–10 year lifecycle — covering firmware patches, scheduled key and certificate rotations, and security configuration changes through one governance flow.

Three update types. One governance flow.

Across a device's full field life, three distinct security maintenance needs emerge — firmware vulnerabilities require patches, certificates and keys require periodic rotation, and security configurations require adjustment. The trigger, encryption requirements, and rollback strategy differ for each, but all three share one governance flow.

01 · Firmware update

Patch the code.

Triggered by CVE remediation or functional iteration. Each Update binds a complete SBOM, so the traceability chain extends from build to every OTA cycle.
02 · Key & certificate issuance

Rotate the credentials.

Triggered by certificate expiration, key generation advancement, or algorithm migration.
03 · Configuration update

Adjust the policy.

Triggered by security policy changes, regional rollouts, or runtime parameter tuning.

What the factory embeds. What the device carries.

The capabilities below exist because OBIS controls what happens at the factory. An OTA platform that arrives after manufacturing cannot retroactively embed rotation anchors, targeting tags, or multi-party credentials.

A · Targeting

The device knows who it is.

Each device carries identity tags from the factory — encoding product variant, region, security tier, and more — so the OEM can target by those dimensions without maintaining a cloud-side device registry.
B · Multi-party management

One owner, many partners.

Factory provisioning can embed multiple independent management credentials. Permission boundaries are set at provisioning, not negotiated at runtime.
C · Tracking

Tracking lives at the device level.

The device record tracks update delivery and confirmation across firmware, keys, and configuration, reflecting the fleet’s current state rather than release history.

Two delivery paths.

OEMs with existing OTA infrastructure keep it. OBIS handles the trust layer — signing, authorization, coverage tracking — regardless of how the bytes get to the device.

The relay path carries the package — it never holds the trust. The trust relationship stays between the device and OBIS, so existing OTA investments keep their value and security does not depend on hardening the delivery channel.

See 5–10 year trust maintenance in action.

A platform walkthrough goes through a real update scenario — a CVE patch, a certificate rotation, or a configuration rollout, shows how all three move through one governance flow.