Read our Open Letter to the Healthcare Community Leaders, from the Security Research Community.

Leave a public pledge to uphold the Hippocratic Oath for Connected Medical Devices in the comments.

Download the PDF

Hippokratischer Eid für vernetzte medizintechnische Geräte

The latest medical advances lay at the intersection of patient care and connected technology. Integration of new technology enables innovations that improve patient outcomes, reduce cost of care delivery, and advance medical research. New technology also introduces new classes of accidents and adversaries that must be anticipated and addressed proactively. Remote malicious attackers, software flaws, and privacy concerns are the potential inadvertent side effects of transplanting connected technology into care delivery. The once distinct worlds of patient safety and cyber security have collided.

The Hippocratic Oath is a symbolic attestation by physicians to provide care in the best interest of patients. Medical devices are key instruments of delivering this care. It stands to reason that the design, development, production, deployment, use, and maintenance of medical devices should also follow this symbolic spirit. Our Hippocratic Oath for Connected Medical Devices describes commitments to capabilities that preserve patient safety, as well as trust in the process of care delivery itself.

On January 19th, 2016 I Am The Cavalry published an open letter to the Healthcare Stakeholder Communities. This letter urges stakeholders to:

  • Acknowledge that patient safety issues can be caused by cybersecurity issues;
  • Embrace security researchers as willing allies to preserve safety and trust;
  • Attest to these five foundational capabilities to improve visibility of their Cyber Safety programs;
  • Collaborate now to avert negative consequences in the future.

Hippocratic Oath for Connected Medical Devices

I will revere and protect human life, and act always for the benefit of my patients. I recognize that all systems fail; inherent defects and adverse conditions are inevitable. Capabilities meant to improve or save life, may also harm or end life. Where failure impacts patient safety, care delivery must be resilient against both indiscriminate accidents and intentional adversaries. Each of the roles in a diverse care delivery ecosystem shares a common responsibility: As one who seeks to preserve and improve life, I must first do no harm.

To that end, I swear to fulfill, to the best of my ability, these principles.

  1. Cyber Safety by Design: I respect domain expertise from those that came before. I will inform design with security lifecycle, adversarial resilience, and secure supply chain practices.
  2. Third-Party Collaboration: I acknowledge that vulnerabilities will persist, despite best efforts. I will invite disclosure of potential safety or security issues, reported in good faith.
  3. Evidence Capture: I foresee unexpected outcomes. I will facilitate evidence capture, preservation, and analysis to learn from safety investigations.
  4. Resilience and Containment: I recognize failures in components and in the environment are inevitable. I will safeguard critical elements of care delivery in adverse conditions, and maintain a safe state with clear indicators when failure is unavoidable.
  5. Cyber Safety Updates: I understand that cyber safety will always change. I will support prompt, agile, and secure updates.

⚕ Cyber Safety by Design

I respect domain expertise from those that came before. I will inform design with security lifecycle, adversarial resilience, and secure supply chain practices.

Safe outcomes are the product of systematic intent throughout the device lifecycle; they cannot be left to chance. Those whose lives and livelihoods depend on the reliability of the medical device should be able to evaluate for themselves the extent to which safety is assured – or neglected – in its design and development. Greater maturity and consistency in software design, development, testing, and maintenance leads to higher quality, and improved patient outcomes.

  • Cyber security standards based. Existing International and industry standards for secure design and development of software components are highly mature. Manufacturers who use these can accelerate the security of their software development, baselines, and processes. While there is no single consensus standard, common practices can help mature a program and lay the groundwork for adoption of a preferred standard or framework later.
  • Adversarial resilience analysis. All other things equal, a component and system that has been more rigorously tested has fewer unknown flaws or defects. Adversarial threat modeling, fault testing, and other cyber security practices build on safety engineering to consider failure and misuse caused by adversaries. Assessments should be carried out by qualified personnel, independent of design and development.
  • Avoid unmitigated remote access. Capabilities to save lives in the hands of qualified caregivers, can put life at risk when guided by accident or adversaries. Non-unique credentials (passwords, keys, etc.) and undisclosed access may allow untrusted commands, information, or individuals to influence treatment. Open, remote access may facilitate widescale harm from accidents and adversaries. Where such exposures must exist, mitigations must also exist to prevent harm.
  • Supply chain rigor. Well-governed, traceable hardware and software supply chains establish predictable quality and provenance of device components. A more trustworthy supply chain enables better resilience and a more agile response to accidents and adversaries. Off-the-shelf hardware and software, acquired with appropriate rigor, can increase reliability, reduce cost, and speed time to market compared to other alternatives.
  • Avoid known flaws. Avoid third-party software components with known vulnerabilities when less vulnerable alternatives are available and will not compromise required functionality. Consider providing a bill of materials for third-party software packages, including their versions, so stakeholders can make their own risk decisions, even beyond the expected lifetime of the device.
  • Shared responsibilities. The outcome of any course of treatment is a union of the device’s inherent capabilities, the care giver’s operation in its environment. The best care possible is achieved when the device and operator do what each is best poised to do. In the absence of clear statements of design assumptions and expectations for care delivery, the ability of care givers to replicate assumed environments and processes will be fortunate coincidence, rather than inherently systemic. Communicate expected deployment conditions, known failure conditions, operational requirements, design assumptions, architectural elements, reference implementation guidance, specific warnings or prohibitions, and other considerations.

⚕ Third-Party Collaboration

I acknowledge that vulnerabilities will persist, despite best efforts. I will invite disclosure of potential safety or security issues, reported in good faith.

Software flaws identified before they become safety issues give defenders an advantage. Manufacturers with the capability to receive and investigate flaws quickly increase this advantage. Those who encourage and act on reporting from independent sources can also reduce cost and exposure beyond what is possible with internal review alone. Value from researcher-manufacturer collaborations has led to manufacturers incentivizing research via recognition and reward programs.

  • Standards based. Published policies and programs in the software industry can serve as effective examples for medical device manufacturers. Use of vetted standards (such as those in the FDA Consensus Standards, including ISO 30111 and ISO 29147) and practices accelerate an organization’s maturity and ensure predictable, normalized interfaces to those who report issues.
  • Existing mechanisms. Use of existing processes and structures reduces time to develop an effective program, increases participation, and reduces administrative burden. Processes and policies already in place to accept and respond to reports of safety concerns – such as complaint handling – may also be used to handle reports of potential safety or security issues.
  • Known interfaces. External vulnerability reporting coordinators have normalized interfaces between manufacturers and third-party researchers. This brokers trust on all sides and reduces effort required.
  • Incentives focused. Patient safety should be in everyone’s best interest. Positive incentives, such as outreach, recognition, and financial incentives, drive earlier, higher quality reporting. This reduces cost, time, and negative perception to eliminate flaws, at the same time gives defenders an edge on adversaries by disrupting their ability to monetize attacks. Negative incentives deny these benefits to patients and to the healthcare ecosystem.

⚕ Evidence Capture

I foresee unexpected outcomes. I will facilitate evidence capture, preservation, and analysis to learn from safety investigations.

Safety investigations and records of device operations give visibility into unexpected outcomes. This evidence can plainly show the sources of error, be they malfunctions, design defects, human error or deliberate attack. Without evidence, causes of adverse events will be opaque and corrective actions will be speculative.

  • Independently reviewable. Independent reviews of device failure or safety reports allow stakeholders to investigate adverse events in a timely manner, to improve transparency of findings, and to support lines of accountability. Manufacturers should provide guidance to support investigations by healthcare facilities, specialized service providers, researchers, and agencies.
  • Tamper resistant, forensically sound evidence capture. Mechanisms should provide a legal standard of care for preserving logs and other information about the event, including tamper resistance, tamper evidence, and chain of custody.
  • Privacy sensitivity. The benefits of safety investigations are intrinsically linked to records that demonstrate the impact of failure. However, these benefits can be realized without creating privacy and surveillance concerns by decoupling security and integrity logs from patient records.
  • Reapplication of knowledge. Understanding causes of vulnerability, failure and harm are a precursor to addressing them, not the end in itself. Insights must inform all aspects of the medical device and patient care cycles. Share lessons learned with the broader healthcare community where it can improve the public good.

⚕ Resilience and Containment

I recognize failure in components and in the environment are inevitable. I will safeguard critical elements of care delivery in adverse conditions, and maintain a safe state with clear indicators when failure is unavoidable.

Medical devices deliver patient care through an interdependent system of systems. The strength this complexity brings should not put patients at undue risk of harm. Systems must operate safely independent of the operating states of other systems or components. Failures should be apparent, dependent inputs validated, and outputs protected.

  • Minimal elective exposure. Connectivity can provide critical capabilities to medical devices. It also increases exposure to hazardous conditions and adversaries. Exposure that does not meaningfully improve capabilities adds attack surface. (eg. NFC versus Bluetooth for changing treatments in implantable devices.) As such, more secure and lower cost designs seek to minimize these types of exposure.
  • Isolation and segmentation. Unexpected or hostile interactions between devices and their environment are more likely to lead to harm than well-understood interactions. A more secure design and implementation seeks to shield components and systems from adversaries or unexpected conditions.
  • Fail safe and visibly. Failure conditions should not cause undue harm to patients and should clearly indicate that the device is not operating normally. Unexpected modes of operation or known failures should trigger a “fail safe” or “safe mode” that can prevent a failure in one device or software component from spreading. Communicate indications and known conditions of failure to stakeholders.
  • Trusted input. Tamper resistant, tamper evident techniques safeguard against life-critical decisions or actions from untrustworthy information or instructions (ie. Drug libraries, HL7 codes, treatment plans, etc.), ideally with real-time feedback.
  • Patient record integrity. Decisions about patient care rely on accurate records of patient history and treatment. These records should be protected against tampering, manipulation, loss, and gaps. Capabilities such as ample storage, confirmation after transfer, integrity validation, and privacy protection allow informed patient care decisions.

⚕ Cyber Safety Updates

I understand that cyber safety will always change. I will support prompt, agile, and secure updates.

Once an issue is known that could affect patient care, a faster response improves care delivery. Software updates are faster and less expensive than hardware replacement; and automated, remote software updates are most efficient. Increases in exposure are compensated for by the speed and scale of addressing flaws or weaknesses that could lead to negative outcomes.

  • Automation and documentation. Update processes that are more automated and better controlled are less prone to error, delay, malice, misinterpretation, or other issues. Process documentation should outline clear roles and responsibilities for relevant stakeholders and allow development of corresponding processes inside stakeholder groups.
  • Secure update process. Processes should verify the authenticity and integrity of software updates to prevent adversarial, malicious, or accidental tampering. Remote update capability can give cost, reputational, and speed advantages if implemented in KNOWN good ways.
  • Stakeholder communication. Communication to stakeholders should be prompt, transparent, and forthright. Manufacturers should notify relevant stakeholders when and where flaws exist, their severity, contents of the update, and instructions for each role. Updates may be exclusively communication about workarounds, warnings, unsafe conditions, labeling, instructions for use, or other relevant information.
  • Support dependency security updates. Medical device safety depends on the integrity of third-party software dependencies. Patient safety must not be undermined by vulnerabilities in these platforms, nor in applying updates to fix them. Verification processes specific to off-the-shelf software security updates can enable a more agile response.

When the technology we depend on affects public safety and human life, it commands our utmost attention and diligence. Our medical devices command this level of care. These capabilities establish a foundation for cyber safety. Medical professionals are masters of your domain, cyber security researchers are masters of ours. Where our domains of expertise overlap, we can achieve safer outcomes sooner, together.

Medical device manufacturers, healthcare delivery organizations, physicians, patients, insurers, and other interested parties can get in touch with I Am The Cavalry at info [at] iamthecavalry.org


We urge healthcare stakeholders to adopt, develop, enhance, and promulgate these capabilities. Patients, care givers, and others have a right to inform themselves of potential consequences of treatment options. Manufacturers and others involved in the chain of care delivery may demonstrate their commitment to cyber safety by attesting to the way they fulfil this oath. We commit to help you diagnose and treat cyber safety issues to continue your ability to provide greater patient care benefits with fewer side effects.

We welcome public pledges in the comments. Whether you are a researcher, care giver, patient, or even a concerned citizen, you may commit to join us in collaborating toward our common goal to be safer, sooner, together.

16 Responses

  1. Beau Woods says:

    As an ambassador from the cyber security research community, I pledge to uphold this Hippocratic Oath for Connected Medical Devices.

  2. Florian Mösch says:

    As a software developer for Medical Devices, I pledge to uphold this Hippocratic Oath for Connected Medical Devices.

  3. Daniel Beard says:

    I pledge as a software engineer for medical devices to uplhold the Hippocratic Oath for Connected Medical Devices.

    I also pledge as VP of Promenade Software that we, as a company, will uphold this Oath to the best of our abilities in both software we create by ourselves and for our clients.

  4. Stephen Cobb says:

    As a cybersecurity and data privacy researcher, I pledge to uphold this Hippocratic Oath for Connected Medical Devices.

  5. Don Faulkner says:

    As a security and identity researcher, I pledge to uphold this Hippocratic Oath for Connected Medical Devices.

  6. As a physician who is interested in medical devices, I recognize that this oath for connected medical devices makes sense for protecting patients and promoting safety. I am happy to be the first physician on this website to pledge to uphold this Hippocratic Oath for Connected Medical Devices.

  7. As an interaction designer interested in online identity and intent on simplifying and unifying end-user control over the proliferating number of devices and services in our increasingly fragmented digital lives, I hereby pledge to uphold this Hippocratic Oath for Connected Medical Devices.

    (I also hereby wish that many more people discover this effort and sign this oath! Thank you for your efforts!!)

  8. Alain F. says:

    As a cybersecurity (soon-to-be) researcher, and concerned citizen, I pledge to uphold this Hippocratic Oath for Connected Medical Devices.

  9. As a Creative Director of 415Agency that collaborates with healthcare startups and always seeks new ways to create UX/UI environment where apps’ capabilities are united with users’ needs and operation safety, I hereby pledge that we, as a team, will uphold this Hippocratic Oath for Connected Medical Devices.

  10. erika says:

    As a nurse who is starting a company that stops wandering by alzheimers and autism sufferers, i pledge to uphold this oath.

  11. Georg Heidenreich says:

    Georg H, as a contributor to international ICT standards, I pledge to uphold this oath,

  12. Ben Ransford says:

    As a tool builder and medical device security researcher, I pledge to uphold this oath and also to spread the word about it.

  13. Darin the American says:

    As a healthcare administrator, I pledge to uphold this Hippocratic Oath for Connected Medical Devices.

  14. Bob Hone says:

    As a health game designer, I pledge to uphold this Hippocratic Oath.

  15. Koray Atalag says:

    As a health informatician and MD I pledge to uphold this Oath in addition to the original Hippocratic Oath I’ve upheld in the past

  16. James Gannon says:

    As a leader at a digital healthcare firm, I pledge to uphold this oath and share it far and wide.

Leave a Reply

Your email address will not be published. Required fields are marked *