Medical Device & SaMD

Standing Up a Coordinated Vulnerability Disclosure Program

Bill Barksdale, CISSP

In short

A coordinated vulnerability disclosure process gives a researcher who finds something in your product a way to tell you that does not involve guessing at an email address. Section 524B requires one. The mechanics take about a week. What makes it real is naming a person who owns it, not a team.

Section 524B requires a plan to monitor, identify, and address postmarket vulnerabilities, and that plan has to include a coordinated disclosure process. The mechanics of building one are about a week of work. Almost none of the difficulty is in the mechanics.

I have said elsewhere that the failure mode here is a well-written plan describing a process that requires an owner, at a company where nobody is one. This is the article behind that claim.

Why plans end up unowned

It is not carelessness, and it usually is not budget. It is a habit companies learn from every other kind of security assessment they buy.

The pattern runs like this. A company brings someone in to do an audit. A penetration test, an internal security review, a questionnaire-driven assessment, whatever the trigger was. A report comes back. The company clears the severe and the high findings, because those are the ones that look like failure, and then considers the matter closed.

But that report almost always contained two different kinds of output. There were findings, which are discrete and closable, and there were recommendations for ongoing management of the tools and systems, which are neither. The findings get worked. The recommendations get filed. And the thing about ongoing management is that it is only worth anything if someone does it on an ongoing basis, so what actually happens is nothing, until the next audit rediscovers the same conditions or something goes wrong first.

Nobody decided to skip it. The work simply had no owner, so it did not happen. There is a worked example of exactly this dynamic, where every service was purchased, most of them were running, and the one machine that never went through the process was the one that mattered. The process was real. The ownership was not.

A disclosure plan is the same object. It is not a finding you close. It is a standing capability, described in a document, that is worth exactly as much as the person who owns it. Write it with no owner and you have written a description of something you do not have.

The mechanics, which really are about a week

A published route in. A security.txt file at the well-known location, a /security page a human can find, and a monitored security@ alias that is not a named person's inbox. Individuals leave, change roles, and go on holiday. The address should not.

An acknowledgement commitment, stated publicly and stated in business days. Not "as soon as practicable." A number. FDA asks about your timelines directly, and so will an enterprise customer's security questionnaire.

A triage path. Who reads it. Who assesses whether the reported flaw is actually reachable in your product rather than true of the component in the abstract. Who decides severity. Who decides it is a complaint, or a nonconformance, or a CAPA.

A disclosure timeline you can live with, stated up front, before you are negotiating it with someone who has already been waiting.

A route to a fix and out to deployed units, including the awkward case where the affected unit is not connected and the update has to reach it some other way.

A safe harbour statement. Researchers will not test your product if your policy reads like a threat, and the ones who test it anyway will not be the ones who email you first.

None of that is hard. You can have all of it standing by Friday.

The second hop is the part that fails

Here is what I would tell you if you only kept one paragraph.

Every organization I have run or worked inside that handled this well had two things, not one. The inbox, and the hop after the inbox.

When I ran IT operations at NTT, we had a security@ address and it went to the CISO. That is the easy half, and it is the half that gets built. The half that made it work was what happened next: a report that turned out to be an application issue came to me, and I assigned it to my team. Same structure at Ascend Federal Credit Union, where I did not set the process up but was on the receiving end of it. The alias went to the security team, and application-layer issues were routed to the person who owned the application.

That second hop is where disclosure programs die. The alias is easy because it is a configuration change. The hop is hard because it is an org chart question, and it has to be answered in advance for every kind of report you might get. A flaw in your own application code. A flaw in a third-party component you embed. A flaw in a cloud service you depend on. A flaw in a device already in the field. Those go to four different people, and if you have not decided who, the report sits in an inbox while somebody works out whose problem it is.

Write the names down. Not a team, not a role that is currently vacant. A person, in writing, whose job description includes this. A committee is how this fails politely.

The intake you already have

Most companies building this discover they are constructing a second, parallel intake process alongside one that already exists, which is how it ends up neglected. The engineering organization already has a way for work to arrive, get classified, and get routed.

The better design is to make an inbound vulnerability report a recognized item type in the intake you already run, with the same triage step everything else gets: is this device software, does it change a design output, does it meet complaint or CAPA criteria. That is the mechanism that connects a disclosure to your quality system without anyone inventing a procedure under pressure. The disclosure program then adds exactly one thing the existing intake does not have, which is the external route in and the obligation to write back.

The submission version and the running version

What FDA wants to see and what you need for the process to actually run overlap, but they are not the same document, and confusing them produces a plan written for a reviewer that nobody inside the company could execute.

The submission version describes the process, the timelines, and the criteria. The running version has names in it, and lives where the people doing the work will see it. Write the second one first. The first one is a summary of it.

Be honest about cadence

A plan promising a deep monthly review is a plan that gets abandoned in month four, and an abandoned commitment looks considerably worse in an audit than a modest one you actually kept.

Tie review to events rather than to the calendar wherever you can. A dependency update. A component reaching end of support. One of your components appearing in CISA's Known Exploited Vulnerabilities Catalog. Those are triggers that fire when something has actually changed, and they generate a record that shows the process runs, which a quarterly meeting that quietly stopped happening does not.

The test

Your plan is real if you can answer this without hedging.

A researcher emails at four o'clock on a Friday afternoon. They found something in your product. Who reads it? By when? Who decides whether it is real? Who owns the fix if it is in your code, and who owns it if it is not? Who writes back, and what do they say?

If any answer is "someone would probably," you have a document rather than a program. The person on the other end of that email has usually already waited, and is already deciding whether telling you privately was worth it. The researcher in the advisory I took apart recently went through a coordination process that worked, and the outcome was a fixed product rather than a surprise. That is what the week of setup buys you.

This is engineering guidance, not legal or regulatory advice. The content of a postmarket plan submitted to FDA belongs with your regulatory lead.

This is the work I do — FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.

Common questions

Is a coordinated disclosure process actually required?

For a cyber device, yes. The postmarket vulnerability monitoring and disclosure plan required under Section 524B includes a coordinated disclosure process. A connected product with no published route for a researcher to reach you has not met that requirement, regardless of how well the plan describes one.

Do we need a bug bounty?

No. A bounty is a way of attracting reports. Coordinated disclosure is about handling the ones that arrive. Do the second first. Most companies never need the first, and a bounty running into an unowned intake process makes things worse rather than better.

What if the report is about a third-party component?

Your program still owns the triage, the assessment of whether the flaw is reachable in your product, and the communication back to the reporter. You do not own the upstream patch. Your plan should say explicitly how you handle the case where no upstream patch is coming, because that case is common and it is the one people have not thought through.

How fast do we have to acknowledge a report?

There is no universal number, but state yours and keep it. Several business days is defensible. FDA asks about your timelines directly, and 'as soon as practicable' is not a timeline. Silence is the failure mode that turns a private report into a public one.

We are not a medical device company. Do we need this?

Not by statute, but your enterprise customers increasingly ask for it in security questionnaires, and the alternative is a researcher publishing because they could not find anyone to tell. The cost of standing one up is trivial next to the cost of learning about your vulnerability from a blog post.

FDA Section 524B: What Premarket Cybersecurity Actually Requires Your MSP Is Not Your Security Program One Credential, Every Device: Reading a CISA Advisory as a Design Failure FDA Changed Its Cybersecurity Guidance Again. What Actually Moved?

← More in Medical Device & SaMD