Evidence as a byproduct of how you operate.

Compliance does not need to be a separate project. OnBoardTM IoT Security (OBIS) turns daily operations — signing, authorizing, provisioning, updating — into an audit trail. The Compliance&Disclosure module aggregates evidence — it does not create it. ENISA submissions, audit reports, and CVD responses all draw from one source.

The CRA clock is running.

The CRA timeline is fixed. ENISA's 24-hour, 72-hour, and 14-day reporting cadence becomes a continuous obligation in September 2026. Full conformity follows in December 2027. The question is no longer whether a structured compliance program is required — only how much runway is left.

In effect

DEC 2024

CRA enters into force

Transition period begins. OEMs selling into the EU start building vulnerability disclosure, SBOM, and lifecycle security capabilities.
In effect

AUG 2025

EU RED DA + EN 18031

Radio Equipment Directive Delegated Act is now mandatory. Wireless devices sold in the EU require cybersecurity conformity under harmonized standards.
Upcoming

SEP 11, 2026

Vulnerability reporting begins

ENISA-mandated cadence: 24-hour early warning, 72-hour notification, 14-day technical report. Structured evidence required on demand.
Upcoming

DEC 11, 2027

Full CRA compliance

Non-conforming products can no longer be placed on the EU market. CE marking requires demonstrable security-by-design across the device lifecycle.

Every action writes a record. Compliance & Disclosure reads them.

Production Versions, Production Batches, VEX Decisions, Update Jobs, and Device Asset Records (DARs)are native OBIS data objects. The module does not reconstruct history — it reads from the same event stream that operations already produce. One source, many outputs.

Build compliance once. Reuse the evidence.

OBIS is built to the EU CRA — today's strictest framework. Because regulators agree more than they disagree, the same operational record stream maps cleanly to other major frameworks as they come into scope, with no parallel evidence program per region.

Mandatory
Covered by companion standard
Not a direct requirement
IEC 62443-4-2 does not directly mandate SBOM; the requirement is covered by its companion standard IEC 62443-2-4 (supply chain security), with which 4-2 is typically procured.
IEC 62443-4-2 mandates patch ability; the vulnerability handling process itself is covered by IEC 62443-2-1 (security management system) and IEC 62443-2-4.
RED DA itself does not directly mandate vulnerability disclosure to authorities; the harmonized standard EN 18031 includes vulnerability monitoring and handling under VLM clauses.

ENISA submissions, on demand.

CRA Article 14 defines three reporting windows triggered by an actively exploited vulnerability. Early warning (24h) and notification (72h) start when the manufacturer becomes aware; the final technical report (14d) starts when a corrective or mitigating measure is available. Each window requires a structured submission to ENISA — and each one maps directly to OBIS data objects.

24h

EARLY WARNING

First signal to ENISA.

Initial notification of an actively exploited vulnerability. Identifies the affected product and the first assessment of severity.
Pre-filled from OBIS
Production Version identifier + CVE number
CVSS / EPSS initial severity
Exploitation signal source

72h

Notification

Confirmed scope and impact.

Detailed notification: affected Production Versions, Production Batches, device counts, geographic distribution, and interim mitigations.
Pre-filled from OBIS
Affected Production Version list
Production Batch + device count
VEX decisions + interim mitigations

14d

Technical report

Full incident documentation.

Root cause, remediation path, OTA rollout plan, residual risk, and per-device update coverage.
Pre-filled from OBIS
SBOM + component provenance
OTA targeting + rollout plan
Per-device update receipts + coverage

See compliance as an operational byproduct.

A 30-minute demo walks your target regulation against the records OBIS already produces.