1. Introduction

Cybersecurity standards for connected medical devices are the technical standards, regulatory requirements, and risk-management procedures designed to protect medical equipment that exchanges data with hospital networks, cloud platforms, mobile applications, or other connected devices.

Examples include:

Internet-connected pacemakers and cardiac monitors.

Insulin pumps and continuous glucose monitoring systems.

MRI, CT, and other medical imaging equipment.

Network-connected ventilators and infusion pumps.

Remote patient monitoring devices and wearable medical sensors.

Connected surgical robots and software-controlled diagnostic equipment.

Cybersecurity is not merely an information-technology concern in this context. A compromised medical device can expose confidential patient information, produce unreliable readings, interrupt treatment, or cause physical injury.

The US Food and Drug Administration (FDA) issued updated final guidance on medical-device cybersecurity in February 2026, addressing secure design, quality management, premarket documentation, and lifecycle risk management. The guidance is generally nonbinding, although separate statutory and regulatory obligations may be enforceable.

FDA+1

Central legal principle: A manufacturer must consider whether a foreseeable cybersecurity failure could compromise a device's safety or effectiveness. Hospitals, software suppliers, manufacturers, and healthcare providers may each have responsibilities depending on their roles and the applicable law.

2. Meaning and scope of connected medical-device cybersecurity

Connected-device cybersecurity involves protecting three essential properties:

Confidentiality

Preventing unauthorized disclosure of patient records, diagnostic images, device telemetry, and treatment information.

Integrity

Ensuring that medical readings, dosage instructions, device configurations, and clinical data are not improperly altered.

Availability

Ensuring that authorized clinicians and patients can use essential device functions when medically necessary.

For example, ransomware affecting a hospital's imaging network may delay diagnosis even if the attacker never directly changes an MRI machine's software. Cybersecurity risk therefore extends beyond the individual device to the connected clinical system, its software dependencies, maintenance arrangements, and network infrastructure.

NCBI+1

3. Major cybersecurity standards and frameworks

The following standards and frameworks are particularly relevant. Their applicability depends on device classification, jurisdiction, product architecture, and the manufacturer's regulatory obligations.

The FDA specifically recognizes ANSI/AAMI SW96:2023 for medical-device security risk management.

Access Data+1

A critical distinction is that a standard is not automatically a law. A voluntary consensus standard may support regulatory compliance or become relevant through incorporation into a regulation, contractual obligation, or other legal requirement. Likewise, following a standard does not automatically establish that a device is safe or legally compliant.

4. Core cybersecurity requirements for connected medical devices

4.1 Secure-by-design architecture

Manufacturers should integrate cybersecurity into the design process rather than treating it as a problem to solve after the product has entered the market.

Important controls include:

Secure boot and cryptographic verification of firmware.

Strong authentication for clinicians, administrators, and service personnel.

Role-based access control and least-privilege permissions.

Encryption of sensitive data in transit and, where appropriate, at rest.

Protection against unauthorized changes to device settings.

Segmentation of device networks from general hospital networks.

Secure interfaces and restrictions on unnecessary ports and services.

For high-risk equipment, a security failure must be evaluated for its potential impact on essential clinical performance.

4.2 Vulnerability assessment and threat modelling

Manufacturers should systematically identify potential attack paths, vulnerable components, and clinical consequences.

A practical assessment should examine:

Threat sources, including malicious insiders, remote attackers, and compromised suppliers.

Vulnerable interfaces, wireless connections, remote maintenance tools, and software libraries.

Potential consequences, such as incorrect measurements, interrupted therapy, or unauthorized disclosure.

Security controls and alternative safeguards.

Residual risks and the evidence supporting acceptance of those risks.

The assessment should connect cybersecurity vulnerabilities to patient-safety hazards. A vulnerability that could stop an infusion pump deserves a different response from one affecting a nonessential administrative display.

4.3 Software Bill of Materials (SBOM)

An SBOM identifies software components incorporated into a device, including commercial, open-source, and other third-party components.

It assists manufacturers and healthcare organizations in determining whether a newly disclosed vulnerability affects their products.

For devices covered by section 524B of the US Federal Food, Drug, and Cosmetic Act, the manufacturer must provide an SBOM as part of the applicable premarket cybersecurity requirements. The law also requires plans for vulnerability monitoring and procedures for providing security updates and patches.

FDA+1

4.4 Patch management and software updates

Patch management is particularly important because medical devices may remain in clinical use for many years.

An effective programme should provide for:

Continuous monitoring of vulnerability disclosures.

Assessment of whether a vulnerability affects the device and its clinical environment.

Prioritisation according to exploitability and potential patient harm.

Authenticated, integrity-checked software updates.

Testing before deployment, including safety and compatibility testing.

Rollback or recovery procedures if an update fails.

Communication of known limitations and end-of-support dates.

Updates must not introduce new hazards or interrupt critical treatment without appropriate safeguards. If a device cannot safely be patched, compensating controls, clinical instructions, replacement, or other risk-reduction measures may be necessary.

The FDA's February 2026 guidance addresses cybersecurity throughout the product lifecycle, while section 524B establishes specific obligations for qualifying cyber devices.

FDA+2

4.5 Incident detection and response

Manufacturers and healthcare providers should maintain procedures to detect, investigate, contain, and recover from cybersecurity incidents.

An incident-response plan should specify:

Who is responsible for technical containment and clinical decisions.

How affected devices can be isolated without unnecessarily interrupting care.

How logs, forensic evidence, and device configurations will be preserved.

When clinicians, patients, regulators, and other affected parties must be notified.

How devices will be restored and verified before returning to clinical use.

How lessons from the incident will be incorporated into future risk assessments.

In India, the applicable CERT-In directions under section 70B of the Information Technology Act, 2000, may impose incident-reporting, log-retention, and related requirements on covered entities. The precise applicability and deadlines must be assessed against the directions and relevant FAQs.

Directions70B+1

5. United States legal framework

5.1 Federal Food, Drug, and Cosmetic Act

The principal US statutory provision specifically addressing medical-device cybersecurity is section 524B, Ensuring Cybersecurity of Devices, added by the Consolidated Appropriations Act, 2023.

It applies to a defined category of devices called cyber devices. The statutory definition includes devices that contain qualifying software, can connect to the internet, and have technological characteristics that could be vulnerable to cybersecurity threats.

For applicable premarket submissions, manufacturers must:

Submit a plan for monitoring, identifying, and addressing cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure procedures.

Design, develop, and maintain processes that provide reasonable assurance of cybersecurity.

Make postmarket updates and patches available to address vulnerabilities.

Provide a software bill of materials.

These requirements have applied to qualifying submissions since March 29, 2023, subject to the statute's scope and transition provisions.

FDA+1

5.2 FDA regulatory guidance

The FDA's February 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, describes recommended approaches to cybersecurity design, testing, documentation, and lifecycle management.

It is important to distinguish the guidance's recommendations from enforceable statutory requirements. A manufacturer may need to comply with section 524B even though individual recommendations in the guidance are nonbinding.

Official source: FDA cybersecurity guidance, February 2026.

5.3 Product liability and negligence

Where a cybersecurity defect contributes to patient injury, possible legal claims may include:

Design defect: The device lacked reasonable safeguards against foreseeable attacks.

Manufacturing defect: A particular device was released with insecure or improperly configured software.

Failure to warn: The manufacturer failed to communicate material cybersecurity risks or necessary precautions.

Negligence: Reasonable security, testing, maintenance, or incident-response practices were not followed.

Breach of warranty: The device failed to meet applicable express or implied warranties.

Regulatory enforcement: The manufacturer failed to meet applicable statutory or regulatory requirements.

A cybersecurity weakness alone does not automatically establish civil liability. A claimant generally must establish the elements of the applicable cause of action, which may include duty, breach, causation, damages, and compliance with relevant procedural rules.

6. Indian legal framework

India regulates medical devices under the Drugs and Cosmetics Act, 1940, and the Medical Devices Rules, 2017. The Central Drugs Standard Control Organisation (CDSCO) administers the central regulatory framework. The Rules address matters such as licensing, safety, performance, quality management, and post-market oversight.

CDSCO+1

The main legal instruments relevant to connected-device cybersecurity include the following.

Official sources:

CDSCO: Medical Devices Rules, 2017.

CERT-In: cybersecurity directions.

Digital Personal Data Protection Act, 2023.

Important qualification: India does not have a single, comprehensive statutory cybersecurity standard specifically governing every connected medical device. Applicable obligations arise from the interaction of medical-device regulation, data-protection law, cyber-incident requirements, contracts, consumer law, and general liability principles. The commencement of individual DPDP Act provisions and any applicable rules must be checked for the relevant date and facts.

7. Important case laws and their legal significance

There is an important distinction between a judgment directly deciding a medical-device cybersecurity dispute and a judgment establishing a legal principle that could apply to such a dispute. The cases below are relevant analogies; they should not be described as all being cybersecurity-specific precedents.

7.1 United States cases

1. Riegel v. Medtronic, Inc.

552 U.S. 312 (2008) · US Supreme Court

Facts and issue: The case concerned injuries allegedly caused by a medical balloon catheter and the relationship between federal device regulation and state product-liability claims.

Decision: The Supreme Court held that certain state-law requirements concerning an FDA-approved Class III device were pre-empted by federal law where they imposed requirements different from or additional to federal requirements.

Cybersecurity significance: A claim alleging that a regulated medical device was defectively designed or inadequately secured may raise federal pre-emption issues. Whether a particular cybersecurity claim survives depends on the device's regulatory status, the claim's substance, and the relevant federal requirements.

2. Medtronic, Inc. v. Lohr

518 U.S. 470 (1996) · US Supreme Court

Facts and issue: The dispute involved alleged defects in a pacemaker and its leads, and whether federal medical-device regulation displaced state-law claims.

Decision: The Court held that the Medical Device Amendments did not pre-empt the particular claims at issue involving a device cleared through the then-applicable 510(k) process.

Cybersecurity significance: The regulatory pathway through which a connected device is marketed can influence the availability of state-law product-liability claims. The decision does not establish a cybersecurity-specific duty or guarantee that claims concerning every 510(k)-cleared device will proceed.

3. Stengel v. Medtronic Inc.

704 F.3d 1224 (9th Cir. 2013) (en banc)

Facts and issue: The case concerned alleged injuries associated with an implanted medical device and a manufacturer's alleged failure to report safety information to the FDA.

Decision: The Ninth Circuit allowed a failure-to-warn theory based on an alleged duty under Arizona law to warn the regulator to proceed, finding that it was not necessarily pre-empted.

Cybersecurity significance: Where a manufacturer discovers a serious vulnerability that creates a patient-safety risk, questions may arise concerning regulatory reporting and warnings. Whether an analogous claim is legally available depends on the applicable reporting duties and state law.

4. Wyeth v. Levine

555 U.S. 555 (2009) · US Supreme Court

Facts and issue: A patient suffered serious injury after a medication was administered using an unsafe method. The dispute concerned state failure-to-warn liability and federal regulation.

Decision: The Court rejected the particular pre-emption defence, finding that the manufacturer could have strengthened the warning under the applicable federal framework.

Cybersecurity significance: The case provides a broader analogy for analysing warnings and regulatory compliance. It is a pharmaceutical case, not a connected-medical-device cybersecurity judgment, and its holding cannot simply be transferred to devices.

7.2 Indian cases

5. Justice K.S. Puttaswamy (Retd.) v. Union of India

(2017) 10 SCC 1 · Supreme Court of India

Facts and issue: The case concerned whether privacy is protected as a fundamental right under the Indian Constitution.

Decision: The nine-judge Bench recognised privacy as a fundamental right under Article 21 and other relevant constitutional guarantees.

Cybersecurity significance: Connected medical devices can generate highly sensitive personal and health-related data. Unlawful collection, exposure, or misuse may engage privacy and data-protection principles. However, not every private-sector data breach automatically constitutes a constitutional violation; the defendant, legal duty, and applicable statutory framework matter.

6. Samira Kohli v. Dr. Prabha Manchanda

(2008) 2 SCC 1 · Supreme Court of India

Facts and issue: The case concerned medical treatment performed without the required informed consent for the procedure undertaken.

Decision: The Court explained the principles governing valid consent in medical treatment.

Cybersecurity significance: If a connected device's known security limitations materially affect treatment risks, the adequacy of patient information may become relevant to clinical consent and professional responsibilities. The case does not hold that every cybersecurity risk must independently be disclosed to every patient.

7. Spring Meadows Hospital v. Harjol Ahluwalia

(1998) 4 SCC 39 · Supreme Court of India

Facts and issue: The case arose from serious injury to a child associated with negligent medical care and considered liability under consumer law.

Decision: The Court addressed the liability of healthcare providers and the legal consequences of negligent medical services.

Cybersecurity significance: If inadequate hospital security practices allow a device compromise that foreseeably disrupts treatment, the hospital's conduct may be examined under applicable negligence and consumer-law principles. Liability would still require proof of the relevant legal elements and causation.

8. Jacob Mathew v. State of Punjab

(2005) 6 SCC 1 · Supreme Court of India

Facts and issue: The case considered the standards governing criminal liability for alleged medical negligence.

Decision: The Court discussed the distinction between civil negligence and the higher threshold applicable to criminal negligence by medical professionals.

Cybersecurity significance: A cyber incident involving clinical equipment does not automatically establish criminal negligence by a clinician, hospital administrator, or manufacturer. The relevant person's conduct, applicable legal duty, causation, and the required degree of fault must be assessed separately.

7.3 Regulatory enforcement example: cybersecurity affecting essential performance

A particularly useful real-world example is the FDA's October 2025 alert concerning the Automated Impella Controller manufactured by Abiomed.

The FDA described cybersecurity vulnerabilities that could affect essential performance, potentially leading to loss of device control or an unexpected pump stop, with potentially life-threatening consequences. The alert reported no associated cyberattacks or patient harm at that time.

FDA

This is a regulatory safety action, not a court judgment. Nevertheless, it illustrates why cybersecurity failures in medical devices must be assessed according to their clinical consequences rather than solely by whether personal data has been compromised.

8. Legal liability: who may be responsible?

Liability depends on the source of the failure, the relevant legal duty, and whether the failure caused harm.

These responsibilities can overlap. A manufacturer may provide a secure device that a hospital later configures insecurely; conversely, a hospital may follow the manufacturer's instructions yet remain exposed to a vulnerability that the manufacturer failed to address.

Courts should examine evidence such as security assessments, device logs, software versions, patch notices, maintenance records, contracts, and the causal relationship between the incident and the injury.

9. Practical compliance checklist

The following checklist can help manufacturers and hospitals organise a connected-device cybersecurity programme.

Compliance self-assessment

0 of 9

Governance and accountability

Assign responsibility for cybersecurity, safety decisions, vulnerability disclosure, and incident response.

Secure product design

Document authentication, encryption, access controls, secure boot, and network protections.

Risk and safety analysis

Link each significant vulnerability to potential clinical hazards and risk-reduction measures.

Software inventory

Maintain an SBOM and monitor relevant third-party software vulnerabilities.

Verification and validation

Conduct security testing, penetration testing where appropriate, and safety regression testing.

Updates and end-of-life

Define patch delivery, testing, recovery, support periods, and communication procedures.

Hospital deployment

Segment medical-device networks, restrict remote access, manage credentials, and monitor activity.

Incident reporting

Establish escalation, evidence preservation, regulatory reporting, and patient-safety procedures.

Documentation and audit

Retain risk assessments, test results, change records, corrective actions, and compliance evidence.

Reset checklistCopy checklist

This is an organisational checklist, not a certification or a determination of legal compliance. Requirements should be mapped to the device's intended use, risk class, market authorisations, and applicable laws.

10. Emerging legal issues

Several issues are likely to remain important as medical technology becomes increasingly interconnected:

Artificial intelligence and adaptive software: Who is responsible when a security compromise affects an AI-assisted diagnosis or changes the reliability of a clinical recommendation?

Legacy devices: How should hospitals manage equipment that remains clinically useful but no longer receives security updates?

Supply-chain liability: When does a vulnerability in an open-source library or third-party component create liability for the manufacturer?

Cybersecurity and patient consent: What information about material security risks should be provided to clinicians and patients?

Cross-border responsibility: Which country's law applies when a device is manufactured in one country, hosted in another, and used in a third?

Evidence and causation: How can parties prove that a cybersecurity vulnerability caused a particular medical injury when several technical and clinical factors contributed?

These questions require fact-specific analysis and may involve both established legal doctrines and evolving regulatory requirements.

11. Conclusion

Cybersecurity standards for connected medical devices sit at the intersection of medical-device safety, software engineering, data protection, product liability, and healthcare regulation.

The most defensible compliance approach combines secure-by-design development, documented risk management, an accurate software inventory, tested patch procedures, post-market monitoring, and coordinated incident response. In India, these practices should be assessed against the Medical Devices Rules, applicable IT and data-protection laws, and general liability principles. In the United States, section 524B and the FDA's current guidance are particularly important.

The case laws discussed above provide relevant principles concerning pre-emption, warnings, privacy, informed consent, and negligence; they should not be mistaken for a settled body of cybersecurity-specific medical-device precedent.

For a more targeted legal analysis, the next useful step would be a jurisdiction-specific case-law study of connected medical-device cybersecurity in India, including statutory provisions, relevant judgments, and manufacturer liability.