An FDA deficiency letter on cybersecurity is not a rejection. It is a hold, and it comes with a clock: 180 calendar days from the date on the letter to submit a complete response covering every deficiency. There are no extensions. Miss the window and the submission is considered withdrawn and deleted from the review system, which means a new submission, new fee, new queue.

The letter itself is downstream of what Section 524B requires, so if you have not read the statute against your own package recently, start there.

The MDUFA review clock stops while you are on hold and restarts when FDA receives a complete response. That is the one piece of good news in the letter. Everything else is work.

Read the whole thing before you fix anything

The instinct when the letter lands is to start closing items. Resist it. The first month of a response goes entirely to reading and understanding what the agency is actually asking, and that is not wasted time. Deficiencies cross-reference each other. A gap in the risk assessment methodology shows up again in the security controls section and again in the testing section, and if you fix it three separate ways you have created three inconsistent documents for a reviewer to notice.

The other reason to read first: some of what looks like a documentation complaint is an engineering complaint wearing a documentation costume. "Please provide more detail on the controls implemented" sometimes means the detail exists and was not written down. Sometimes it means the control does not exist. You cannot tell which until you have read the letter against the code.

Break it into discrete items

A letter of any substance becomes a list of dozens of discrete items. Not dozens of paragraphs of agency prose - dozens of things that have to be true before you can respond, each with an owner and a definition of done.

Without that decomposition you play whack-a-mole. You fix something, discover it touched a document you already considered final, go back, and lose a week. With it, you can work a bucket at a time and know what is finished. It is unglamorous project management, and it is the single highest-leverage hour of the whole response.

What FDA is actually asking for

The pattern underneath most cybersecurity deficiencies is the same. The agency is not asking for security principles. It is asking for specific, uniquely identified, testable requirements, traced to verification evidence.

That distinction is the whole game, and it is where submissions written by security-minded engineers still fall down. What separates a principle from a requirement is a short list of properties, and the conversion is worth running across your entire control set rather than only across the items the letter names.

The device-specific version of it is unforgiving. Bluetooth is not "secure pairing," it is a Core Specification version, a Security Mode and Level, and a named Secure Simple Pairing association model. 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 and the hash, and the process that applies them.

Cloud deployments get a version of this that catches people out. If your backend runs on a hyperscaler, you are expected to define the shared responsibility boundary explicitly and then describe your side of it in detail: API token and key management, the authorization logic that runs on every request, and how tenant data is segregated so one customer cannot reach another's records in a shared database. "We use a major cloud provider and they are SOC 2 certified" is not an answer to any of that.

Penetration testing gets its own scrutiny

FDA treats penetration testing as the primary validation that your controls actually work in the finished product, and the bar for the report is specific: tester independence and expertise, scope, duration, methods, and results. Scans are not a penetration test. A summary of findings is not a test report.

Two things reliably draw a deficiency here. The first is submitting automated output - port scans, cipher scans, a static analysis run - as though it were the test. Automation contributes, but the agency is explicit that testing must include manual work beyond what a tool can do. The second is the closure claim with nothing behind it: "all findings were fixed." That prompts an immediate request for the design changes you made for each one, and a fresh penetration test proving they hold. If you fix findings and do not retest, you will be asked to retest, and the retest will happen on FDA's calendar rather than yours.

Working a report into that shape is its own exercise, covered in what to do with a penetration test report. And if you are wondering who is supposed to perform the remediation, not the firm that tested you.

If any of the testing was internal, be ready to show the testers were independent of the design team, with a reporting line that means their findings could not cost them anything.

If your product is software-only, 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 gets reviewed against the same expectations.

What changes is the mix, and it does not get easier. The items that fall away are the ones about radios, 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 whole 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 enumerated 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.
  • SBOM and its vulnerability assessment, which is if anything larger for a software-only product, because there is more of it.

The pattern from the hardware side holds exactly: FDA is not asking for principles, it is asking for uniquely identified testable requirements traced to verification evidence. A web product's requirements are just as writable as a firmware product's. Most teams have simply never written them that way.

The SBOM is not the hard part. The SBOM's homework is

Generating a bill of materials is a tooling problem and it is solved. What follows is not.

An SBOM that exists is not an SBOM that has been assessed. You are expected to run the components against a vulnerability source - NIST's National Vulnerability Database and CISA's Known Exploited Vulnerabilities Catalog are the two named in the letters - and produce a safety and security risk assessment of what turns up, with risk controls for anything that matters and a described compensating control where you are not fixing it.

Do that honestly on a real codebase and you find that half your packages have newer versions and roughly one in ten carries a published vulnerability. Now you are triaging every one of them, deciding which are reachable in your product, upgrading the ones that are, and documenting the reasoning for the ones you leave. That is the work. The document generation took an afternoon.

The related trap is the risk assessment itself. If you do not state your methodology and your acceptance criteria up front - CVSS, AAMI TIR 57, ANSI/AAMI SW96, or a custom approach you can defend - the assessment reads as a table of opinions.

Do not half-fix things

The instruction I give clients when a letter lands is to stop patching around problems. Fix the core issue, even when that means a partial rewrite.

Half-measures are usually how the submission got here. They may satisfy the immediate deficiency, but they generate rework later and they tend to open new issues while closing old ones. You are also going to have to describe the change you made in a document that a reviewer reads. A description of a workaround reads exactly like a description of a workaround.

The claim that was almost true

The most valuable find in a response like this usually has nothing to do with the letter.

Somewhere in the submission is a security claim that was true when somebody wrote it and is not quite true now. A radio documented as disabled that comes up in some state nobody thought to test. A service asserted to be unreachable from the internet that is reachable from one subnet. A field described as encrypted at rest that is encrypted in one of two stores. The claim was accurate when it was written, the product moved, and the document did not.

When you find one you have two options, and only one of them is defensible. You can reword the sentence to describe what the product actually does. Or you can change the product so the original sentence becomes true.

Teams that pick the second are rarer than they should be, and it is the right call every time. An inaccurate security claim in a submission is worse than an absent one, because it misrepresents the product to the person deciding whether it is safe. Read your claims against the running system before a reviewer does.

Where the five months went

A response that uses most of the window tends to break down roughly like this:

  • Month 1 - reading, understanding, decomposing into discrete items.
  • Months 2 and 3 - remediation. The actual engineering.
  • Months 4 and 5 - documentation, testing, and evidence that the fixes hold.

Two of the five months went to proving the work rather than doing it, and that ratio surprises people every time. Plan for it. If you back-load documentation into the last three weeks you will either miss the window or send something thin to an agency that has already told you once that thin is not acceptable.

This is engineering guidance, not legal or regulatory advice. Regulatory strategy for a specific submission belongs with your regulatory lead.