The May 2026 postmarket cybersecurity guidance turned SBOM drift from a paperwork footnote into a cybersecurity control. The auditor is no longer satisfied with a written policy — they want evidence that the program is running in production, on the device as deployed, anchored to the 510(k) that was cleared. Here is how Korvantis findings map to the controls they will read.
First, the vulnerability handling plan. Every CVE that hits CISA KEV triggers a reachability check against the function path actually running on the device. The finding is filed against the vulnerability handling plan entry that should have caught it, with a timestamp and the DHF row it ties back to. A routine closure writes its own evidence; a recall-grade finding escalates with a draft notification ready for your Quality lead.
Second, the software bill of materials. The SBOM on file at the submission has to match the SBOM running on the device. Korvantis surfaces any drift — a transitive library added in a CI bump, a vendor binary rotated without a catalogue update — as a finding tied to the design-control row that introduced the change.
Third, postmarket surveillance. The surveillance record has to be a unified, timestamped audit trail a regulator can read without reconstruction. Korvantis produces that record as a single hash-anchored package per quarter per submission, generated from the same evidence store the agents have been writing to all quarter, not rebuilt for the audit.