The SPDF Playbook for FDA-Ready Medical Devices

SPDF Governance & QMS Integration

A written Secure Product Development Framework policy that lives inside your ISO 13485 QMS and references IEC 62304 software lifecycle activities. It defines roles, escalation paths, and the security gates that block a release.

FDA’s February 2026 premarket cybersecurity guidance and Section 524B treat the SPDF as a process artifact, not a single document. Reviewers look for evidence that security decisions are made by accountable owners and traced through your QMS like every other design control.

• SPDF policy document mapped to QMS procedures
• RACI matrix covering security architect, QA, regulatory, and engineering
• Definition of Done for each design phase including security exit criteria

Security Requirements & Design Inputs

Cybersecurity requirements derived from intended use, risk, and applicable standards (FDA 524B, AAMI SW96, IEC 81001-5-1, IEC 62443-4-2). Each requirement is testable and traced to a design output.

Without explicit security requirements, there is nothing to verify against. Reviewers commonly flag submissions where security controls appear in implementation but never in requirements, breaking traceability.

• Security requirements specification with unique IDs and rationale
• Traceability from each requirement to threats, controls, tests, and design outputs
• Mapping to applicable standards and regulatory clauses

Threat Modeling & Architecture Views

Data flow diagrams with trust boundaries, a STRIDE or PASTA threat enumeration, and the four architecture views FDA expects: global system, multi-patient harm, updateability, and security use case views.

FDA’s February 2026 guidance is specific about the views required. Submissions with a single block diagram and a generic STRIDE table are routinely held with deficiencies tied to threat model depth and architecture clarity.

• Data flow diagrams covering every interface, trust boundary, and external entity
• Threat register linking each threat to a control, test, or accepted residual risk
• All four architecture views, kept consistent with the threat model

Security Risk Management Integrated with ISO 14971

A Security Risk Assessment that translates exploitability into probability of harm and lives inside the same risk file as your ISO 14971 hazard analysis, not in a parallel spreadsheet.

Section 524B and the premarket guidance are explicit: cybersecurity risk must be evaluated through patient safety. A standalone security risk register without 14971 linkage is one of the most common deficiency triggers.

• Security Risk Assessment with exploitability-to-harm mapping
• Bidirectional traceability between security risks and 14971 hazards
• Residual risk evaluation reflected consistently in both files

Secure Implementation, SBOM & SOUP

Secure coding standards, code review with security checklists, dependency hygiene, and a CycloneDX or SPDX Software Bill of Materials regenerated on every build with a documented lifecycle plan.

FDA expects a machine-readable SBOM that supports continuous vulnerability monitoring, plus evidence that third-party and SOUP components are evaluated, not just inventoried.

• Secure coding standard tied to language and toolchain in use
• CycloneDX or SPDX SBOM with transitive dependencies, suppliers, versions, and licenses
• SOUP analysis with vulnerability assessment and rationale for use

Verification: Static Analysis, Fuzzing & Penetration Testing

A layered test program: SAST and SCA in CI, protocol fuzzing on critical interfaces, and end-to-end penetration testing across every interface (wired, wireless, BLE, cellular, USB, cloud, service ports).

Reviewers expect testing scoped to the threat model and performed with medical-device context. Pure automated scans, web-only pen tests, and reports from generalist firms without medical experience are routinely flagged.

• SAST/SCA configuration and results integrated into the design history file
• Penetration test report scoped across all interfaces, written for FDA audience
• Fuzz testing results on protocols handling untrusted input

Cybersecurity Labeling & Coordinated Vulnerability Disclosure

User-facing cybersecurity transparency: a labeling section covering supported configurations, network requirements, end-of-support dates, SBOM access, and a published Coordinated Vulnerability Disclosure (CVD) program with intake and SLAs.

Cybersecurity labeling and CVD are explicit submission elements. Reviewers verify that customers, IT departments, and security researchers have what they need to operate the device and report issues.

• Cybersecurity section in IFU/labeling with hardening guidance and EOS dates
• Published CVD policy referencing ISO/IEC 29147 and 30111
• Internal triage workflow with risk-based response SLAs

Post-Market Monitoring, Patching & TPLC

A Total Product Lifecycle (TPLC) plan that operationalizes the SBOM: continuous monitoring of vulnerabilities via NVD and CISA KEV, risk-based patch timelines, validated update mechanisms, and customer communication.

FDA evaluates premarket and post-market cybersecurity together. A strong premarket package with no credible monitoring or patch plan does not stand on its own.

• Vulnerability monitoring sources and triage workflow tied to the SBOM
• Validated update mechanism: signature, integrity, atomic install, rollback
• Customer communication and patch deployment plan with SLAs