FDA Cybersecurity Guidance
Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions
Legal Requirement: This regulation is legally binding and must be complied with for US market access. Non-compliance can result in regulatory action, including warning letters, import detentions, and product recalls.
Overview
Scope
This finalized FDA guidance document provides recommendations on cybersecurity information to include in premarket submissions for medical devices with cybersecurity considerations. It applies to devices that contain software (including firmware), programmable logic, and software as a medical device (SaMD). The guidance addresses the full device lifecycle, from design through post-market management, and establishes expectations for a Secure Product Development Framework (SPDF) that integrates cybersecurity into the Quality System.
Applicability
This guidance applies to all medical device manufacturers submitting premarket applications (510(k), De Novo, PMA, HDE) for devices that contain software or are programmable. With the enactment of Section 524B of the FD&C Act via the 2023 Omnibus bill, many of these recommendations have become statutory requirements for "cyber devices." Manufacturers of Class II and Class III devices with network connectivity, data exchange capabilities, or software update mechanisms should consider this guidance essential reading.
Why It Matters
This guidance represents a paradigm shift in how FDA evaluates cybersecurity. It moves beyond a checkbox approach to requiring evidence of a mature security development process. The FDA now expects threat models, architectural data-flow diagrams, a Software Bill of Materials (SBOM), and documented evidence that cybersecurity was integrated into every phase of product development. Failure to address cybersecurity adequately in premarket submissions can result in Refuse to Accept (RTA) decisions, significantly delaying market clearance.
Key Concepts
- Secure Product Development Framework (SPDF) as the foundation for cybersecurity activities
- Threat modeling with data-flow diagrams and trust boundary documentation
- Cybersecurity risk assessment using exploitability-based scoring (not probabilistic models)
- Software Bill of Materials (SBOM) in machine-readable format for all software components
- Vulnerability management and coordinated disclosure procedures
- Post-market cybersecurity management including patch/update plans
- Authentication, authorization, and encryption requirements for device interfaces
- Security testing requirements including fuzz testing, static analysis, and penetration testing
- Labeling requirements for cybersecurity information to end users
The FDA finalized this guidance after years of iteration. The message is clear: bolt-on security is dead. You must design security in from day one.
This is the single most important document for any manufacturer building a connected medical device. The 2023 finalized guidance—combined with Section 524B—means cybersecurity is no longer "nice to have." It's a gate for market access. If you submit a 510(k) without a threat model, SBOM, and post-market patch plan, expect an RTA letter. FDA reviewers are trained on this guidance now, and they will check.
🔑 Key Takeaways
- →Start your SPDF documentation early—retrofitting security documentation is painful and expensive.
- →Your threat model must include data-flow diagrams. Block diagrams alone are not sufficient.
- →Don't use probability-based risk scoring for cybersecurity. FDA will flag it.
- →SBOM is not optional for cyber devices. Automate generation in your build pipeline.
- →Plan for coordinated vulnerability disclosure BEFORE you ship the product.
— ER | medev.ai
Building better devices, together.
Premarket Submission Requirements
Secure Product Development Framework (SPDF)
Manufacturers must demonstrate that cybersecurity was integrated into product development through an SPDF. This goes beyond traditional QMS by requiring security-specific activities at every design phase: security requirements definition, secure architecture design, secure coding, security testing, and vulnerability management. The SPDF should align with recognized frameworks such as NIST CSF or IEC 81001-5-1.
Threat Modeling
The FDA expects comprehensive threat models that include: system architecture diagrams, data-flow diagrams showing trust boundaries, use-case and misuse-case scenarios, and attack surface identification. Threat models must map identified threats to security controls. STRIDE, PASTA, or equivalent methodologies are acceptable. Threat models must be updated throughout the product lifecycle.
Cybersecurity Risk Assessment
FDA explicitly states that traditional probabilistic risk assessment (as used in ISO 14971) is insufficient for cybersecurity because threats from malicious actors are intentional, not random. Manufacturers must use exploitability-based assessments considering known vulnerability severity (CVSS), exploit availability, and potential impact on safety. Residual risk must be evaluated for both uncontrolled and controlled scenarios.
Software Bill of Materials (SBOM)
All premarket submissions for cyber devices must include a complete SBOM listing commercial, open-source, and off-the-shelf software components. SBOMs should be in machine-readable format (SPDX or CycloneDX) and include component name, version, manufacturer, and known vulnerabilities. SBOMs must be maintained and updated post-market.
Security Architecture
Submissions must include documentation of the device security architecture, including: end-to-end encryption strategies, authentication and authorization mechanisms, secure boot and firmware integrity verification, network segmentation and interface security, and secure update/patch mechanisms.
Security Testing and Verification
Evidence of comprehensive security testing must be provided, including: static code analysis (SAST), dynamic analysis (DAST), software composition analysis (SCA), fuzz testing of all interfaces, penetration testing results, and vulnerability scanning. Test results must demonstrate that identified security requirements are met.
Post-Market Cybersecurity Management
Manufacturers must document plans for: monitoring new vulnerabilities affecting device components, timely patch and update deployment, coordinated vulnerability disclosure, incident response procedures, and communication with healthcare delivery organizations (HDOs) about cybersecurity events.
Labeling
Device labeling must include cybersecurity-relevant information for end users and healthcare organizations, including: recommended cybersecurity controls, network environment requirements, known residual risks, instructions for security updates, and contact information for reporting vulnerabilities.
Submission Preparation Roadmap
Determine Cyber Device Classification
Use the Cyber Device Classification tool on medev.ai to determine whether your device meets the definition of a "cyber device" under Section 524B. This determines whether SBOM and patching plans are statutory requirements or just recommended best practices.
Establish or Document Your SPDF
Implement a Secure Product Development Framework integrated with your existing QMS design control process. Map your SPDF activities to IEC 81001-5-1 clauses and document how cybersecurity requirements flow through your design inputs, outputs, verification, and validation.
Conduct Threat Modeling
Create system architecture diagrams, data-flow diagrams with trust boundaries, and identify the complete attack surface. Apply STRIDE or equivalent methodology to enumerate threats. Map each threat to security controls and document residual risk.
Perform Cybersecurity Risk Assessment
Assess risks using exploitability-based methods. For each identified threat, evaluate severity using CVSS scoring, assess exploit availability, and determine potential patient safety impact. Document risk controls and evaluate residual risk.
Generate and Validate SBOM
Create a complete Software Bill of Materials covering all software components. Use automated tooling (Syft, FOSSA, Snyk) for accuracy. Validate against NTIA minimum elements. Cross-reference components against NVD/CVE databases for known vulnerabilities.
Execute Security Testing
Perform static analysis, dynamic analysis, fuzz testing, and penetration testing. Document all findings, remediation actions, and retest results. Ensure test coverage addresses all identified threats and security requirements.
Document Post-Market Plan
Create documented procedures for vulnerability monitoring, patch management, coordinated disclosure, and incident response. Define timelines for critical, high, medium, and low severity vulnerability remediation.
Prepare Labeling
Draft cybersecurity-specific labeling including recommended security controls for end users, network environment requirements, update procedures, and vulnerability reporting instructions.
Compile Premarket Submission Package
Assemble all cybersecurity documentation into the submission package. For 510(k) submissions, map to the eSTAR cybersecurity section. Cross-reference all documentation to ensure traceability between threats, controls, testing, and labeling.
Common Challenges & Solutions
RTA (Refuse to Accept) for missing cybersecurity documentation
Use FDA's checklist from the guidance appendix to verify completeness before submission. The most common RTA triggers are: missing SBOM, absent threat model, and no post-market vulnerability management plan.
Adapting ISO 14971 risk management for cybersecurity
Don't try to force cybersecurity into your existing ISO 14971 risk matrix. Create a separate cybersecurity risk assessment that uses exploitability-based scoring. Reference ANSI/AAMI SW96 or AAMI TIR57 for the process framework.
Keeping SBOM current with rapid software changes
Integrate SBOM generation into your CI/CD pipeline so it auto-generates with every build. Use CycloneDX or SPDX tooling that hooks into your build system. Set up automated CVE monitoring against your SBOM.
Related Regulations
Section 524B (FD&C Act)
Ensuring Cybersecurity of Devices
Section 524B codifies many of this guidance's recommendations into law for cyber devices
21 CFR Part 820
Quality System Regulation
SPDF requirements integrate with QSR design controls
21 CFR Part 11
Electronic Records; Electronic Signatures
Cybersecurity controls support electronic records integrity requirements
Related Standards
IEC 81001-5-1
Security — Activities in the product life cycle
Maps directly to SPDF requirements; FDA-recognized standard
ANSI/AAMI SW96
Medical device security — Security risk management
FDA-recognized standard for cybersecurity risk management process
AAMI TIR57
Principles for medical device security — Risk management
Provides risk management framework referenced by the guidance
IEC 62304
Medical device software — Software life cycle processes
SPDF extends software lifecycle with security-specific activities
Resources
Official Resources
Implementation Tools
Legal Notice: This page provides implementation guidance and educational content only. The actual regulation text is the legally binding document. Always refer to the official regulation published in the Code of Federal Regulations (CFR) and FDA guidance documents for compliance purposes.