Medical Device & SaMD

Does a Security Patch Require a New 510(k)?

Bill Barksdale, CISSP

In short

A change made solely to strengthen cybersecurity, with no other effect on the device, generally does not require a new 510(k). The word doing the work is solely. Most real security patches change something else as a side effect, and the analysis turns on what else your fix touched.

The governing document is FDA's Deciding When to Submit a 510(k) for a Software Change to an Existing Device, issued October 2017, sitting on top of the threshold at 21 CFR 807.81(a)(3): a change that could significantly affect safety or effectiveness, or a major change in intended use.

The carve-out is real. If the only purpose of the change is to strengthen cybersecurity, and it has no other effect on performance, you are not filing a new 510(k).

Then you look at your actual patch, and the carve-out gets narrower than it sounded.

"Solely" is the entire test

If the change also alters how the device processes data, changes the interface beyond what was cleared, changes performance characteristics, or adds functionality, the carve-out does not apply and you are into the general analysis. Not automatically into a submission. Into the analysis.

The trap is that engineers read "solely for cybersecurity" as a statement about intent, and FDA means it as a statement about effect. You intended only to close a vulnerability. The question on the table is what else happened.

Why real patches fail it

Upgrading a vulnerable dependency changes behavior in everything downstream of it. Adding authentication to an endpoint changes a workflow. Enforcing a cipher policy breaks an older client. Removing a debug interface removes something a service technician was using. None of those were the point of the patch. All of them are effects beyond cybersecurity.

Here is the shape of it, using a finding that turns up constantly on mobile products.

A penetration test reports that your app still supports old operating system releases carrying their own unpatched vulnerabilities. Rated medium. The fix is obvious and cheap: raise the minimum OS version the app will run on.

Now follow the consequences, because they do not stop where the security work stops. On Android, older releases required an app to hold location permission in order to scan for Bluetooth LE devices at all, a platform quirk that has confused users and privacy reviewers for years. Raise your floor past that, and the permission is no longer needed, so you drop it. Good outcome. Fewer permissions, smaller privacy surface, a better story on the app store listing.

You have now done four things:

Changed which devices in the field can run the software at all
Removed a runtime permission, which changes what the app does and what it asks users for
Changed your dependency set, which means your SBOM is no longer accurate until you regenerate it
Possibly changed a pairing or discovery workflow that appears in your instructions for use

Three of those are not cybersecurity effects. They are ordinary product changes that arrived as passengers.

None of this necessarily requires a new 510(k). Raising a minimum OS version and dropping a permission you no longer need is a good candidate for a letter-to-file in most product contexts. But it is emphatically not the "solely, no other effect" case, and a company that files it as one has skipped the analysis rather than performed it.

That is the pattern worth internalizing. The security fix is usually the small part. The question is what rode along with it, and the person best placed to answer that is the engineer who made the change, not the regulatory lead reading a summary of it three weeks later.

The two questions underneath

Strip away the flowcharts and the assessment reduces to two:

Does the change introduce or modify a risk that could result in significant harm, and that the cleared device did not address?

Could the change significantly affect safety or effectiveness?

"Significant" is doing real work in both. A change that alters your risk assessment is not automatically a change that could cause significant harm. Plenty of security patches move a risk score without moving anything a patient would notice, and treating every such change as submission-triggering is its own failure mode. It trains the organization to route around the assessment.

Cumulative change is the trap nobody plans for

Changes are assessed in aggregate against the most recently cleared version, not individually against last month's release.

Four quarterly security patches, each correctly documented as not requiring a submission, can collectively cross the threshold. If your only comparison is to the previous release, you will never see it coming, because each individual comparison is honest and each individual conclusion is right.

This is a configuration management problem wearing a regulatory hat. Every assessment compares to the cleared baseline. Every time. If your change register does not make that baseline obvious to whoever is doing the assessment, someone will eventually compare to the wrong thing, and the error will not surface until an inspection or the next submission.

Documentation is not the consolation prize

"No new 510(k) required" does not mean "proceed." It means "you must document the analysis that concluded so."

The deliverable is a letter-to-file: the change, the risk analysis, the verification and validation summary, and a signed conclusion against the guidance criteria. If an inspector asks why you shipped a change without notifying FDA, that file is the entire answer. Its absence is the finding.

Under the QMSR this sits inside design controls and change management exactly as it did before, with the citations pointing at ISO 13485 rather than at Part 820.

Your source control already holds half of it

The letter-to-file needs two things: what changed, and why. Most companies treat both as writing tasks at release time. Only one of them is.

What changed is not a writing task. It is already recorded, exactly and completely, in version control. Every line, every dependency bump, every removed permission, with timestamps and authorship, in a system nobody can retroactively edit without leaving evidence. That is a better change record than anything a human is going to reconstruct into a document four months later, and it is sitting there already.

Why it changed is the half that goes missing. Commit messages get written for the next engineer, not for the next auditor. "Bump lib to 4.2.1" is perfectly adequate for a code reviewer and useless in a regulatory file, because it does not say that the bump closed a specific finding, or that the finding came from a penetration test, or that the version was chosen because it was the earliest one without the vulnerability.

This is where I have found the current generation of tooling genuinely earns its place. A model with access to the repository and the issue tracker can read a release's worth of commits and produce the change description, and where the context exists, the rationale behind it. That turns the most expensive part of the letter-to-file into a review task instead of an archaeology dig.

Two caveats, both important. The model can only surface a why that exists somewhere: in the ticket, the pull request discussion, the finding it traces back to. If the reason lives only in the head of the engineer who made the change, no tooling recovers it, and the fix for that is discipline at commit time rather than cleverness at release time. And the output is a draft that a human signs. The signature is the regulatory artifact, and it means someone read it and agrees. There is more on where that line falls in a regulated codebase.

What to actually do

Link the change to the finding. A patch that traces to a specific penetration test finding, with the disposition recorded, is most of your rationale already written. That is one of the reasons disposition records matter more than the report.

Write the effects, not the intent. List everything the change touched, then strike the ones that are genuinely cybersecurity-only. What is left is your analysis.

Compare to the cleared baseline, every time.

When you are unsure, ask. The Q-Submission program exists for exactly this question, and a documented agency answer beats a confident internal one.

This is engineering guidance, not legal or regulatory advice. Whether a specific change requires a new 510(k) is a determination for your regulatory lead, made against the guidance and your own device's cleared configuration.

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

Solely for cybersecurity - who decides?

You do, and you document the reasoning. It is an assessment made against FDA's flowcharts in the October 2017 software change guidance, not a self-evident category. The conclusion is only as good as the record of how you reached it.

Does upgrading a component in our SBOM count as a security-only change?

It depends entirely on what the upgrade changed. A patch-level bump to a library used in one code path is a different analysis from a major version bump that alters behavior. The SBOM entry changes either way, which is a postmarket obligation regardless of the 510(k) answer.

Do we notify FDA at all if no new submission is required?

Not through a premarket pathway. Your obligations run through your quality system: design controls, change control, CAPA where applicable, and the letter-to-file documenting the analysis. Nothing goes to the agency, but the file has to exist.

What if we are genuinely not sure?

The Q-Submission program exists for this. Asking is considerably cheaper than a retroactive finding during an inspection, and a documented question with an agency answer is the strongest possible record.

Does any of this change under the QMSR?

The decision logic is unchanged. What shifts is the terminology in your design control documentation, which now maps to ISO 13485 subclauses rather than to subsections of 21 CFR 820.

Can cybersecurity affect substantial equivalence itself?

Yes. FDA has taken the position that a device may be found not substantially equivalent to its predicate in light of new risks or vulnerabilities and inadequate performance data showing it is nonetheless cybersecure. Cybersecurity is not purely a content question inside a submission; it can bear on the pathway.

FDA Changed Its Cybersecurity Guidance Again. What Actually Moved?You Have a Penetration Test Report. Now What?Your SBOM Lists the Framework, Not the 1,000 Packages Underneath Using AI Coding Assistants in a Regulated Codebase

← More in Medical Device & SaMD