How Do I Conduct a Cybersecurity Risk Assessment for a New Medical Device to Meet FDA Standards?

A connected medical device can expose far more than patient data. A successful attack could interrupt treatment, alter device behaviour, or prevent clinicians from accessing essential functions. An FDA-aligned medical device cybersecurity risk assessment helps you identify possible attack paths, evaluate their effect on safety and performance, and select controls that reduce risk before submission.

The financial impact also deserves attention. IBM reported an average global breach cost of $4.44 million in 2025. The US average reached a record $10.22 million, while healthcare remained the costliest industry at $7.42 million per incident.

Your assessment must consider the complete device system, including firmware, software, mobile apps, APIs, cloud services, update processes, and third-party components. This guide follows the FDA guidance issued in February 2026 and the requirements under Section 524B. It explains how to assess cybersecurity risk and prepare the required evidence for submission.

Key Takeaways

• Cybersecurity work needs to start while the device is still being designed. Leaving it until submission can expose gaps that take longer to fix.
• Keep the cybersecurity file connected to the ISO 14971 safety process whenever a security failure could place a patient at risk.
• A vulnerability score does not tell the whole story. Consider how realistic the attack is and what could happen to patients if it succeeds.
• Penetration testing proves whether selected safeguards hold up under attack. It still forms only one part of the wider assessment.
• For devices covered by Section 524B, the manufacturer must provide an SBOM and show how vulnerabilities will be monitored and addressed after release.

What Does FDA Expect From a Medical Device Cybersecurity Risk Assessment?

The FDA cybersecurity guidelines state that cybersecurity should be built into your quality management system and product development process. Your assessment should show that risks were considered during design and will continue to be managed after release.

It should explain:

• Which assets and device functions need protection
• How threats and vulnerabilities were identified
• How a security failure could affect safety or effectiveness
• Which controls were added
• How were those controls tested
• How will the remaining risks be monitored after launch

ISO 14971 supports safety risk management. AAMI TIR57, ANSI AAMI SW96, and IEC 81001 5 1 can support cybersecurity risk management and development activities.

These standards provide useful structure, but they do not automatically meet every FDA or Section 524B requirement. Your submission must still address the specific risks, controls, testing, and monitoring needs of the device.

Is the Medical Device Covered by Section 524B?

Begin by determining whether the product qualifies as a cyber device. A device generally falls under Section 524B when it contains software authorised by the sponsor, can connect to the internet, and includes technical features that could be affected by cybersecurity threats.

The review should cover the complete device system rather than the main product alone. Check companion applications, gateways, cloud platforms, service laptops, APIs, and update services. Internet access through any of these connected components can affect whether the product meets the definition.

Document your conclusion and the reasons behind it. Record the relevant device pathway, current regulatory status, connectivity features, and the basis used to decide whether Section 524B applies.

A previously authorised device can also become subject to Section 524B when a modification requires a new premarket submission.

Ready for FDA Approval?

Regulatory approval starts with cybersecurity readiness. Validate your device before submission.

👨‍⚕️ Talk to a Medical Device Expert →

How to Conduct a Cybersecurity Risk Assessment for a New Medical Device

Step 1: Define the Medical Device System and Assessment Scope

Start by documenting the device’s intended use, users, care setting, clinical function, essential performance, expected lifetime, and safety-critical operations. This gives the assessment a clear basis and helps you identify which parts of the system need closer review.

Next, define the complete system boundary. Include the embedded device and firmware, mobile or desktop applications, cloud services, APIs, web portals, hospital interfaces, remote support functions, and update systems.

You should also record the main security assumptions. These may include:

• Untrusted hospital networks
• Compromised smartphones
• Loss of cloud connectivity
• Physical access to the device

The scope must also cover risk during manufacturing, installation, servicing, updating, decommissioning, and end of support.

Step 2: Inventory Assets, Interfaces, and Software Components

Create a detailed record of the assets that support device operation, data handling, connectivity, and safety. This includes therapy settings, safety limits, patient data, credentials, firmware, operating systems, software libraries, APIs, hardware ports, radios, sensors, storage, cloud services, update servers, and manufacturer portals.

Each entry should show:

• Asset function
• Responsible owner
• Current version
• Connected interfaces
• Technical dependencies
• Confidentiality requirements
• Integrity requirements
• Availability requirements
• Safety relevance
• Support status

Keep the inventory current as the device design changes. It will support later work such as threat modelling, SBOM preparation, vulnerability monitoring, and supplier assessment.

Step 3: Map Architecture, Data Flows, and Trust Boundaries

Create clear diagrams of the device architecture and its data flows. Show the main components, connected systems, communication paths, sensitive data stores, user roles, privilege levels, third-party dependencies, and existing security controls.

Mark each trust boundary where data or commands pass between different environments. This may include movement between the device, hospital network, cloud service, mobile app, user account, and manufacturer system.

Add a separate update view that shows:

• Update source
• Signing and validation process
• Distribution path
• Rollback method
• Recovery process

Also assess shared systems such as backend platforms, update servers, certificate authorities, and fleet portals. A compromise in one of these systems could affect many devices or patients at once.

Step 4: Identify Attack Surfaces and Threat Scenarios

Look for every route that could expose the device to attack. Review wireless connections such as WiFi and Bluetooth. Check cellular access, Ethernet ports, APIs, cloud endpoints, web portals, mobile apps, and update channels.

Physical access can create separate risks. Examine USB ports, debug interfaces, service menus, removable media, pairing controls, and factory reset functions.

Also, review risks introduced through suppliers and shared infrastructure. This includes third party software, firmware vendors, build systems, code repositories, cloud providers, and signing services. Use a method such as STRIDE, attack trees, or abuse cases. For each threat scenario, record:

• The asset at risk
• The entry point and weakness
• The possible attack path
• The clinical function was affected
• The controls required
• The test used to verify them

Step 5: Connect Each Threat to Device Failure and Patient Harm

Trace each threat from the technical weakness to its possible effect on the patient. The sequence should show the threat source, the vulnerability, the security compromise, the resulting device failure, the hazardous situation, and the final harm.

Consider both direct and indirect harm. Direct harm may involve incorrect therapy, altered dosage, suppressed alarms, or changed diagnostic results. Indirect harm may result from delayed diagnosis, unavailable treatment, missing patient data, interrupted monitoring, or disruption across a device fleet.

Transfer the related hazardous situations and harms into the ISO 14971 safety risk process. Keep the technical threat details and exploitability analysis in the cybersecurity file.

For example, an attacker could access an infusion pump API without authentication and change a dosage setting. The device may accept the command and deliver the wrong dose. Controls could include mutual authentication, command signing, enforced safety limits, and anomaly detection.

Step 6: Assess Exploitability, Harm Severity, and Initial Risk

Rate how feasible the attack is. Base the score on factors such as required access, privilege level, attacker skill, attack complexity, exploit availability, physical proximity, user involvement, repeatability, scale, and active use in the wild.

Next, assign a harm severity using the organisation’s safety scale. Also consider the possible reach of the incident. A weakness may affect one patient, a group of devices, one facility, or the entire installed fleet.

The initial risk rating should also reflect:

• How easily the attack can be detected
• Whether the device can recover
• Whether it can enter a safe state

CVSS can support technical ranking, but it should not replace medical device-specific risk analysis. 

Step 7: Define Security Controls and Evaluate Residual Risk

Convert the chosen safeguards into clear security requirements that can be tested and approved.

For each risk, record:

• The control implemented
• Evidence that it works
• The remaining exploitability
• The remaining harm severity
• The acceptance decision
• The person authorised to approve it
• Is any postmarket monitoring needed

Accepted residual risk needs a written justification. Explain why the remaining exposure is tolerable and why further reduction is not reasonably feasible.

Labelling can explain safe use. It should not replace a design control that can be built into the device.

Step 8: Assess Software Supply Chain and SBOM Risk

Review every commercial, open source, and off-the-shelf software component. Check its supplier, current version, support status, end-of-life date, available updates, known vulnerabilities, and dependent packages. Also note whether the component affects security or clinical operation.

Section 524B requires an SBOM for qualifying cyber devices. CycloneDX and SPDX are widely used formats for presenting this information.

The SBOM must remain useful after release. Manufacturers should track newly disclosed vulnerabilities, assess their effect on the specific device, and patch or mitigate affected components.

Unresolved software anomalies also need review. Determine whether an anomaly could be intentionally triggered to bypass a control, change device behaviour, interrupt service, or combine with another weakness.

Step 9: Verify Security Through Testing and Retesting

Test every security requirement and confirm that each mitigation works as intended. Use methods suited to the device, such as:

• Static and dynamic code analysis
• Software composition analysis
• Vulnerability scanning
• Fuzz and malformed input testing
• Authentication and privilege testing
• Update tampering and rollback testing
• Logging and recovery testing

Penetration testing should cover the complete product system, including firmware, applications, APIs, cloud services, wireless interfaces, web portals, update services, and remote support.

The report should include:

• Tester qualifications and independence
• Scope, methods, and limitations
• Findings and supporting evidence
• Remediation status

After remediation:

• Perform targeted retesting
• Run regression testing where needed
• Update the threat model and risk assessment
• Recalculate residual risk
• Close the finding only after the fix is verified

Step 10: Build Traceability and the Security Risk Management Report

Create a traceability matrix that connects each risk to the evidence used to address it:

Asset → threat → vulnerability → harm → security requirement → control → test → result → residual risk

The matrix should link the threat model, risk register, safety file, SBOM, security requirements, test evidence, findings, and corrective actions.

The final security risk management report should include:

• Assessment scope and system description
• Methodology and risk acceptance criteria
• Asset inventory and architecture diagrams
• Threat model and attack surface analysis
• Risk register and security requirements
• SBOM and supplier review
• Testing summary and penetration test report
• Residual risk conclusion
• Traceability matrix
• Approval history

The report should make it easy to follow any risk from its source to the final approval decision.

Step 11: Prepare Postmarket and FDA Submission Documentation

Prepare a Section 524B plan for postmarket and FDA submission documentation monitoring. It should cover vulnerability intake, supplier reports, patient impact review, patch priorities, customer communication, and coordinated disclosure.

For eSTAR, organise the core evidence:

• Cyber device determination
• Security risk management report
• Threat model
• SBOM
• Testing and penetration test reports
• Residual risk justification
• Postmarket plan
• Cybersecurity labelling

Prepare these records during development so the submission does not depend on missing or incomplete evidence.

How Qualysec Can Support Medical Device Cybersecurity Testing

Qualysec tests the parts of a Medical Device Cybersecurity system that attackers could reach. The scope can cover firmware, connected hardware, mobile apps, APIs, cloud services, web portals, and remote support systems.

Testing can follow your threat model and critical clinical functions. You receive:

• Confirmed findings with technical evidence
• Clear reproduction and remediation steps
• Severity ratings and retesting results

FDA guidance expects penetration testing to identify and demonstrate exploitable weaknesses. Qualysec can provide this independent testing evidence, while the manufacturer remains responsible for the full risk management process.

Turn unresolved device risks into verified testing evidence with Qualysec.

Conclusion

A medical device security risk assessment should grow with the product rather than begin when the submission is almost ready. Early preparation gives your team time to test controls, resolve weak points, and support each decision with clear evidence.

The FDA’s February 2026 guidance places cybersecurity within the quality management system and the full product life cycle. Conducting comprehensive FDA services across the complete view of the connected device system helps reduce missing evidence and avoid preventable questions during regulatory review.

Speak Directly With Qualysec’s
Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQs

Q.Does ISO 14971 fully cover medical device cybersecurity risk?

No. ISO 14971 supports safety risk management. A separate security assessment is still needed to examine malicious threats, vulnerabilities, exploitability, and changing attack conditions. The two processes should remain connected where a security issue could cause patient harm.

Q.Does every new medical device require an SBOM?

An SBOM is required under Section 524B when the product qualifies as a cyber device and enters a covered premarket pathway. It must include commercial, open source, and off-the-shelf software components.

Q.Is penetration testing required for an FDA medical device submission?

FDA recommends penetration testing as part of cybersecurity verification. The exact scope should reflect the device architecture, identified threats, and level of cybersecurity risk. The resulting report should be included in the submission where applicable.

Q.Can the development team perform the penetration test?

Internal testers can perform it, provided they have suitable expertise and enough independence from the developers. The report should identify who completed the test and explain their level of independence. Some devices may require an external testing team.

Q.Can CVSS be used for medical device cybersecurity risk scoring?

CVSS can help rank the technical severity of a vulnerability. It does not account fully for clinical harm, device use, exploitability over time, or the number of patients and devices exposed. Use it alongside a medical device-specific risk assessment.