The same gaps recur across premarket and postmarket review. Here is the deficiency language reviewers actually send, paired with what the guidance says closes each one.
A point-in-time penetration test hands you a PDF of findings and high-level advice. FDA reviewers want the opposite: test cases mapped to threats, prescriptive fixes, proof each mitigation was tested, and evidence of prior results. Increasingly, they ask not just what you tested but how you will keep testing.
The deficiency excerpts below are representative of the language reviewers actually send, lightly edited and stripped of identifying detail. Under each one is what the guidance says resolves it. The pattern repeats: legacy, one-time testing produces findings and advice. Review wants evidence, and evidence that continues after clearance.
"Deferred" is not an accepted answer
The most common deficiency: a third-party penetration test report with findings marked deferred.
You provided the third-party penetration test report which identifies multiple security findings. You state that these findings are "deferred." However, these findings pose a security risk that should be mitigated to ensure patient safety from device tampering. Adequate authentication, authorization, and code, data, and execution integrity controls are required under Section 524B(b)(2) of the FD&C Act. Please revise these controls based on the concerns in the tables below.
Read plainly: FDA will not accept a risk assessment that leaves pentest findings unfixed. The guidance is direct about why. If a penetration tester could exploit a vulnerability, "the ability of a threat actor to exploit that vulnerability is likely to increase over the device lifecycle." For issues you do intend to defer to a future release, the submission has to contain the plan: which vulnerabilities the release will address, the anticipated timeline, whether interim devices get the update, and how long it takes to reach the field.
One trap in the follow-up. FDA tends to point at the pentest vendor's recommendation as the fix criteria, and those recommendations are high-level and not always complete. "Fixed per the report" can still be wrong. Write the remediation down to the code or configuration change, and retest it on the shipping build.
Interface-by-interface test cases, or a justification
The second most common deficiency: verification and validation that does not cover the electronic interfaces mechanism by mechanism.
The verification and validation testing for the electronic interfaces on the device has not been adequately addressed. For example, you did not provide complete V&V test results for interface-specific security mechanisms, including: (a) USB-C: malware protection, unauthorized device rejection, and data-integrity verification during transfer; (c) Wi-Fi/Bluetooth: verification that wireless capabilities cannot be reactivated through firmware exploitation or physical access. Please provide adequate V&V for the electronic interfaces, or an acceptable justification for the omission.
Per the verification and validation sections of FDA's interoperability guidance, every interface needs evidenced test results scaled to its risk. Derive the test cases from the interfaces in your architecture views, execute them, and record pass or fail with evidence for each mechanism. A summary is what draws this deficiency.
A postmarket vulnerability management plan, or a deficiency
FDA asks not just what you tested but how you will keep monitoring the product after it ships.
You provided cybersecurity documentation for the product, but you did not elaborate on how you intend to continuously monitor the product's cybersecurity in the postmarket phase, nor did you provide a vulnerability management plan. A vulnerability management plan is required under Section 524B of the FD&C Act. The manufacturer is expected to describe how vulnerabilities will be identified, assessed, and remediated across the device's supported lifetime, including monitoring of the SBOM against newly disclosed vulnerabilities and periodic security testing. Please provide a vulnerability management plan and describe your continuous monitoring and disclosure processes.
What the reviewer is after is evidence that the security program does not end at clearance: a named function, a cadence, and a paper trail. The guidance lists what the plan must contain: personnel responsible; sources, methods and frequency for monitoring and identifying vulnerabilities; how you identify and address entries in CISA's Known Exploited Vulnerabilities Catalog; periodic security testing; the timeline to develop and release patches; update processes; patching capability; the coordinated vulnerability disclosure process; and how you will communicate remediations to customers.
Evidence of testing across the whole product, not a subset
You provided a penetration testing report that contains a subset of findings. Please provide evidence of testing for all in-scope components and any historical testing performed during development, as well as how those vulnerabilities were managed.
A pentest that covers part of the device does not satisfy the SPDF. FDA wants complete, historical evidence of how the product was tested and managed during development. Keep every test case, result and disposition across releases so the record is retrieved, not reconstructed under a deadline.
Regular penetration testing, not a one-time report
You provided a postmarket vulnerability management plan that does not include regular penetration testing. Regular third-party penetration testing is recommended to keep pace with evolving threats and to identify new vulnerabilities, alongside validation of reported and SBOM-related issues.
The guidance says cybersecurity testing after release "should be performed at regular intervals commensurate with the risk (e.g., annually)." Put the cadence in the plan and keep the log that proves you kept it.
The controls FDA expects you to prove
Beyond the big five, a long list of documentation deficiencies recur. Each pairs a request with the fix.
Threat modeling. FDA asks: your device is a cyber device but you did not provide threat modeling. Provide a model assessing assets, threats, vulnerabilities and controls, with a justified methodology (STRIDE, attack trees, kill chain), all end-to-end elements, and architecture or sequence diagrams. Fix: the threat model in Section V.A.1, with the hostile-network assumption stated, supply chain and interoperability risks captured, and the rationale for the method you chose.
Authorization controls. FDA asks: you reference privilege levels but do not describe them or how permissions are granted. Fix: define each role's privileges and the authentication tied to each level, and test the privilege boundaries.
Confidentiality controls. FDA asks: you reference TLS, SSH and asymmetric encryption but do not detail them or where they are implemented, and some versions are insecure. Fix: describe each control, justify the algorithms and versions, and show the test that confirms the implementation.
Integrity controls. FDA asks: you reference checksums but non-cryptographic checksums are not integrity controls. Fix: cryptographic integrity protection, described and tested.
Device hardening. FDA asks: USB and external ports are enabled but you did not describe default hardening. Fix: remove default passwords, disable unused services, restrict interfaces, and document the hardening and its testing.
Event detection and incident response. FDA asks: your device relies on networking but you did not provide detection, response and recovery. Fix: an incident response plan for the device and evidence its detection and logging work.
Antivirus and malware protection. FDA asks: your operating system supports anti-malware. Detail the protections implemented, or justify why they are unnecessary.
Testing evidence and lifecycle traceability
Cybersecurity testing. FDA asks: your testing documentation is a summary rather than a full report. Fix: the elements the guidance lists for a penetration test report: independence and technical expertise of testers, scope, duration, methods, and results, findings and observations. Provide the original third-party report, not a summary of it.
Controls documentation. FDA asks: your risk-to-control traceability table lacked control details. Fix: for each of the eight control categories, the requirements, the acceptance criteria and the test that verified them.
End-of-life components. FDA asks: your SBOM lists components past their end-of-support date. Fix: the level of support and end-of-support date for every component, and a plan to upgrade or a justification for continued use.
Updatability and patchability. FDA asks: you marked updatability inapplicable with only a high-level justification. Fix: the updatability and patchability view, or a detailed justification.
SBOM format. FDA asks: your SBOM could not be opened or was not machine-readable. Fix: a machine-readable SBOM consistent with the NTIA minimum elements, in an industry format such as CycloneDX or SPDX.
Risk management report. FDA asks: your report lacked a separate security risk assessment and the outcomes of threat modeling, SBOM, vulnerability and anomaly reviews, with no cross-document traceability. Fix: the report described in TIR57 and SW96, with the traceability the guidance calls for.
Patch release timelines. FDA asks: you did not provide patch release timelines, including for critical updates. Fix: the reasonably justified regular cycle for known unacceptable vulnerabilities and the out-of-cycle path for critical ones, with the justification in the management plan.
Coordinated vulnerability disclosure. FDA asks: you did not provide adequate CVD information or how users are notified. Fix: the disclosure process for external and internal findings and the customer communication path.
Labeling. FDA asks: you did not provide cybersecurity labeling: interfaces, update instructions, anti-malware requirements, incident response guidance, SBOM information and infrastructure dependencies. Fix: the labeling elements listed in Section VI.A of the guidance.
The root
Every one of these traces back to the same cause. One-time testing produces findings and advice, not evidence, and it stops at clearance. Review wants test cases derived from the architecture, executed against the real device, remediated to the code, and repeated on every release and at least annually. Build the record that way and the deficiencies above do not open in the first place.