Medical Device Design Phase Cybersecurity Guide

This guide is for engineering, quality, and regulatory teams planning a connected medical device. It explains what to define, model, and document during design. It is not a regulatory determination. Requirements and recommendations depend on the device, its intended use, and the submission pathway.

Want help with this work rather than a planning guide? See medical device secure design: requirements and threat modeling for Blue Goat's design-phase scope.

Why the design phase matters for patient safety

Cybersecurity controls are design decisions. The processor, the boot chain, the update mechanism, the open ports, and the cloud tenancy model are all chosen early. Each choice opens or closes attack paths that could affect therapy, diagnosis, or data.

A threat model written late can only record those choices. A threat model written at design can change them. That is the practical reason to start early. It is also why the FDA's guidance describes cybersecurity as part of the quality system and design controls, not a test run before submission.

For devices that meet the Section 524B definition of a cyber device, the statute requires a plan to monitor and address postmarket vulnerabilities, processes and procedures that provide reasonable assurance of cybersecurity, including updates and patches, and a software bill of materials. Design-phase work creates the foundation for each of those.

Inputs to gather before you start

Collect what you already have. Gaps are normal at this stage.

• Intended use and indications. Who uses the device, where, and for what clinical purpose.
• Use environments. Hospital network, home network, clinic, ambulance, or a mix.
• System sketch. Device, accessories, mobile apps, gateways, cloud services, and hospital systems.
• Interfaces. Wireless, wired, debug, removable media, and remote service paths.
• Software and suppliers. Operating system, third-party components, and supplier-provided modules.
• Existing hazard analysis. The current ISO 14971 risk file, even if incomplete.

Security requirements

Security requirements describe what the device must do to protect safety and effectiveness. Write each one so it can be verified by inspection, analysis, or test. Vague goals such as "the device shall be secure" cannot be traced or tested.

Group requirements by the areas the FDA's guidance describes as security controls:

• Authentication. How users, devices, and services prove identity, including service and maintenance access.
• Authorization. Which roles can perform which functions, with least privilege by default.
• Cryptography. Approved algorithms, key generation, key storage, and key lifecycle.
• Code, data, and execution integrity. Secure boot, signed firmware, and protection of stored data and configuration.
• Confidentiality. Protection of patient data and sensitive settings in storage and in transit.
• Event detection and logging. What security events are recorded and how they can be reviewed.
• Resiliency and recovery. Safe behavior during an attack or failure, and a path back to a known good state.
• Updatability and patchability. How updates are authenticated, delivered, and installed without unsafe interruption.

Link each requirement to the threats it addresses. Record where a requirement comes from: a threat, a standard such as IEC 81001-5-1, a hospital security expectation, or a clinical constraint.

Threat modeling at design

A threat model describes how the system could be attacked and what that could mean for patients. At design, it works from architecture diagrams rather than finished code.

1. Draw the system. Create data flow diagrams with processes, data stores, data flows, external entities, and trust boundaries.
2. Identify threats. Apply STRIDE at each element and trust boundary: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
3. Classify, then assess. STRIDE is a classification method. It does not score risk. Assess exploitability for each threat on its own terms.
4. Assess impact. Evaluate security impact separately. Take patient harm severity from the manufacturer's ISO 14971 hazard analysis.
5. Choose controls. Map each threat to the requirements and design controls that address it.
6. Revisit on change. Update the model when the architecture, interfaces, or suppliers change.

For a working format, see the FDA medical device threat model template and the guide to STRIDE threat modeling for medical devices.

Security risk assessment

The security risk assessment records each threat, its exploitability, its impact, the controls applied, and the residual risk. The FDA's guidance recommends assessing cybersecurity risk with exploitability rather than the probability-based estimates used for random failures.

Keep the security risk process connected to the safety risk process without merging them. Where a security threat could lead to a hazardous situation, the ISO 14971 risk file should reflect it. The manufacturer decides whether residual risk is acceptable.

Architecture views

The FDA's guidance recommends security architecture views that show how the system is protected. Common views include:

• Global system view. All components, connections, and trust boundaries.
• Multi-patient harm view. Paths where one compromise could affect many patients or devices.
• Updatability and patchability view. How software moves from the manufacturer to fielded devices.
• Security use case views. Key operational states, such as pairing, configuration, and service access.

Draw these from the same diagrams used in the threat model. Consistency between views and the model makes both easier to review.

Traceability

Traceability connects threats to requirements, requirements to design controls, and controls to verification. A traceability matrix shows that every identified threat has a response and every control has evidence.

Build the matrix during design, even though test evidence comes later. Empty test columns at this stage show where verification is still needed. They are planning information, not a defect.

Design-phase artifacts

By the end of design, a team typically has draft versions of these artifacts. The exact set depends on the device and its risk.

For how these artifacts map to submission content, see FDA premarket cybersecurity deliverables and the eSTAR map.

Ownership and quality records

The manufacturer owns its design controls, risk decisions, and quality records. An outside team can prepare analysis and draft artifacts. The manufacturer reviews, approves, and files them under its own procedures.

Agree early where cybersecurity records live in the quality system. Decide who updates the threat model when the design changes. That avoids a model that stops matching the device.

Common design-phase gaps

• Requirements written as goals that cannot be tested.
• Threat models drawn once and never updated after architecture changes.
• STRIDE categories treated as risk scores.
• Security risk disconnected from the ISO 14971 hazard analysis.
• Service and maintenance access left out of the threat model.
• No plan for authenticating and delivering updates.
• Third-party components not inventoried until late development.

Frequently asked questions

Do we need a prototype to start design-phase cybersecurity?

No. Intended use and a system sketch are enough to start requirements and an early threat model. The model becomes more detailed as the design matures.

Is a threat model required for an FDA submission?

The FDA's guidance recommends threat modeling as part of security risk management. Section 524B requires processes and procedures that provide reasonable assurance of cybersecurity for cyber devices. The documentation expected depends on the device and pathway.

Does STRIDE tell us how risky a threat is?

No. STRIDE classifies the type of threat. Exploitability and impact must be assessed separately. Patient harm severity comes from the manufacturer's hazard analysis.

Who approves the security risk assessment?

The manufacturer. An outside team can prepare analysis and recommendations. Risk acceptance and design decisions remain with the manufacturer.

Does design-phase work replace penetration testing?

No. Design-phase work defines requirements and controls. Penetration testing later evaluates a built system against them. Blue Goat scopes penetration testing separately.

Discuss your design-phase scope

Bring your intended use and system sketch. See medical device secure design: requirements and threat modeling for Blue Goat's design-phase work, or medical device cybersecurity consulting for ongoing support from design through postmarket.

Sources and related resources

• The FDA: Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 3, 2026
• 21 U.S.C. 360n-2: FD&C Act Section 524B
• Medical device cybersecurity SPDF playbook
• FDA medical device threat model template
• STRIDE threat modeling for medical devices
• Medical device threat modeling services