FDA Cybersecurity Remediation
A deficiency letter with a 180-day clock on it, or a submission going out with a cybersecurity package nobody is confident in.
Both problems have the same shape underneath. The agency is asking for something more specific than most teams have written down, and the gap is rarely a security gap - it is a documentation and verification gap sitting on top of a product that may well be secure.
The clock is the first constraint
A cybersecurity deficiency letter gives you 180 calendar days. There are no extensions. If the response does not land inside that window the submission is deleted and you refile from the beginning, which costs far more than the remediation would have.
The instinct is to start fixing at item one. That is the wrong move. Read the whole letter first, because items reference each other and the shape of the work only becomes visible once you have seen all of it. Then break it apart properly before anybody writes code.
The other version of this arrives earlier: a submission being prepared with a cybersecurity section that has been assembled from architecture documents nobody has re-checked against the product. That is cheaper to fix now than after a reviewer has read it.
What Section 524B asks for
Three obligations for a cyber device: a plan to monitor, identify, and address postmarket vulnerabilities including coordinated disclosure; processes providing a reasonable assurance that the product and related systems are cybersecure, with updates and patches made available; and a software bill of materials.
The full version, including which products count and where these submissions usually fall short, is in what Section 524B actually requires. It is worth reading before scoping any of this.
Requirements, not principles
The pattern underneath most cybersecurity deficiencies is the same, and it is the single thing worth understanding before you respond.
FDA is not asking for security principles. It is asking for specific, uniquely identified, testable requirements, traced to verification evidence.
“The product uses TLS 1.3” is a principle. A named cipher suite, enumerated per connection, carrying a requirement ID, with a test that exercises it and an entry in a traceability matrix - that is a requirement. The same conversion applies across the board. Authentication is not “strong passwords,” it is a complexity rule and a lockout policy. Update integrity is not “signed updates,” it is the signature scheme, the hash, and the process that applies them.
This is where submissions written by genuinely security-minded engineers still fall down. The product is fine. The claims are reasonable. They are simply written as intentions rather than as things a reviewer can verify, and there is no route from one to the other except doing the conversion.
An architecture document asserts a protection the product is supposed to provide. Nobody re-checks it against the implementation, and it goes into a submission. An inaccurate security claim is worse than an absent one, because it misrepresents the product to the person deciding whether it is safe. Auditing your own claims before a reviewer does is the cheapest work available here.
What the engagement involves
Read the letter against the product
Every item, read against the running code and the deployed infrastructure rather than against the architecture document. The gap between what a submission claims and what the product does is where these letters usually originate.
Decompose into discrete items
One deficiency paragraph is rarely one piece of work. It gets broken into items with an owner, a definition of done, and an artifact that will satisfy it. Anything left as a paragraph gets answered as a paragraph, which is how a second letter happens.
Write testable requirements
The bulk of the work, and the part teams underestimate. Converting security intent into uniquely identified requirements, each traced to a test that exercises it and an entry in a traceability matrix.
Remediation
The engineering that closes the gap between the requirement and the product. Sometimes the fix is small and the documentation is the work. Sometimes the claim cannot be made true and the honest answer is to change the claim.
SBOM and its vulnerability assessment
Generating the document is a build step. Getting it to come back clean is a software project - a real application pulls in transitive dependencies far beyond the ones you chose, and that is where the findings live. Support level and end-of-support dates belong in it too.
Penetration testing scope and evidence
Testing gets its own scrutiny in this review. Scoping it against the actual attack surface, managing the engagement, and driving the findings to documented closure so the evidence is traceable rather than asserted.
If you ship no hardware, this is still your letter
Section 524B has no hardware requirement, and neither does the guidance behind these letters. A connected SaMD product regulated through a 510(k), De Novo, or PMA is reviewed against the same expectations as a device with a radio in it.
What changes is the mix, and it does not get easier. The items that fall away are the ones about pairing models and firmware update integrity. What is left is the part software teams find hardest, and it arrives with more weight, because in a software-only product it is the entire attack surface:
The cloud shared responsibility boundary
Stated explicitly. Which service model you are on, which controls are yours, which are the provider’s, and the evidence for each. A provider’s compliance certificate covers the provider, not your configuration of it.
Authorization logic on every request
Described rather than asserted. Not “role-based access control” but how the check runs, where it runs, and what happens when it is absent.
Tenant data segregation
If more than one customer’s data lives in a shared database, how one organization is prevented from reaching another’s records.
Transport encryption, per connection
Cipher suite by cipher suite, for every hop - including the ones inside your own perimeter, between a load balancer and the application behind it.
A web product’s requirements are just as writable as a firmware product’s. Most teams have simply never been asked to write them that way.
Scoped against the letter
Fixed-price project work with a defined scope, milestones, and an end date. A deficiency letter scopes itself, which makes this one of the easier engagements to quote honestly rather than estimate vaguely.
If the immediate problem is a test report rather than a letter, that is penetration test remediation and it scopes differently.
If what you need afterwards is somebody holding the security function on an ongoing basis - postmarket monitoring, disclosure handling, the next submission - that is a fractional arrangement and a separate conversation.
I am not your regulatory consultant and I do not write your regulatory strategy. I do the cybersecurity engineering and the documentation that has to survive a reviewer reading it. That works alongside your regulatory lead, not instead of them.
Questions I get asked first
How long do we have to respond?
180 calendar days, and there are no extensions. Miss it and the submission is deleted, which means refiling from scratch rather than continuing the conversation. The clock is the reason to start with a full read rather than with the first item.
Our product is software only. Does Section 524B apply?
Yes. There is no hardware requirement anywhere in the definition. A connected product regulated through a 510(k), De Novo, PMA, PDP, or HDE carries the same obligations, and the deficiencies raised against it look much the same minus the ones about radios and firmware update.
Is this mostly writing, or mostly engineering?
Both, and the ratio surprises people. Most of the effort goes into producing testable requirements and verification evidence rather than into new code. But some claims cannot be documented into being true, and those need the engineering done first.
Can we just submit our SBOM and be done?
No. The SBOM is one of three obligations and it is the easiest to produce. The monitoring plan and the processes providing reasonable assurance of cybersecurity are where submissions more often fall short, and the SBOM itself comes with vulnerability assessment homework attached.
Written on this
Send me the letter
Tell me what you are holding and how much of the clock is left. I will tell you what the response involves and whether the date is realistic. If your regulatory lead already has this covered, I will say so.