On this page
Published: · Updated:
Key Takeaways
- The eighteen deliverables describe Blue Goat Cyber's package, not eighteen universally required FDA files.
- Twelve deliverables have direct IEC 62304 clause homes, two support clauses partially, and four address subjects outside its scope.
- IEC 62304 includes security-related requirements, but does not set out a complete threat-modeling, exploitability-assessment, or vulnerability-monitoring process.
- FDA device class, software Documentation Level, IEC 62304 safety class, and cybersecurity risk are distinct assessments.
- The manufacturer owns lifecycle records, QMS approval, software V&V, risk acceptance, and release; cybersecurity evidence supports those decisions.
- Clause mapping does not establish IEC 62304 conformity or predict an FDA review outcome.
SPDF and IEC 62304 mapping connects cybersecurity evidence to manufacturer-controlled software lifecycle records. Blue Goat Cyber's eighteen-deliverable package has twelve direct clause homes, two partial mappings, and four subjects outside IEC 62304's scope. This is a cross-reference, not a conformity assessment or a universal FDA document checklist. The manufacturer retains software classification, development planning, configuration management, general software verification and validation, risk acceptance, and release decisions.
A cybersecurity test report is useful lifecycle evidence, but it does not establish that a manufacturer's software process conforms to IEC 62304. The practical question is where each security finding, control, and test result connects to the software records your team already controls.
The FDA's February 3, 2026 guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, recommends integrating cybersecurity throughout the product lifecycle. It does not require manufacturers to adopt IEC 62304 or one specific software lifecycle model.
For teams using IEC 62304, this crosswalk connects Blue Goat Cyber's cybersecurity deliverables to supporting clause records. Teams using another lifecycle can use the same evidence within their own controlled processes. The mapping is based on our guide SW-001, Rev B, dated October 22, 2026, and IEC 62304:2006+A1:2015.
Why This Matters
Integrated evidence helps a software quality team follow a security issue from the affected component to the requirement, control, test, and approved change. It also prevents a cybersecurity package from being mistaken for a replacement software lifecycle file.
The FDA's February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, recommends a secure development approach and risk-scaled submission evidence. Section 524B separately imposes statutory duties for devices meeting its cyber-device definition, including an SBOM and a plan to monitor, identify, and address postmarket vulnerabilities and exploits. Those duties do not create a statutory eighteen-document list or mandate IEC 62304 adoption.
Our Rev B cross-reference maps fourteen of eighteen package deliverables to IEC 62304: twelve directly and two partially. That count describes the map, not measured submission outcomes. Labeling, procurement disclosure, and program metrics account for the four remaining items.
IEC 62304 supplies software lifecycle processes. IEC 81001-5-1 supplies security-specific lifecycle activities; ANSI/AAMI SW96 and ISO 14971 connect security analysis with device risk management. Together, these references help teams place evidence without confusing cybersecurity work with general software V&V. The manufacturer's quality team still determines applicable requirements and approves its controlled records.
How does IEC 62304 relate to SPDF?
IEC 62304 provides software lifecycle processes; an SPDF supplies security-focused activities that can be integrated into those processes. Neither is a substitute for the other, and the FDA describes SPDF as an approach rather than the only permissible framework.
IEC 62304 is not silent on security. Clause 5.2.2 includes security-related software requirements, and clause 9.1 includes security effects when describing problem criticality. It nevertheless does not specify the complete cybersecurity processes addressed by threat modeling, exploitability assessment, or ongoing vulnerability monitoring.
Use stable requirement, component, threat, finding, and test identifiers to connect cybersecurity evidence to your lifecycle records. The records do not have to reside in one physical file or use a prescribed template.
The manufacturer determines applicability and approves its software lifecycle and risk-management records. A clause cross-reference shows supporting evidence; it is not an IEC 62304 conformity determination, an FDA-mandated filing format, or a replacement for software V&V.
Where do the eighteen deliverables fit?
The table maps Blue Goat Cyber's eighteen premarket cybersecurity deliverables to the IEC 62304 records they support. Strong means a direct clause home, Partial means a clause covers part of the deliverable, and None means the subject has no direct clause home in this map. These are mapping labels, not readiness scores.
FDA section references below refer to the February 3, 2026 guidance. Software safety-class notes follow the cited clauses in IEC 62304:2006+A1:2015, not FDA device class. The manufacturer should confirm applicability against its controlled copy of the standard.
| # | Blue Goat Cyber deliverable | FDA guidance section | Supporting IEC 62304 clauses | Software safety class | Fit |
|---|---|---|---|---|---|
| 1 | Risk Management Report | V.A | 7.1-7.3 software risk management; 7.3.3 traceability; 7.4.1 change analysis | B, C; 7.4.1 all | Strong |
| 2 | Threat Model | V.A.1 | 7.1 software contributions to hazardous situations; security causes linked through SW96 and IEC 81001-5-1 | B, C | Strong |
| 3 | Cybersecurity Risk Assessment | V.A.2 | 7.1 analysis; 7.2 risk controls; input to 4.3 classification | B, C; 4.3 all | Strong |
| 4 | Software Bill of Materials (SBOM) | V.A.4; VII.C.3 | 8.1.2 SOUP identification; 5.3.3-5.3.4 SOUP requirements | All; 5.3.3-5.3.4 B, C | Strong |
| 5 | Component Support and End-of-Support | V.A.4(b) | 6.1 maintenance planning, including SOUP updates and obsolescence; 7.1.3 published SOUP anomalies | All; 7.1.3 B, C | Strong |
| 6 | Assessment of Unresolved Anomalies | V.A.5 | 5.8.2 residual anomaly records; 5.8.3 residual anomaly evaluation | All; 5.8.3 B, C | Strong |
| 7 | Measures and Metrics | V.A.6 | No direct home; linked to ISO 13485 data analysis | Not applicable | None |
| 8 | Security Requirements and Control Coverage | V.B.1; Appendix 1 | 5.2.2 requirements content; 5.2.3 software risk-control requirements | All; 5.2.3 B, C | Strong |
| 9 | Security Architecture Views | V.B.2; Appendix 2 | 5.3.1-5.3.2 architecture and interfaces; 5.3.5 risk-control segregation | B, C; 5.3.5 C | Strong |
| 10 | Static Application Security Testing (SAST) | V.C | 5.1.12 common software defects; 5.5.2-5.5.5 unit verification support | B, C; 5.5.4 C | Partial |
| 11 | Penetration Test Plan | V.C | 5.1.6 verification planning; 5.7.1 software requirements tests | All | Strong |
| 12 | Penetration Test Cases | V.C | 5.7.1 requirements tests; 7.3.1 risk-control verification | All; 7.3.1 B, C | Strong |
| 13 | Penetration Test Report | V.C | 5.7 system testing support; 9.1 problem reports and security criticality | All | Strong |
| 14 | Cybersecurity Labeling | VI.A | No direct home; connect to device labeling and information for safety | Not applicable | None |
| 15 | MDS2 | VI.A | No direct home; procurement disclosure to healthcare providers | Not applicable | None |
| 16 | Cybersecurity Management Plan | VI.B; VII.C.1 | 6.1 maintenance planning; 6.2.1.1 feedback monitoring; 6.2 problem/change analysis; 7.4 changes; 9 problem resolution | All; 7.4.2-7.4.3 B, C | Strong |
| 17 | Interoperability Risk Assessment | V.A.3 | 7.1 risk analysis; 5.2.2 requirements; 5.3.2 external interfaces | B, C; 5.2.2 all | Partial |
| 18 | Interoperability Labeling | VI.A | No direct home; connect to device labeling | Not applicable | None |
For qualifying cyber devices, Section 524B requires an SBOM and the postmarket vulnerability-management plan. It does not prescribe our document titles or require every other row as a separate file. MDS2 is one common procurement-disclosure format, not an FDA-mandated form. See the premarket deliverables and eSTAR map for the submission-side organization.
What does the map not cover?
A direct clause home does not mean a cybersecurity deliverable fulfills the whole clause. An SBOM supports SOUP identification, but does not complete configuration management; security testing supports selected verification evidence, but does not complete general software verification or validation.
Threat modeling and exploitability assessment add analysis of intentional attacks and their consequences. Component support records and the cybersecurity management plan add vulnerability monitoring across the supported life of the device. Optional VEX statements can communicate whether a particular product version is affected by a vulnerability; they do not replace supporting analysis.
Security architecture evidence should address relevant system boundaries, controls, and the view types recommended in the FDA guidance. The guidance does not turn this crosswalk into a fixed number of diagrams. Labeling, MDS2, interoperability labeling, and metrics still need appropriate homes outside the software-clause map.
Which responsibilities stay with the manufacturer?
The manufacturer owns the software process and decisions supported by the cybersecurity evidence. Blue Goat Cyber provides product cybersecurity work within the agreed engagement, not full QMS implementation, certification, or general software V&V.
| Manufacturer-owned activity | Cybersecurity contribution | Boundary |
|---|---|---|
| Software safety classification, 4.3 | Security-driven hazardous situations as classification inputs | The manufacturer assigns and documents the class |
| Software development planning, 5.1 | Penetration test planning and agreed security evidence | The manufacturer owns the software development plan and general V&V |
| Configuration management, 8 | SBOM and affected-component/version evidence | The manufacturer owns identification, change control, and status accounting |
| Legacy software determination, 4.4 | Cybersecurity analysis of legacy components | The manufacturer makes the legacy-software determination |
| QMS approval, risk acceptance, and release | Findings, control evidence, retest results, and residual-risk inputs | The manufacturer approves records, accepts risk, and decides release |
Findings, risk ratings, and test conclusions change when evidence changes, for example following remediation and retesting. They do not change simply to fit a template or a preferred outcome. Preserve identifiers when placing editable cybersecurity content into controlled records, and retain original test reports with their evidence links.
How do SBOM and SAST reviews enter the lifecycle?
SBOM and SAST evidence supports component identification and security-related verification, but the manufacturer still owns the complete software process. Our guide SW-002, Rev B, adds practical review steps to the SW-001 clause map above; neither guide establishes conformity or an FDA-mandated filing format.
| Evidence handoff | Cybersecurity review | Manufacturer lifecycle action |
|---|---|---|
| Component inventory | Reconcile available source/build and binary evidence; record tools, versions, direct/transitive dependencies, and coverage limits | Connect the SBOM to the controlled SOUP/component records and the approved software version |
| Support enrichment | Review support level and end-of-support fields through the enrichment gate and second-person peer review | Obtain supplier evidence, track explicitly unknown dates, and make maintenance decisions |
| Static analysis | Configure scans for the in-scope source, review raw results, and map confirmed weaknesses to CWE | Link findings to software problem reports, requirements, and corrective changes |
| Deferred security finding | Supply device-specific risk and unresolved-anomaly evidence, including controls and rationale | Review the unresolved anomaly and make the release and risk-acceptance decisions |
| Remediation and retest | Verify the security change and retain the original finding and closure evidence | Approve the change, update configuration records, and review impacts on other lifecycle evidence |
SAST's mapping remains Partial: security-focused static analysis does not satisfy all unit verification activities in clause 5.5. Source code unavailable for review and unexamined software systems remain explicit limitations. A scanner's clean output is not evidence that the whole device is free from vulnerabilities.
See also: IEC 62304 Classes vs FDA Device Classes, FDA Cybersecurity Documentation: Legal Duties and Guidance Recommendations, and CI/CD Security Gates for Medical Devices.
Assess security impact even when a finding has no demonstrated patient-harm pathway. Patient-safety severity comes from the manufacturer's ISO 14971 evidence; it is not assigned from a CWE or CVSS score. A CISA KEV listing triggers applicability and control review, not an automatic increase in matrix exploitability.
Manufacturer teams may place editable cybersecurity content in their controlled templates while retaining the identifiers and evidence connections. Original third-party test reports should remain originals, consistent with Section V.C of the February 3, 2026 guidance; cite them from your template rather than rewriting their test conclusions. Retrospective work carries the dates it actually occurred, not backdated lifecycle claims.
For discovery, verification, finding triage, and agreed source-code confidentiality, see the SBOM and SAST methodology within our medical-device SBOM guide. The manufacturer approves its records and release; Blue Goat Cyber supplies cybersecurity evidence and recommendations.
Connect cybersecurity evidence to your existing quality records.
Review our cybersecurity QMS integration scope, including manufacturer-owned approvals and separately agreed procedure support.
How does one threat trace through the records?
A fictional connected infusion pump illustrates how one threat connects the deliverables without replacing manufacturer decisions. Assume the manufacturer has classified its dose-control software as IEC 62304 Class C; this is not a client case or a classification recommendation.
| Evidence step | Illustrative record | Supporting clause |
|---|---|---|
| Threat model | An attacker attempts to spoof a dose command over a wireless link | 7.1 |
| Cybersecurity risk assessment | Manufacturer-provided hazard evidence connects an incorrect dose to possible serious injury; authentication is selected as a control | 7.1; 7.2; input to 4.3 |
| Security requirements | Mutual authentication of dose commands, with requirement and control identifiers | 5.2.2; 5.2.3 |
| Architecture views | The enforcement point, trust boundary, and responsible software items | 5.3.1-5.3.2 |
| Penetration tests | Attempt a spoofed command, record the result, and route findings into problem resolution | 5.7.1; 7.3.1; 9.1 |
| Postmarket records | Use the SBOM to identify a newly disclosed wireless-stack vulnerability and route a change through maintenance | 8.1.2; 7.1.3; 6.2; 7.4 |
The manufacturer reviews the evidence, approves changes, evaluates residual risk, and decides release. Patient harm is supported by device-specific evidence, not inferred from a vulnerability score alone.
How do software safety class and cybersecurity risk differ?
These assessments answer different questions and do not map one-to-one. A Class II device can contain Class A, B, or C software.
- FDA device class (I, II, III) determines device-level regulatory controls and affects the premarket pathway.
- FDA software Documentation Level (Basic or Enhanced) determines software submission documentation under the June 2023 device software-functions guidance.
- IEC 62304 software safety class (A, B, C) determines applicable lifecycle rigor; the manufacturer assigns it under clause 4.3.
- Cybersecurity risk determines the risk-scaled security evidence. Section IV.D of the February 3, 2026 guidance separates this from software Documentation Level and other software risk levels.
For Class A software, clauses 7.1-7.3 do not apply, but cybersecurity risk work still belongs in the manufacturer's risk-management process. Clauses such as 5.2.2, 5.7, 6, 8, and 9 remain relevant. Class A does not exempt a qualifying cyber device from Section 524B.
Our risk-scoring methodology keeps security and patient-safety assessments separate, uses exploitability rather than guessed attack probability, and leaves risk acceptance with the manufacturer.
How Blue Goat Cyber Approaches This
We start with the manufacturer's existing software and quality records, the device architecture, and the agreed cybersecurity scope. We identify the owners and record identifiers needed to connect threat models, security requirements, component evidence, tests, findings, and change records. This supports one controlled lifecycle without requiring one physical document.
Our medical-device cybersecurity team brings security-testing and risk-analysis experience to the work. Software quality and regulatory staff retain ownership of their lifecycle documents and decisions. Where separately agreed, our cybersecurity QMS integration work supports procedure revisions, responsibilities, and evidence connections within the manufacturer's existing QMS.
Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. Those are company track-record statements, not a guarantee of clearance or IEC 62304 conformity. Our FDA premarket cybersecurity services define the engagement scope. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.
Frequently Asked Questions
Does SPDF replace IEC 62304?
No. SPDF describes security-focused development activities; IEC 62304 defines software lifecycle processes. A manufacturer using IEC 62304 can integrate cybersecurity evidence into its existing records. The FDA does not require adoption of IEC 62304 or a specific lifecycle model, and SPDF is an approach described in the cybersecurity guidance rather than the only acceptable framework. The manufacturer remains responsible for its applicable software and quality requirements.
Does the FDA require all eighteen deliverables as separate documents?
No. Eighteen is Blue Goat Cyber's package organization, not a universal FDA minimum or prescribed set of filenames. Section 524B requires specified duties for qualifying cyber devices, including an SBOM and a postmarket vulnerability-management plan. Other content is addressed through risk-scaled guidance recommendations and applicable submission requirements. Connected records can support multiple purposes; MDS2 is one common disclosure format, not a required FDA form.
Does a Strong mapping establish IEC 62304 conformity?
No. Strong means that the cybersecurity deliverable has a direct supporting clause home in this cross-reference. It does not establish that the complete clause, process, or device conforms to the standard. The manufacturer evaluates the full requirements and approves its lifecycle records. Penetration testing may support security-related verification evidence, but Blue Goat Cyber does not provide general software verification and validation or certify the manufacturer's QMS.
Can Class A software still need cybersecurity evidence?
Yes. Class A changes the applicability of certain IEC 62304 clauses, not the device's cybersecurity obligations. Clauses 7.1-7.3 apply to Classes B and C, while other lifecycle clauses still apply to Class A. Cybersecurity analysis remains in the manufacturer's risk-management process and informs classification where appropriate. FDA cybersecurity documentation scales with cybersecurity risk; qualifying cyber devices remain subject to Section 524B regardless of software safety class.
What if our team does not use IEC 62304?
The cybersecurity deliverables can support another controlled lifecycle. Set aside the IEC clause column and connect evidence to your software requirements, risk-management file, design-change records, and postmarket processes. The manufacturer determines applicable standards and submission requirements. See the software documents and cybersecurity guide for the boundary between general software documentation and cybersecurity evidence, and retain stable identifiers across those records.
What changes if cybersecurity work starts after software development?
Evidence should describe the design as built and carry the actual dates of the work. New security requirements and findings enter the manufacturer's controlled requirements and design-change processes. Do not backdate records or imply that retrospective evidence proves activities occurred earlier. Scope and timing depend on the device, available records, test access, and remediation needed; the clause map does not supply a universal retrofit deadline.
Connect your cybersecurity evidence before submission
Bring your existing software lifecycle records and cybersecurity evidence to a scope discussion. We can identify the connections and gaps within our product cybersecurity work while your team retains lifecycle ownership. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.
Discuss your premarket cybersecurity scope
Related SPDF reading
- Medical Device Cybersecurity SPDF Playbook
- Premarket cybersecurity deliverables and QMS integration
- IEC 62304 Classes vs FDA Device Classes
- How SPDF Maps to IEC 81001-5-1 Activities
- CI/CD Security Gates for Medical Devices
- SPDF Cybersecurity Documentation
- SPDF vs SSDLC: What Medtech Teams Get
- Medical Device Cybersecurity SPDF vs TPLC
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.