Medical Device Cybersecurity
A practical orientation to medical device cybersecurity — what it covers, why it matters, and where to go next for regulatory requirements, standards, and Aktriva's services.
What is medical device cybersecurity?
Medical device cybersecurity is the practice of protecting connected medical devices — and the software and data they depend on — from threats that could compromise their safety, effectiveness, or the confidentiality of patient data.
It differs from conventional IT security in one critical way: a compromised device isn't just a data-breach risk, it's a potential patient-safety event. Ransomware on a hospital laptop is a business problem; the same attack against an infusion pump or a networked imaging system is a clinical one. That's why cybersecurity, safety, and device performance are treated as inseparable — a control that degrades clinical performance, or a fix that opens a new attack surface, both fail the same requirement.
Why medical device cybersecurity matters
- Patient safety — a compromised device can directly harm the person using it, not just leak data.
- Device availability — ransomware or exploited vulnerabilities can take life-sustaining devices offline.
- Sensitive data — devices increasingly store and transmit protected health information.
- Regulatory expectations — FDA, EU MDR/IVDR, and other regulators increasingly expect manufacturers to demonstrate that cybersecurity risks have been addressed as part of device safety and performance.
- Growing connectivity — wireless, cloud, and mobile connectivity keep expanding the attack surface.
Across the product lifecycle
Cybersecurity isn't a phase — it runs the full length of a device's life, from the first design decision to the day it's decommissioned.
Premarket: Concept & design · Requirements · Architecture · Development · Verification & validation · Regulatory submission
Post-market: Deployment · Vulnerability monitoring · Risk assessment · Remediation & updates · End of support
Aktriva's Security by Design Services cover the premarket half of that lifecycle end-to-end; Post-Market Services pick up everything after launch.
Security by design
Security by design means building security into a device from the earliest design decisions rather than testing it in at the end.
In practice: security requirements alongside product requirements, threat modeling, an architecture built around authentication, access control, and encryption, secure development practices, least privilege by default, and resilience/recovery for when something does go wrong. See Security by Design Services for how this gets embedded into an existing development process.
Cybersecurity risk management
Cybersecurity risk management identifies threats and vulnerabilities, assesses their likelihood and impact, and applies controls to reduce risk to an acceptable level — then documents what risk remains and why it's acceptable.
Per AAMI TIR57, cybersecurity risk management runs as its own process, aligned with ISO 14971 safety risk management — its own risk management plan, analysis, evaluation, control, residual-risk acceptability check, and report — rather than being folded into it. The two processes stay connected at two points: security risks surfaced during security risk evaluation that carry a potential safety impact are fed into safety risk evaluation, and because a control can cut both ways, security controls that affect safety and safety controls that affect security are each fed back into the other process's risk control step. Post-market, both processes draw on the same complaint and vigilance data.
What a cybersecurity program needs to cover
Whatever the device, market, or company size, a medical device cybersecurity program works through the same core activities:
- Establish cybersecurity responsibilities and governance
- Identify cybersecurity risks and threats
- Define security requirements and architecture
- Perform threat modeling and security risk management
- Implement secure development practices
- Generate and maintain an SBOM
- Perform security verification and testing
- Prepare cybersecurity documentation for regulatory submission
- Monitor vulnerabilities after release
- Assess, remediate, and disclose vulnerabilities throughout the product lifecycle
Key cybersecurity artifacts
The documentation set a cybersecurity program typically produces — useful as a quick reference for "what do we actually need to write." This list reflects FDA expectations specifically; other regulators largely expect the same artifacts, though naming and exact detail can vary — see Global Regulations for jurisdiction-specific requirements.
| Artifact | Purpose |
|---|---|
| Threat Model | Identifies threats, vulnerabilities, and attack pathways across the device's architecture — hardware, software, data flows, and network interfaces. |
| Security Architecture Views | Global System, Multi-Patient Harm, Updatability & Patchability, and Security Use Case views, plus documentation of implemented security controls. |
| Cybersecurity Risk Assessment | Assesses security risks and residual-risk controls, focused on exploitability — distinct from safety risk management. |
| SBOM | Machine-readable inventory of software components and dependencies, including support level and end-of-support dates. |
| Vulnerability assessment | Identifies and assesses known vulnerabilities in custom and third-party code used by the medical device system, including those in CISA's KEV Catalog. |
| Cybersecurity Testing Documentation | Evidence that security requirements, threat mitigations, and vulnerabilities have been tested — including penetration testing. |
| Labeling | Cybersecurity information for securely configuring, deploying, maintaining, and updating the device. |
| Cybersecurity (Vulnerability) Management Plan | Defines how postmarket vulnerabilities are identified, assessed, remediated, and monitored. |
| Security Risk Management Report | Summarizes risk evaluation methods, residual risk conclusions, and risk mitigation activities, incorporating the threat model, risk assessment, SBOM, and vulnerability assessment above. |
See our FDA submission requirements guide for the full detail behind each artifact, including what's required specifically for "cyber devices" under Section 524B.
FDA medical device cybersecurity requirements
Section 524B of the FD&C Act gives FDA statutory authority to require cybersecurity information for "cyber devices" as a condition of premarket submission.
Current guidance: FDA's February 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, supersedes the June 2025 version. The update aligns FDA's cybersecurity recommendations with the Quality Management System Regulation (QMSR), effective February 2, 2026.
524B requirements translate into cybersecurity content a submission has to include: a cybersecurity management plan, SBOM, vulnerability management commitments, and security testing evidence, plus post-market obligations after clearance. That content is typically submitted through FDA's eSTAR template, though eSTAR isn't required for every pathway — some PMA submissions, for example, can currently proceed outside it. It's detailed enough to warrant its own guide — for source documents see Global Regulations, for submission support see Regulatory Compliance Consulting, and for background see our coverage of FDA's premarket guidance and what submissions require.
Cybersecurity regulations vary by market
FDA's requirements are only one piece. The EU's MDR and IVDR address cybersecurity through Annex I and MDCG guidance, and dozens of other jurisdictions — the UK, Japan, South Korea, Singapore, Australia, Canada, and more — have their own expectations, at different stages of maturity.
What clears FDA review doesn't automatically satisfy MDR, and vice versa. See our Global Regulations reference for the current document from each jurisdiction we track.
Medical device cybersecurity standards & frameworks
Regulations generally establish requirements and expectations, while standards and industry frameworks provide structured approaches for implementing and demonstrating cybersecurity. The ones that come up most often:
| Area | Standards / frameworks |
|---|---|
| Safety risk management | ISO 14971 |
| Cybersecurity risk management methodology (runs parallel to safety risk management — see Risk management) | AAMI TIR57 |
| Holistic, lifecycle-wide device cybersecurity management | IEC 81001-5-1, ANSI/AAMI SW96 |
| Software lifecycle foundation (not itself a security standard) | IEC 62304 |
| Post-market vulnerability management | AAMI TIR97 |
| Broader security practices | NIST (CSF, SP 800-series) |
| International regulatory principles | IMDRF |
| Industry practices & playbooks | HSCC, MITRE, MDIC |
Medical device security testing
Security testing for a medical device has to answer a more specific question than a typical vulnerability scan: not just "does a known CVE exist," but "can it actually be exploited in this device's real operating context, and what happens if it is."
That's the gap between a generic scan and genuine exploitability validation. Regulatory submissions increasingly need evidence that security testing is appropriate to the device's architecture, threat model, and identified risks — a complete program covers vulnerability assessment, penetration testing across hardware and software interfaces, and verification tied to the device's actual threat model, not a generic IT checklist. See Penetration Testing & Exploitability Validation.
SBOM and vulnerability management
A Software Bill of Materials (SBOM) is a machine-readable inventory of every software component in a device — first-party, open-source, and third-party — and it's the foundation everything else here depends on.
Once you know what's in a device, vulnerability management becomes possible: monitoring new CVEs against that inventory, triaging which apply, assessing risk, remediating, and — where appropriate — coordinating disclosure with external researchers. This is ongoing work, not a one-time submission artifact. See Post-Market Services for how it's run as a managed program.
Post-market cybersecurity
A device's cybersecurity obligations don't end at clearance. Post-market cybersecurity covers continuous vulnerability monitoring, incident response, coordinated disclosure, and the security update process for as long as the device is in the field.
Legacy devices are a particular pressure point — one that can no longer receive updates, like those still running Windows 10 past its end-of-life date, still needs a documented risk position, not silence. This is what Post-Market Services manages on a manufacturer's behalf.
Common medical device cybersecurity challenges
Several recurring factors make this harder than typical enterprise IT security:
- Legacy technology still running in the field years past its original support window
- Third-party and open-source software components outside the manufacturer's direct control
- Cloud connectivity and mobile companion apps expanding the attack surface
- AI-enabled features introducing new, less understood risk categories
- Interoperability requirements that widen the number of systems a device has to trust
- Long product lifecycles, often a decade or more, against a faster-moving threat landscape
- Limited update capability on devices not designed to be patched easily or often
- Translating regulatory expectations into concrete engineering requirements
- Maintaining cybersecurity evidence across the full product lifecycle, not just at submission
- Coordinating engineering, quality, regulatory, and security teams around shared ownership
How Aktriva helps
Aktriva works across every area covered on this page, as five connected services rather than one-off engagements.
Regulatory Compliance Consulting
Guidance through complex global cybersecurity regulations: FDA, EU MDR, NMPA, PMDA, and beyond, so your submissions clear the bar the first time.
Learn more →Security by Design Services
Cybersecurity embedded into every stage of the medical device lifecycle: threat modeling, architecture, and secure development, from first design decision through deployment.
Learn more →Penetration Testing & Exploitability Validation
An ongoing, annually-renewed subscription that continuously proves which findings are actually exploitable in your device's real operating context, not a one-time scan that goes stale.
Learn more →Post-Market Services
End-to-end SBOM monitoring, triage, risk assessment, security testing, and coordinated vulnerability disclosure, managed on your behalf against your cybersecurity management plan.
Learn more →Executive Advisory & Fractional Leadership
A fractional Head of Product Security for teams that need senior leadership judgment now, without full-time overhead.
Learn more →Related resources
Everything above links out to something more specific. Here's the full map:
- Global Regulations — the current regulation and guidance document from every jurisdiction we track
- Cybersecurity Standards — the full standards stack across the device lifecycle
- Industry Frameworks — voluntary playbooks from HSCC and MDIC
- Weekly Briefing — regulatory changes and deadlines, updated every week
- Articles — deeper coverage of specific regulations, standards, and events
- Free Tools — calculators and self-assessment tools for cybersecurity risk and regulatory readiness
Frequently asked questions
What is medical device cybersecurity?
Protecting connected medical devices, and the software and data they depend on, from threats that could affect patient safety, device availability, or data confidentiality — treated as part of safety risk management, not a separate IT concern.
What are FDA's medical device cybersecurity requirements?
Under Section 524B of the FD&C Act — and FDA's February 2026 guidance aligning cybersecurity recommendations with the QMSR — FDA requires applicable "cyber device" submissions to address a cybersecurity management plan, SBOM, vulnerability monitoring commitments, and security testing evidence, plus ongoing post-market responsibilities.
See our FDA submission requirements guide →What cybersecurity standards apply to medical devices?
Most commonly ANSI/AAMI SW96, AAMI TIR57/TIR97, IEC 81001-5-1, ISO 14971, and IEC 62304, alongside NIST and IMDRF/HSCC guidance — which ones apply depends on the device and target markets.
What is security by design?
Building security requirements, threat modeling, and controls like authentication, encryption, and least privilege into a device from the earliest design stage, rather than adding them before submission.
What is an SBOM?
A Software Bill of Materials — a machine-readable inventory of every software component in a device, used as the foundation for ongoing vulnerability monitoring.
What is medical device penetration testing?
Testing that goes beyond a vulnerability scan to validate whether a finding is actually exploitable in a device's real operating context — not just a checklist of known CVEs.
What are post-market cybersecurity responsibilities?
Continuous vulnerability monitoring, triage, risk assessment, security updates, and coordinated disclosure for as long as a device is in the field, including a documented position once past its support window.
Not sure where to start?
Tell us about your device and where you are in the lifecycle — we'll point you to the right service.