Secure Product Development Framework (SPDF) Implementation Guide
Integrating cybersecurity into your medical device design controls — from security requirements through validation and post-market monitoring
Overview
Purpose
This guide provides a phased implementation roadmap for establishing a Secure Product Development Framework (SPDF) as required by the FDA Cybersecurity Guidance. The SPDF is not a standalone process — it is a set of security-specific activities that integrate into your existing design control process (21 CFR 820 / ISO 13485). The goal is to ensure that cybersecurity is designed into the product from day one, not bolted on after development. This guide maps each SPDF activity to an equivalent IEC 81001-5-1 clause and design control phase, providing concrete deliverables and templates for each step.
Target Audience
Software engineers, systems engineers, QMS managers, cybersecurity engineers, and regulatory affairs professionals who need to implement a compliant SPDF process.
Prerequisites
- Existing design control process (21 CFR 820 or ISO 13485)
- Familiarity with IEC 62304 software lifecycle process
- Basic understanding of cybersecurity concepts (threat modeling, vulnerability management)
- Access to IEC 81001-5-1 standard (for detailed clause-level mapping)
Estimated Implementation Time: 3-6 months for initial framework establishment; ongoing integration with each product development cycle
Process Flow
Phase 1: Establish SPDF Foundation
Define the organizational security development policy, roles, and integration points with your existing QMS and design control process.
Define Security Development Policy
Create an organizational policy document that establishes the commitment to secure product development. Define scope (which products and processes are covered), security objectives, and management commitment. This policy becomes the top-level document in your SPDF documentation hierarchy.
Deliverables:
- Security Development Policy document
- Management commitment statement
- SPDF scope definition
💡 Tips:
- Align with your existing Quality Policy language
- Define scope broadly — all software-containing devices
- Get executive sign-off to ensure organizational buy-in
- Reference IEC 81001-5-1 and FDA guidance explicitly
Map SPDF to Design Controls
Create a mapping document that shows how each SPDF activity integrates into your existing design control process (design inputs → outputs → verification → validation → transfer). For each design control phase, identify the parallel security activity and its deliverables. This mapping is the key artifact that demonstrates integration.
Deliverables:
- SPDF-to-Design Control mapping matrix
- Updated design control SOP with security gates
- Security review checklists for each design phase
💡 Tips:
- Security requirements → Design Inputs
- Security architecture → Design Process
- Security test results → Design Outputs
- Penetration testing → Design Verification
- Security validation → Design Validation
Assign Security Roles and Training
Define security-specific roles within the product development team. At minimum, designate a Security Lead for each project who is responsible for security activities. Establish training requirements for all team members covering secure coding, threat modeling, and vulnerability management.
Deliverables:
- Security roles and responsibilities matrix
- Security training curriculum
- Training records
💡 Tips:
- The Security Lead does not need to be a dedicated hire — cross-train existing engineers
- Include security awareness training for all team members, not just developers
- Document training as evidence of SPDF implementation for submissions
Phase 2: Security Requirements and Threat Modeling
Define security requirements through systematic threat modeling and risk assessment. This phase runs in parallel with design input activities.
Conduct Threat Modeling
Create data-flow diagrams showing all system components, data flows, trust boundaries, and external interfaces. Apply STRIDE methodology to each element: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Document each identified threat with severity and potential impact.
Deliverables:
- System architecture diagrams
- Data-flow diagrams with trust boundaries
- STRIDE threat enumeration table
- Attack surface documentation
💡 Tips:
- Include ALL interfaces: network, USB, Bluetooth, serial, debug ports
- Trust boundaries are where data crosses between different privilege levels
- FDA expects data-flow diagrams specifically — block diagrams are not sufficient
- Update threat model whenever the architecture changes
Perform Cybersecurity Risk Assessment
For each identified threat, assess risk using exploitability-based methods (not probability-based). Evaluate using CVSS for known vulnerability scoring and CWSS for weakness scoring. Determine uncontrolled risk, identify candidate security controls, and evaluate residual risk after controls are applied.
Deliverables:
- Cybersecurity risk assessment document
- Risk-to-control mapping
- Residual risk analysis
💡 Tips:
- Do NOT use your ISO 14971 probability scale for cybersecurity
- Assume attackers are skilled, motivated, and persistent
- Use CVSS Base Score for known vulnerability severity
- Document why you chose each security control
Define Security Requirements
Translate threat model findings and risk assessment results into specific, testable security requirements. Each requirement should trace back to one or more threats. Requirements should cover: authentication, authorization, encryption (transit and rest), integrity verification, audit logging, secure boot, and update mechanisms.
Deliverables:
- Security requirements specification
- Requirements traceability matrix (threat → requirement)
- Security design inputs for DHF
💡 Tips:
- Write requirements that are testable — "shall encrypt using AES-256" not "shall be secure"
- Include both functional and non-functional security requirements
- Add security requirements to your formal Design Input document
- Each requirement must trace to at least one threat from the threat model
Phase 3: Secure Design and Implementation
Implement security controls through secure architecture design, coding standards, and component management.
Design Security Architecture
Create the security architecture that implements the security requirements. Document: encryption algorithms and key management, authentication and authorization mechanisms, network security controls, secure boot chain, data protection at rest and in transit, and secure update mechanisms. This architecture becomes part of the Design Process documentation.
Deliverables:
- Security architecture document
- Cryptography specification
- Network security design
- Secure update mechanism design
💡 Tips:
- Use defense-in-depth — no single control should be the only barrier
- Specify exact algorithms and key lengths (e.g., AES-256-GCM, RSA-2048)
- Design for secure defaults — security should be enabled out of the box
- Plan for key rotation and certificate management
Establish Secure Coding Standards
Define and document secure coding standards for all development. Standards should address: input validation, output encoding, memory safety, error handling, logging (without sensitive data), and avoidance of known-insecure patterns. Reference CERT Secure Coding Standards for your language (C, C++, Java, Python).
Deliverables:
- Secure coding standards document
- Static analysis tool configuration
- Code review checklist for security
💡 Tips:
- Tie standards to automated tooling — configure SAST tools to enforce them
- Include examples of both correct and incorrect patterns
- Review OWASP Top 10 and CWE Top 25 for common vulnerability patterns
- Require security-focused code review for all changes
Manage Software Bill of Materials
Implement SBOM generation as part of the build process. Track all first-party, third-party, open-source, and commercial software components. Set up continuous vulnerability monitoring by linking the SBOM to NVD/CVE databases. Define a process for evaluating and remediating newly discovered vulnerabilities.
Deliverables:
- Automated SBOM generation pipeline
- SBOM in SPDX or CycloneDX format
- Vulnerability monitoring dashboard
- Third-party component evaluation procedure
💡 Tips:
- Automate SBOM generation — manual tracking will fail at scale
- Include transitive dependencies (dependencies of dependencies)
- Choose CycloneDX for security use cases, SPDX for license compliance
- Set up automated alerts for CVEs affecting your components
Phase 4: Security Testing and Verification
Verify that security controls are correctly implemented through comprehensive security testing. This phase maps to Design Verification.
Perform Static and Dynamic Analysis
Run static application security testing (SAST) on all source code. Run dynamic application security testing (DAST) on running interfaces. Run software composition analysis (SCA) to identify vulnerable dependencies. Document all findings, prioritize by severity, and track remediation.
Deliverables:
- SAST scan results and remediation log
- DAST scan results and remediation log
- SCA vulnerability report
- Security findings tracking document
💡 Tips:
- Integrate SAST into CI/CD pipeline for continuous scanning
- Prioritize findings by exploitability, not just count
- Document rationale for any accepted false positives
- Re-scan after remediation to confirm fixes
Conduct Fuzz Testing
Perform fuzz testing on all device interfaces: network protocols, file parsers, API endpoints, USB interfaces, and Bluetooth connections. Fuzz testing sends malformed or unexpected data to find crashes, memory corruption, and unexpected behavior. Document all findings and remediation.
Deliverables:
- Fuzz testing plan and scope
- Fuzz testing results
- Crash analysis and remediation log
💡 Tips:
- Fuzz ALL input interfaces, not just network
- Run fuzz testing for a meaningful duration (days, not hours)
- Use both mutation-based and generation-based fuzzers
- FDA specifically calls out fuzz testing — this is not optional
Execute Penetration Testing
Conduct penetration testing of the device and any connected backend systems. Test should cover: network penetration, application-layer attacks, authentication bypass attempts, privilege escalation, data exfiltration, and denial-of-service resilience. Can be performed by internal security team or third-party firm.
Deliverables:
- Penetration testing report
- Finding remediation log
- Retest results confirming fixes
💡 Tips:
- Third-party penetration testing adds credibility to submissions
- Scope should include the device, mobile apps, cloud backend, and APIs
- Fix all Critical and High findings before submission
- Keep the report — FDA may request it during review
Phase 5: Security Validation and Release
Validate that the overall security posture meets requirements and prepare cybersecurity documentation for premarket submission.
Conduct Security Validation
Validate that the integrated system meets all security requirements under realistic conditions. Security validation differs from verification — it confirms the system is secure in its intended use environment, not just that individual controls work. Include end-to-end security scenarios and abuse case testing.
Deliverables:
- Security validation protocol and report
- Residual risk summary
- Security validation summary for submission
💡 Tips:
- Test in an environment that mimics the intended deployment
- Include realistic network conditions and user scenarios
- Validate that security does not degrade over time or with load
- Summarize residual risks with mitigation recommendations
Compile Submission Cybersecurity Package
Organize all cybersecurity documentation into the format expected by FDA reviewers. For 510(k) submissions, map to the eSTAR cybersecurity section. Include: SPDF process documentation, threat model, risk assessment, SBOM, security test results, post-market plan, labeling, and traceability matrix.
Deliverables:
- Cybersecurity submission package
- eSTAR cybersecurity section (if 510(k))
- Traceability matrix (threats → controls → tests)
- Executive summary of cybersecurity posture
💡 Tips:
- Cross-reference the FDA guidance appendix checklist item by item
- Include an executive summary that a non-technical reviewer can understand
- Ensure SBOM is in machine-readable format (not just a PDF table)
- Have a regulatory reviewer check the package before submission
Phase 6: Post-Market Security Management
Establish ongoing cybersecurity monitoring, patching, and incident response procedures.
Establish Vulnerability Monitoring
Set up continuous monitoring for newly discovered vulnerabilities affecting device components. Subscribe to NVD feeds, vendor security advisories, and CISA alerts. Configure automated SBOM-to-CVE matching. Define escalation procedures and response SLAs by severity level.
Deliverables:
- Vulnerability monitoring procedure
- Monitoring tool configuration
- Escalation and response SLA matrix
💡 Tips:
- Automate CVE monitoring against your SBOM — manual review does not scale
- Define clear SLAs: Critical = 48 hours, High = 2 weeks, etc.
- Include OT/embedded-specific vulnerability sources, not just IT databases
- Review monitoring effectiveness quarterly
Implement Patch Management Process
Create a documented process for developing, testing, validating, and deploying security patches. Include: risk assessment of each patch, regression testing requirements, deployment mechanisms, rollback procedures, and customer notification. Address both routine and emergency (out-of-cycle) patches.
Deliverables:
- Patch management SOP
- Patch validation protocol
- Customer notification templates
- Emergency patch procedure
💡 Tips:
- Security patches may not require a new 510(k) under FDA's guidance on software changes
- Test patches against your full V&V suite before deployment
- Communicate clearly with healthcare organizations about patch criticality
- Maintain a patch deployment log for audit purposes
Publish Coordinated Vulnerability Disclosure Policy
Create and publish a vulnerability disclosure policy that enables security researchers to report vulnerabilities. Include: secure reporting channel (e.g., security@company.com), acknowledgment timeline (within 5 business days), safe harbor statement, coordination with FDA and CISA, and public disclosure timeline.
Deliverables:
- Vulnerability Disclosure Policy (public)
- Internal vulnerability response procedure
- CISA/FDA coordination procedure
💡 Tips:
- Publish the policy on your website where researchers can find it
- Consider joining an ISAO for threat intelligence sharing
- Train your customer support team to recognize vulnerability reports
- Work with CISA ICS-CERT for coordinated disclosure of critical findings
Implementation Checklists
SPDF Foundation Checklist
Threat Modeling Checklist
Security Testing Checklist
Submission Readiness Checklist
Common Pitfalls & Solutions
Treating SPDF as a Separate Process
The SPDF must integrate into your existing design control process — not run in parallel. Conduct threat modeling during the design input phase, include security requirements in formal design inputs, and make security review a design phase gate requirement.
Using Probabilistic Risk for Cybersecurity
FDA explicitly rejects probability-based risk assessment for cybersecurity. Attackers are intentional, not random. Use exploitability-based scoring (CVSS, CWSS), create a separate cybersecurity risk document, and reference AAMI SW96 or TIR57 for the process framework.
Manual SBOM Tracking
Spreadsheet-based SBOM tracking is unsustainable and error-prone. Integrate SBOM generation into your CI/CD pipeline using automated tools (Syft, FOSSA, Snyk) and set up automated CVE monitoring against the SBOM.