SBOM & Vulnerability

From a CVE to the exact device. In hours, not weeks.

CRA vulnerability notification obligations take effect in September 2026, including 24-hour early warning requirements. OnBoard™ IoT Security (OBIS) keeps SBOMs, provisioning records, and OTA state on the same operational trust chain — so the path from a CVE to the affected device serial resolves through a single query.

Lifecycle Traceability

Trace vulnerability exposure across release, production, and deployed state.

SBOMs, provisioning records, and device state remain cryptographically linked across build, provisioning, and OTA operations — so exposure analysis always reflects the device's current state.

L1 · Release Version

Which releases are affected.

Each signed release carries its SBOM and dependency record forward into provisioning and OTA operations, preserving traceability across the lifecycle.

L2 · PRODUCTION BATCH

Which production runs are affected.

Provisioning records bind each production batch to its authorized release version, with EdgeHSM signatures making the association tamper-evident.

L3 · DEVICE STATE

Which deployed devices remain exposed.

Per-device state tracks firmware, credentials, updates, and rollback history — so exposure maps reflect the device's current operational state, not historical deployment data.

Vulnerability Operations

Operational vulnerability response across the product lifecycle.

OBIS connects vulnerability intelligence, production history, OTA state, and VEX decisions into a single operational workflow — so exposure analysis and remediation tracking stay tied to the device's current state.

Q1 · SEVERITY

How relevant is the vulnerability?

CVSS scores are only the starting point. OBIS correlates exploitability, runtime reachability, and known exploitation activity to identify which vulnerabilities actually matter to the deployed product.

Q2 · EXPOSURE

Which devices remain affected?

From release version to production batch to deployed device state, OBIS maps exposure based on the device's current operational state — automatically excluding devices already remediated through OTA updates.

Q3 · REMEDIATION

What action should be taken?

Patch, mitigation, or not affected — every remediation decision becomes part of the governed operational record. Manufacturing authorization and OTA deployment remain coordinated under the same trust workflow.

Q4 · COVERAGE

Was remediation actually completed?

Device state records continuously confirm remediation coverage across deployed products, tracking affected, remediated, and remaining exposure directly from operational state.

Disposition Governance

Every vulnerability decision becomes part of the governed record.

Vulnerability assessments, remediation decisions, and deployment coverage remain attached to the governed product record throughout the lifecycle.

Affected

The vulnerable code path is reachable under the device's operational conditions, triggering remediation tracking through deployment closure.

Not Affected

The vulnerable component exists, but runtime conditions, architecture boundaries, or compensating controls prevent exploitation within the deployed product context.

Under Investigation

The vulnerability has been matched to a governed release, but analysis and remediation decisions remain in progress.

Fixed

A remediated release has been signed and deployed through manufacturing updates or OTA operations, with coverage tracked until exposure is cleared.