The software bill of materials your 510(k) was cleared against is already out of date.

What SBOM drift really means in a postmarket program

SBOM drift is the silent delta between the bill of materials a regulator cleared and the system actually running on a shipping device. An open-source dependency sneaks in via a routine CI bump. A vendor rotates their binary and ships a new revision that does not match the catalogue line in the original submission. A new transitive dep is pulled in to support a feature no one remembers adding. Each individual change looks small; cumulatively, they shift the device away from the design controls that were authorised.

For a 510(k) program, drift is not a question of taste. Section 524B of the FD&C Act requires manufacturers to submit a software bill of materials, run a vulnerability handling plan, and demonstrate a postmarket surveillance process. When the device on the floor stops matching the SBOM you cleared, the controls in that plan stop applying — the assumption the regulator relied on is gone. The longer you go between rev chain verification, the more a regulator has to re-derive authorship, reachability, and threat-model updates from a snapshot they cannot trust.

How Korvantis detects drift on a continuous cadence

Korvantis runs the SBOM diff on every device fleet on a 4-hour cadence. Every component is re-hashed, mapped back to the canonical bill of materials, and compared against the design-control row it ties to. New transitive dependencies, version bumps, and unaccountable binaries surface in minutes — not in the next quarterly review — and the finding is filed against the DHF row that introduced the component, the 510(k) the submission was anchored to, and the threat-model row the dependency affects.

The detection loop runs against the device, not the upstream package: CISA KEV is pre-screened, but reachability is checked against the function path actually deployed, not what the datasheet implies. Routine findings close themselves with evidence attached — a hash, a timestamp, the DHF row. A senior reviewer is looped in — with the evidence package, the affected DHF, and a draft notification — only where the finding is FDA-reportable or recall-grade.

How SBOM drift ties into FDA Section 524B

Section 524B and the February 2026 postmarket cybersecurity guidance turn bill-of- materials drift from a paperwork problem into a control problem. The submission package has to demonstrate a vulnerability handling plan that is running in production — not a document the manufacturer claims they follow. The bill of materials submitted to the agency has to match the bill of materials running on the device. The postmarket surveillance record has to be a unified timestamped audit trail a regulator can read without reconstruction.

Korvantis maps every signal to those controls. A new transitive dep lands — the finding is tied to the design-control row and the vulnerability handling plan entry that should have caught it. A CVE is added to CISA KEV — the reachability check, the evidence package, and the postmarket surveillance attachment are written before the next quarterly review. The 524B narrative is not a separate narrative — it is the same evidence store the agents have been writing to all quarter, generated as a signed, time-anchored package per submission per quarter.

What good evidence looks like for the regulator

A Section 524B audit-trail reads from the same source data the agents authored. The hash chain is anchored to write-once storage; the version of the SBOM, the version of the threat model, and the design-control row each signal ties back to are reproducible a hundred days later. That is the bar the closed loop is designed to clear: the artifact a regulator reads is not a one-off rebuild, it is the same evidence store the team has been operating against. A 50-person MDM without a dedicated cybersecurity team can stand behind it on day one, not after they hire one.

Frequently asked

The five questions we hear most from Quality and IT leads after a Section 524B briefing.