Service — Keep it clean
Clearance is the start of the obligation, not the end of it.
Section 524B(b)(1) commits you to monitoring, patching, and coordinated vulnerability disclosure for as long as the device is supported. Most teams write that plan for the submission and then discover that running it every month is somebody’s whole job. We run it.
What you actually committed to.
The postmarket plan in your submission is a promise about process. It says you will monitor for vulnerabilities in your software components, assess what you find against patient safety, patch on a defined basis, and give security researchers a way to reach you.
Then the device ships, the team moves to the next product, and the plan runs on goodwill. Six months later the SBOM is stale, nobody has looked at a vendor advisory, a component quietly went past end of support, and there is no record of any of the decisions that were — or were not — made.
That gap shows up in three places: an audit asking for the records, the next submission for the next device on the same platform, and, occasionally, a real vulnerability in the field with no process ready to handle it.
An SBOM that was accurate on the day you filed does not satisfy the intent of the requirement. The guidance is interested in the lifecycle: how the SBOM is regenerated, who is accountable for its accuracy, how it is validated, and how a customer obtains the current version after the device is on the market.
The artifact is the easy half. The process behind it is what is actually being asked for.
The monitoring loop, run on a defined cadence.
Same steps every cycle, with a record at each one. The value is not that any single step is difficult — it is that all seven happen, on schedule, and produce evidence.
Refresh the inventory
SBOM regenerated from the build for each supported release and configuration in the field — including transitive dependencies, cloud back-end components, and companion apps. What is deployed, not what the roadmap says is deployed.
Ingest the sources
National vulnerability data, the CISA Known Exploited Vulnerabilities catalog, upstream vendor and distribution advisories, and end-of-support announcements for every component you depend on.
Triage against your device
The step tools cannot do alone. Is the vulnerable code path reachable in your configuration? Is the interface exposed? What is the exploitability in a lab or clinical network, and what is the patient impact if it is exploited? Most findings are not applicable — and saying so needs a written rationale.
Score and decide
CVSS v4.0 with environmental and modified metrics, residual risk after existing controls, and an explicit decision: patch now, patch on the next release, apply a compensating control, or accept with rationale. Each with a named owner and a date.
Act
Where a patch is warranted, it goes through change control with verification scoped to the change — and through the validated-configuration reality of a lab that cannot take unplanned downtime. Where a compensating control is the answer, it gets documented and communicated.
Communicate
Customer-facing security notices, updated security documentation, current SBOM made available on request, and coordination with the disclosure timeline where a researcher or upstream vendor is involved.
Record
Every cycle produces evidence: what was reviewed, what was found, what was decided, why, and by whom. Filed where an auditor expects to find it and reusable in your next submission.
Feeding back into engineering. A component that generates a finding every quarter is not a monitoring problem, it is an architecture problem. Part of this service is noticing that pattern and telling you, rather than dutifully triaging the same dependency forever.
A postmarket obligation
Coordinated vulnerability disclosure, actually operating.
Required under §524B(b)(1) — and a published policy nobody is monitoring is worse than none. It invites a report you will not answer, and the researcher’s next step is publication.
- A published policy and a monitored intake path, with a security contact that reaches a human
- Acknowledgement and triage commitments you can meet, not aspirational ones
- Assessment of each report against the device, the threat model, and the risk file
- Researcher communication handled professionally, including the cases where the report does not reproduce
- Disclosure timeline coordination, advisory drafting, and CVE handling where warranted
- Escalation into your complaint handling, CAPA, and reportability processes, because a security report can become a regulatory event
- Optional information-sharing organization participation, so you are receiving intelligence and not only fielding it
- A full record of every report and its resolution
Where this connects to the rest of your QMS. Cybersecurity events do not stay in a cybersecurity box. A credible vulnerability report may trigger complaint handling, a risk file update, a CAPA, and a reportability assessment. We wire the interfaces to your existing procedures explicitly, so the first real event is not the moment you discover they were never connected.
What arrives, and when.
Cadence is set to your risk profile and release rhythm — monthly for a networked instrument fleet, quarterly for something simpler. Urgent findings do not wait for the cycle.
Vulnerability report
Refreshed SBOM, new findings with scoring and applicability rationale, KEV-flagged items called out separately, decisions taken, and open items with owners and dates. Written to be read by engineering and filed by quality.
Priority alerts
A known-exploited vulnerability in a component you ship, or a disclosure report that reproduces, does not wait for the next report. You get it immediately, with an initial assessment and a recommendation.
Posture review
Threat model and architecture views revisited against how the product and its environment have actually changed, metrics trended, end-of-support horizon reviewed, and a candid read on what needs engineering attention in the next year.
Customer response support
Hospital and laboratory IT security questionnaires, MDS2-style disclosure statements, SBOM requests, and the “are you affected by this” email that lands the morning after a headline vulnerability. Answered consistently, so your field team is not improvising.
Regulatory support
Records pulled and packaged for an audit, an inspection, or the postmarket section of the next submission on the same platform. This is the compounding benefit — a running process makes the next filing dramatically cheaper.
A dedicated engineer
Someone who knows your architecture and can be reached when something happens. Not a shared queue, and not a different analyst every cycle relearning what your device is.
Legacy instruments and the fleet you inherited.
A large share of this work starts with a product that shipped before any of this existed, running on an operating system past support, with an SBOM nobody has ever produced.
- Build a real inventory of what is deployed, by release and configuration — usually the hardest and most valuable step
- Generate the SBOM for what is actually in the field, including the parts nobody documented
- Establish a current-state vulnerability position with a defensible written rationale
- Separate what must be patched from what can be compensated, and say why
- Set an end-of-support and communication plan customers can plan around
- Sequence remediation against a release cadence and labs that cannot take downtime
We do not sell a monitoring platform, which means we have no reason to tell you that you need one. If you already run an SBOM or product-security tool, we operate inside it. If you do not, we will recommend one that fits your stack and your budget, or run the process with tooling you own.
Platforms are good at ingesting feeds and matching components. They are not good at deciding whether a vulnerable code path is reachable in your configuration, or what a finding means for a patient. That judgment is the service, and it is why a tool alone leaves you with a queue instead of an answer.
Standards and sources we work against
Questions about postmarket.
Can you monitor a device you did not build?
Yes, and most of this work is exactly that. We need a reliable component inventory and enough architectural understanding to judge whether a finding is reachable. If no SBOM exists, producing one is the first phase — and it is frequently the most useful thing that happens all year, because teams routinely discover components nobody knew were shipping.
Do we have to patch everything you find?
No, and a process that tried to would be unrunnable. The requirement is that you assess, decide, and document — not that you remediate every CVE that touches a component. A written rationale for not patching, grounded in reachability, exposure, and patient impact, is a legitimate and expected outcome. What is not legitimate is having no record that you looked.
Who owns the decisions?
You do. We do the monitoring, the analysis, the scoring, and the recommendation, and we prepare the record. The manufacturer holds the regulatory obligation and makes the call. In practice most cycles are routine and a few need a real conversation — those are the ones worth your time, and part of our job is making sure they are the only ones that take it.
How does this interact with our complaint handling and CAPA?
Explicitly, by design. A credible vulnerability report can become a complaint, a risk file update, a CAPA, and a reportability assessment. We define those interfaces to your existing procedures at the start of the engagement rather than working it out during the first real event.
What happens if there is a real incident?
You have a dedicated engineer who already knows your architecture, a current SBOM, a threat model to reason against, and a documented process for triage, decision, and communication. That is most of incident response. We support the technical investigation and the customer and regulatory communication; your team makes the decisions and holds the obligation. Having the groundwork in place before the phone rings is the entire value of this service.
Is this a retainer or project work?
A standing engagement, because the obligation is standing — scoped per device or per platform, at a cadence matched to your risk profile. Legacy-fleet cleanup usually runs as a project first, then transitions into the ongoing cycle once there is something reliable to monitor.
Start with a conversation about your device.
Thirty minutes with a senior medical device software expert who understands both the regulatory requirements and the business realities of bringing software to market. Bring your architecture, your submission type, and your timeline. You will leave knowing which artifacts you are missing and what it takes to close them.
- Submission type and target date — 510(k), De Novo, PMA, IDE, or a postmarket change
- A block diagram or architecture sketch, however rough
- Your interface list: network, LIS, USB, wireless, cloud, service ports
- Whatever cybersecurity documentation exists today, including nothing at all
- Any FDA correspondence you have already received