Medical Device Secure Design Requirements, Threat Modeling, and Artifacts
Build cybersecurity into the design phase through security requirements, architecture review, threat modeling, and traceable artifacts aligned with the FDA's February 2026 guidance. Scope the work around your intended use, connected systems, and patient-safety considerations.
The short answer
What cybersecurity work belongs in medical device design?
Design-phase cybersecurity connects intended use and patient-safety considerations to security requirements, architecture decisions, and threat modeling. A Secure Product Development Framework (SPDF) provides the lifecycle context. Design artifacts record threats, controls, assumptions, and planned security evidence with traceability. Blue Goat supports the agreed cybersecurity work; the manufacturer owns design approval and risk acceptance. The FDA's February 2026 guidance describes recommended documentation, not a promise of a regulatory outcome.
275+ FDA submissions supported, zero cybersecurity rejections.
- Deficiency Commitment
- Fixed-Fee Pricing
- Retests Included
- FDA eSTAR Aligned
- Free 30-min call
- No obligation
- Senior expert
- Fixed fee in 24h
- NDA on request
- US-based team
The design phase
Turn security decisions into traceable design inputs
The design phase connects intended use, system architecture, threats, and security requirements before implementation decisions are fixed. Blue Goat supports this work within an agreed product cybersecurity scope. Your engineering, quality, and regulatory teams own design approval, risk acceptance, and submission decisions.
Threat and system context
What could be attacked, how, and across which boundary?
Requirement and control
What must the design do to address the identified threat?
Planned evidence
How will the team document the control and assess it during development?
Requirements
Define what the device must protect
Security requirements are design inputs, not a list of tools. Tailor them to the device's intended use, connectivity, deployment, and lifecycle. The categories below are starting points for a device-specific review, not a universal checklist.
Intended use and patient safety
Start with the clinical function, users, environment of use, and essential performance. Connect security concerns that can reach a patient to the manufacturer's hazard analysis.
Access and trust boundaries
Define identities, roles, authentication, authorization, and separation between device, companion app, cloud, and service interfaces. Record what each boundary is intended to protect.
Data and communications
Specify protection for data at rest and in transit, command integrity, credential storage, and key management. Include the assumptions made about hospital networks and external systems.
Boot, updates, and recovery
Define software authenticity, update authorization, rollback behavior, secure recovery, and access to debug interfaces. Document how the device maintains its clinical function when a security control fails.
Components and suppliers
Record software components, supplier responsibilities, support information, and vulnerability handling. Plan how the software inventory will become an SBOM tied to the actual device build.
Evidence and change control
Give each security requirement an identifier, rationale, owner, and acceptance criteria. Record the planned evidence and reassess requirements when architecture or threat assumptions change.
Threat modeling
Use the threat model to shape the architecture
Start with a system sketch and refine it as the design develops. Cover the device and connected systems, including external dependencies, service access, software updates, and the environment of use. Record assumptions and gaps rather than treating an early model as a finished assessment.
Blue Goat uses STRIDE to classify threats at data-flow elements and trust boundaries. STRIDE does not score risk. Exploitability and security impact are assessed separately. Where a threat can reach a patient, harm severity comes from the manufacturer's ISO 14971 hazard analysis.
Medical Device Threat Modeling- Map assets, entry points, data flows, and trust boundaries.
- Describe threats and abuse cases, including lifecycle and supply-chain paths.
- Connect mitigations to security requirements and architecture decisions.
- Record residual risks, open decisions, and manufacturer review responsibilities.
- Revisit the model after material design, component, interface, or deployment changes.
Artifacts
A design-stage evidence set aligned with FDA guidance
Agree the artifact scope before work begins. Design-stage documents record decisions and planned evidence. They are not a completed premarket submission package or a substitute for later security testing.
- Security requirements
- Identified requirements with rationale, acceptance criteria, owners, and links to design controls.
- Threat model
- System scope, data flows, entry points, trust boundaries, assumptions, threats, mitigations, and unresolved questions.
- Architecture views
- Global System, Multi-Patient Harm, Updateability/Patchability, and Security Use Case views, with device-specific explanations.
- Security risk assessment
- Exploitability and security impact, control rationale, residual risk, and links to manufacturer-owned safety analysis where patient harm is possible.
- Traceability matrix
- Connections from threat to requirement, design control, planned security test, and resulting evidence as development progresses.
- Lifecycle planning inputs
- Component inventory, SBOM approach, update and support assumptions, vulnerability management, and cybersecurity labeling inputs.
The FDA's February 3, 2026 final premarket cybersecurity guidance recommends a Secure Product Development Framework and describes recommended submission documentation. Section 524B establishes statutory duties for applicable cyber-device submissions. Guidance recommendations and statutory duties are not interchangeable, and applicability needs manufacturer regulatory review.
Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (the FDA, February 3, 2026)Premarket cybersecurity deliverables and eSTAR mapping
Read the full guide: Medical device design phase cybersecurity: requirements, threat modeling, and artifacts
Start and handoff
Start with what your team has today
Bring the current design inputs
Share intended use, a system sketch, planned interfaces, component choices, existing security requirements, and available hazard analysis. Identify the engineering, quality, and regulatory owners. A working prototype is not necessary to begin the design discussion. Missing inputs remain documented as open questions.
Keep ownership clear
Blue Goat prepares the agreed cybersecurity analysis and documentation. Your team reviews and approves the design, QMS records, and risk decisions. Penetration testing, full submission packages, postmarket monitoring, and QMS procedure changes need explicitly agreed scope. General software verification and validation are not Blue Goat services.
FDA cybersecurity requirements just got tougher
Section 524B of the FD&C Act requires cyber device sponsors to have processes that provide reasonable assurance of cybersecurity, and the FDA recommends an SPDF as one way to meet that. Be ready to show the artifacts, not promises.
Months of delay, millions lost
FDA cybersecurity deficiencies routinely add 3-6 months to clearance timelines. For a $20M/year device, that's $1.5M+ in lost revenue, plus burn and investor pressure.
RTAs & deficiency letters
Per FDA premarket cybersecurity guidance, missing or weak SPDF documentation is one of the top reasons reviewers send deficiency letters or refuse-to-accept (RTA) determinations.
How IEC 81001-5-1 structures secure developmentPatient safety & liability
Without an SPDF, vulnerabilities slip into production, leading to recalls, MedWatch alerts, lawsuits, and brand damage you can't undo.
The eight pillars of an SPDF for FDA submissions
Aligned to the FDA's February 2026 cybersecurity guidance: an SPDF is one way to satisfy the QMSR (21 CFR 820 / ISO 13485:2016), it's an integrated process, not a single document. We deliver every piece.
Process & lifecycle
- SPDF process design tailored to your QMSR and IEC 62304 lifecycle
- Threat modeling (STRIDE) workshops, DFDs, threat trees, and risk ratings
- Security architecture views: multi-patient harm, updateability, secure use
- Postmarket monitoring with patch timelines, CVD, and CVE tracking
Software supply chain
- SPDX-format Software Bill of Materials
- Software of Unknown Provenance (SOUP) analysis
- Continuous vulnerability monitoring via GoatWatch
- End-of-support and third-party risk controls
Verification & testing
- Device, cloud, mobile, and BLE security testing across every interface
- Firmware security testing: extraction, reverse engineering, and binary analysis
- RF testing of proprietary radios, Wi-Fi, and cellular interfaces
- Medical protocol testing: DICOM, HL7/FHIR, MedRadio
- Fuzz testing of inputs, interfaces, and protocols
- Retests included until risks are mitigated (every medical device pentest engagement)
Submission documentation
- Section 524B Cybersecurity Risk Management Report
- Cybersecurity Management Plan, labeling, and traceability
- eSTAR-formatted, reviewer-ready package
- Regulatory mapping to FDA, EU MDR/IVDR (MDCG 2019-16), Health Canada, PMDA
Design-time decisions that lock in cybersecurity posture
Most cybersecurity cost on a medical device is decided before the first prototype boots. The engagement covers the architectural and process decisions that determine whether the device clears §524B cleanly or fights deficiencies for years.
- 01Architecture (trust boundaries, segmentation, root of trust)
- 02SoC + secure-boot stack selection
- 03Wireless stack + protocol choice
- 04Update + key-management design
- 05Cloud + identity architecture
- 06SDLC + SPDF tooling
- 07SBOM + VEX pipeline
- 08Threat-modeling cadence + QMS integration
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
From first call to FDA submission package in 4 steps
Most vendors put you in a 4-to-8-week onboarding queue. We start this week.
- 01
1 · Discovery call (30 minutes)
Talk directly with a senior MedTech security practitioner. We learn your device, submission timeline, intended use, and risk profile. No sales reps, no qualification gauntlet.
- 02
2 · SPDF gap assessment (within 24 hours)
We map your current state against FDA 524B, AAMI SW96, and IEC 81001-5-1, then deliver a fixed-fee scope, deliverables list, and timeline. No T&M, no scope creep.
- 03
3 · SPDF build & integration (starts in days)
We embed with your engineers, run threat modeling workshops, generate SBOMs, perform pen testing, and produce every required artifact, in your QMS, on your tools.
- 04
4 · submission package for FDA premarket submissions
Cybersecurity Risk Management Report, threat model, SBOM, security architecture views, pen test report, and labeling, eSTAR-formatted and backed by our remediation commitment.
Submission deliverables in one engagement
Every engagement ships with traceable, complete artifacts aligned with current FDA guidance.
medical device cybersecurity consulting retainer
- Security architecture and trust boundaries
- Cryptography and key management
- Secure boot and update strategy
- Developer training for medical teams
Public premarket cybersecurity history
Recalls, CISA ICS-MA advisories, and disclosed research that shape what reviewers ask about, and what this engagement is built to cover.
- the FDA·2023-2026
Section 524B(b)(2) updateability as design-input
Section 524B treats updateability as a design-input requirement, not a postmarket aspiration. Devices designed without a defensible update channel are hard to fix later, and reviewers may ask for design changes.
SPDF frequently asked questions
Secure by design, baked into the SDLC, not bolted on at V&V.
Build cybersecurity into the design phase through security requirements, architecture review, threat modeling, and traceable artifacts aligned with the FDA's February 2026 guidance. Scope the work around your intended use, connected systems, and patient-safety considerations.