FDA Premarket Cybersecurity Submission Checklist Guide

Use this to audit a package before it goes out. Each item includes what reviewers actually look for, because completeness is not the same as sufficiency. The 13 checklist items below cover all 18 deliverables; for the line-by-line list with the guidance section and eSTAR v7.1 field for each, see our FDA premarket cybersecurity deliverables and eSTAR v7.1 map.

Scope: does Section 524B apply to you?

Section 524B applies to a "cyber device," meaning a device that includes software, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. Note what is absent: device class. A Class II wearable and a Class III implant with a cloud companion are both in scope.

If you are in scope and the cybersecurity information is missing or plainly incomplete, the FDA can refuse to accept the submission at the RTA stage, before substantive review begins.

1. Cybersecurity management plan

• Plan covering the full device lifecycle, not just development
• Named roles and responsibilities for security decisions
• Process for monitoring, identifying, and addressing postmarket vulnerabilities
• Patch and update cadence, including the routine and out-of-cycle paths
• Coordinated vulnerability disclosure process referenced by URL
• Plan is a controlled document inside your QMS

Deficiency pattern: a plan that describes intentions in future tense. Reviewers want procedures that already exist under document control, with numbers.

2. Secure Product Development Framework evidence

• SPDF described and mapped to your existing design controls
• Security requirements captured as design inputs, not bolted on
• Security activities placed at defined design phases and gates
• Traceability from security requirement to verification evidence
• Alignment stated to IEC 81001-5-1 and ANSI/AAMI SW96

Deficiency pattern: the SPDF narrative and the QMS procedures describe two different processes.

3. Threat model

• Decomposition to DFD level 3 with all trust boundaries drawn
• Every element analyzed against all applicable threat categories
• Threats scored with patient-safety impact, not CVSS alone
• Controls and verification evidence linked per threat
• Residual risk with disposition and rationale
• Stable threat IDs referenced from the risk file and test reports

Full method in the STRIDE threat modeling guide.

Deficiency pattern: architecture diagrams submitted in place of an analysis.

4. Security architecture views

• Global system view
• Multi-patient harm view
• Updateability and patchability view
• Security use case views for the significant interfaces

Deficiency pattern: treating these as the same attachment as the threat model. They are separate, and the guidance names them specifically.

5. Security risk assessment

• Separate from, and traceable to, the ISO 14971 safety risk file
• Scoring method documented, including any CVSS harm adjustment
• Exploitability and patient harm scored on distinct axes
• Risk acceptability criteria stated in advance
• Benefit-risk rationale for every accepted residual risk

Deficiency pattern: security risk collapsed into the safety risk file with no security-specific scoring.

6. Software bill of materials

• Machine-readable, in CycloneDX or SPDX
• All NTIA minimum elements present, including PURL or CPE identifiers
• Transitive dependencies included, not just direct
• Support level and end-of-support date per component
• Known vulnerabilities listed with exploitability assessment and safety impact
• SBOM version matched to the submitted build

Format guidance: CycloneDX vs. SPDX.

Deficiency pattern: a PDF table, or an SBOM with no unique identifiers so CVEs cannot be matched.

7. Vulnerability analysis of SBOM components

• Every known CVE triaged, not just listed
• Exploitability in your configuration justified, ideally as VEX
• Safety impact per exploitable finding
• Mitigation or accepted-risk rationale for anything unpatched
• Statement of how the analysis will be repeated postmarket

Deficiency pattern: a raw scanner dump with hundreds of unexplained criticals.

8. Security testing

• Vulnerability scanning results, full reports
• Penetration testing report from a team independent of the design team
• Fuzz and malformed-input testing on every external interface
• Static and dynamic analysis results with findings dispositioned
• Scope, methodology, tools, versions, and dates stated
• Retest evidence for anything remediated

Deficiency pattern: a one-page test summary with no findings, no scope, and no tester identity. Reviewers read this as testing that did not happen. See 12 critical findings from medical device penetration tests.

9. Security controls and architecture documentation

• Authentication and authorization design, including service and maintenance access
• Cryptography inventory: algorithms, key lengths, key lifecycle, entropy source
• Secure boot and firmware signing described end to end
• Data protection at rest and in transit
• Audit logging with attribution and time synchronization
• Interface control documentation covering every physical and wireless port
• Debug and diagnostic interfaces disabled or protected in production

Deficiency pattern: "industry-standard encryption" with no algorithm, key length, or key management detail.

10. Update and patch capability

• Ability to deploy validated updates, including out of cycle
• Integrity and authenticity verification on the update path
• Rollback and failure handling
• Expected update timelines for critical vulnerabilities
• User or operator actions required, documented in labeling

Deficiency pattern: an update mechanism that exists in engineering but is not described as a controlled, validated process.

11. Postmarket plan

• Continuous monitoring of SBOM components against CVE feeds
• Triage SLA and escalation path
• CVD policy published at a stable URL and referenced in labeling
• Customer communication process for safety-relevant vulnerabilities
• Linkage to the QMS complaint, CAPA, and recall procedures

Detail in the postmarket monitoring program guide.

12. Cybersecurity labeling

• Security-relevant device features and configuration guidance
• Network and port requirements
• Hardening recommendations for the operating environment
• End-of-support date and its implications
• SBOM availability and how to obtain it
• CVD contact information

Deficiency pattern: labeling that omits the end-of-support date. This is now checked routinely.

13. PCCP, if you plan to change the device

If you intend to update algorithms or security controls without a new submission, include a predetermined change control plan with defined modifications, a validation protocol, and an impact assessment.

For cybersecurity specifically, a PCCP is worth the effort when your roadmap includes recurring changes of a predictable shape: rotating to a longer key length, adding a cipher suite, updating a TLS library on a defined cadence, changing an authentication timeout, or expanding logging. Each of those is a control change that would otherwise force a case-by-case letter-to-file or a new submission.

What reviewers expect in the cybersecurity portion of a PCCP:

• Bounded modification descriptions. "Update third-party libraries" is too broad and gets rejected. "Update the OpenSSL library to any subsequent 3.x release, with no change to the cipher suites listed in Table 6" is bounded and reviewable.
• A validation protocol tied to the threat model. Each permitted change names the threats it could affect and the regression tests that must pass before the change ships, including re-running the relevant penetration test cases when a network-facing control changes.
• An impact assessment against the security risk file. State explicitly that permitted changes cannot introduce a new hazardous situation, and describe the analysis that confirms it before each release.
• A stop condition. Define what falls outside the plan and therefore requires a new submission, such as adding a new external interface or changing the trust boundary.

Do not use a PCCP as a placeholder for controls you have not designed yet. A plan that reads like deferred work draws scrutiny on the underlying deliverables, not just the plan.

The traceability failure that is not on any checklist

The most common Major deficiency we see is not a missing document. It is thirteen documents that do not agree with each other: an interface in the architecture that never appears in the threat model, a control in the threat model that no test verifies, a component in the SBOM that the vulnerability analysis skipped, a residual risk in the security assessment that the ISO 14971 file never received.

Before you submit, run one traceability pass end to end: interface → DFD element → threat → control → test → residual risk → postmarket monitoring item. Every interface should complete the chain. That single pass catches more deficiencies than any individual document review.

Where each cybersecurity deliverable lands in eSTAR

Reviewers open attachments, not chapters. Mapping the checklist to the attachment structure before you assemble prevents the most avoidable finding of all, which is a deliverable that exists but was filed where nobody looked for it.

A 90-minute self-review before you submit

Run this as a working session with the systems engineer, the security lead, and whoever owns the regulatory file. It finds the traceability breaks that individual document reviews never surface.

1. Pick three interfaces at random from the interface control document. For each, walk it forward: does it appear in a DFD element, does that element carry threats, do those threats have controls, does a test verify each control, is any residual risk in the security risk assessment, and is there a corresponding postmarket monitoring item? Any interface that does not complete the chain is a finding.
2. Pick five threats at random from the threat model and walk them backward to the DFD element and forward to the test report. Confirm the threat ID is literally quoted in both places, not merely conceptually related.
3. Pick five SBOM components at random, ideally transitive ones, and confirm each appears in the vulnerability analysis with a disposition.
4. Open every test report and check for scope, dates, tool versions, tester identity and independence, and retest evidence. A report missing any of these will draw a question.
5. Read the labeling against the checklist above, specifically for the end-of-support date and the CVD contact.
6. Diff the SBOM build metadata against the firmware version named in the submission.

If steps 1 through 3 produce more than one break each, the package is not ready, regardless of how complete the document list looks.

When to start each cybersecurity deliverable

Most schedule pain comes from treating cybersecurity as a documentation task at the end of design. The dependencies force a different order.

Penetration testing is the item most often left too late. It needs a frozen, representative build, an independent team, and enough runway to remediate and retest. Six to eight weeks before submission is tight; twelve is comfortable.

How FDA cybersecurity deficiencies are actually phrased

Recognizing the language helps you pre-empt it. Recurring constructions from cybersecurity deficiency letters include: the submitted threat model does not support the risk determinations in the security risk assessment; the SBOM does not include unique identifiers sufficient to determine whether known vulnerabilities affect the device; provide the complete penetration test report including scope, methodology, and findings rather than a summary; clarify how the update mechanism verifies the authenticity and integrity of the software update; and provide the end-of-support date and describe how users will be notified.

Every one of those is answerable in advance by an artifact you already owe. See FDA cybersecurity deficiency letter examples for the full pattern set and how responses are best structured.

How Blue Goat Cyber runs premarket packages

We scope against the device profile first, produce each deliverable under your design controls with the standard cited in the artifact, run testing with a team separate from the people who wrote the design, and finish with the traceability pass above. Details on FDA premarket cybersecurity services. If a deficiency letter has already arrived, deficiency response is the faster path.

Where this fits in the cluster

• FDA Section 524B Requirements Explained
• STRIDE Threat Modeling for Medical Devices
• FDA Cybersecurity RTA Prevention Checklist
• FDA Cybersecurity Deficiency Letter Examples
• eSTAR Cybersecurity Mapping

Related from Blue Goat Cyber

• FDA Premarket Cybersecurity Services
• Threat Modeling Services
• Medical Device Penetration Testing
• FDA Cybersecurity Deficiency Response

FAQ

What are the minimum cybersecurity requirements for an FDA 510(k)?

For a cyber device: a cybersecurity management plan, SPDF evidence, a threat model, security architecture views, a security risk assessment, a machine-readable SBOM with vulnerability analysis, security testing reports, control documentation, a validated update capability, a postmarket plan with CVD, and cybersecurity labeling. Section 524B makes these statutory rather than discretionary.

Does the FDA require penetration testing for all medical devices?

For cyber devices, yes in practice. The guidance expects security testing appropriate to the device, and for anything with a network, wireless, or physical data interface that means penetration testing alongside vulnerability scanning, fuzzing, and static analysis. Reviewers expect the full report, and they expect the testers to be independent of the design team.

What SBOM format does the FDA prefer?

No preference. The requirement is machine-readable with the NTIA minimum elements. CycloneDX and SPDX are both accepted. CycloneDX tends to fit device vulnerability management and VEX better; SPDX is stronger on licensing.

How do I document threat modeling in a premarket submission?

Submit the analysis, not just diagrams: DFD3 decomposition, threats enumerated per element, patient-harm-aware risk scores, the control and verification test for each threat, and residual risk with disposition, all carrying stable IDs referenced from your risk file and test reports.

What is the Refuse to Accept policy for cybersecurity?

RTA is an administrative completeness check performed before substantive review. Under Section 524B, missing or facially incomplete cybersecurity information can stop a submission there. An RTA hold typically costs weeks to months, which is why the checklist above is worth running before you file.

How current does security testing need to be at submission?

Testing must reflect the software version you are submitting. If code changed after testing, either retest or provide a documented impact analysis explaining why the change does not affect the results. Reports older than roughly 12 months tend to attract questions even when the build has not changed.

Sources & primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• Section 524B of the FD&C Act
• The Minimum Elements For a Software Bill of Materials (NTIA)
• IEC 81001-5-1 Health software security in the product life cycle
• ISO 14971:2019 Application of risk management to medical devices