Published in


Cryptography is Critical to Digital Health and Interoperability

Trust is a prerequisite for the interoperability of medical devices. Cryptography is the key to implementing trust. Healthcare needs purpose-built cryptography and certificate management, especially for medical devices.

By Shannon Lantzy, MedCrypt Vice President of Consulting and Mike Kijewski, MedCrypt CEO.

Recent headlines have called for improving the interoperability of medical devices to advance patient care. Interoperability requires that devices be able to share and understand data between them, as well as give and accept commands to operate digital devices (e.g., deliver a drug infusion, run a diagnostic). To do that, the devices must (1) speak the same language and (2) trust each other. Cryptography, through the use of digital certificates, is the current best practice for establishing and maintaining trust between digital devices. However, common cryptography and certificate management solutions are usually built for enterprise and the traditional browser/web server use cases. Medical devices need cryptography and digital certificates built specifically for the clinical use case.

Why interoperability?

Hospitals are overwhelmed with devices. Many connect to a central electronic health record. While there has been a lot of progress (e.g., HL7, FHIR), the data are not yet sufficiently harmonized in a way that can be easily aggregated to form a coherent patient profile. Surgical suites are filled with digital devices involved with patient care, from surgical robots to patient monitors. Hospitals average about 10–15 medical devices per bed; of those, an estimated 25–40% are already or will soon be network-connected. Interoperability would help harmonize the data from the array of medical devices, streamline clinical workflows, reduce alarm fatigue from multiple overlapping systems, and help hospitals provide personalized patient care using all available sources of information.

Interoperability doesn’t stop at the four walls of a hospital. Increasingly wearable consumer devices are going home with patients, which also require secure interoperability. For example people who rely on insulin pumps and continuous glucose monitors (e.g., people with type 1 diabetes) have limited technology choices because they have to buy one company’s complete system. (Standards are on their way, but not yet mature and widely adopted.) The exceptions are loopers, who create DIY systems with the goal of increasing their quality of life.

Why now?

It used to be that MedTech companies built products that were not designed to securely communicate with products outside of their control. Now, customers like hospitals and people with type 1 diabetes demand interoperability. Furthermore, companies are starting to need interoperability within their own products, as they begin to unbundle systems to compete across the marketplace. FDA recently approved an algorithm specifically aimed at paving the way for interoperable diabetes devices.

How do we establish trust?

Interoperability in insulin delivery means that an insulin pump acts on a dosing message from a controller that received a message from a glucose monitor. For these communications to be trusted, the pump, controller, and monitor all have to be able to identify each other. Digital certificates are the current standard practice for establishing trust between systems. However, current certificate standards are built for traditional web use cases, (e.g., a browser connecting to a web server). Standard certificates are often too large and require too much resource-intensive processing for the small chips in embedded medical devices, like an insulin pump. Furthermore, established best practices for digital certificates include refusing connection if a certificate has expired, and expiring certificates in one year. Generally, this can not be reliably attained in a clinical use case because devices may not be connected frequently enough to ensure that devices can receive updated certificates in time.

How do we keep the messages private?

Security supports the goal of trust between devices as well as integrity and confidentiality of data exchanged. Digital certificates can be used to sign and encrypt. In hospitals, computed tomography (CT) scanners will often send imaging data unencrypted to picture archiving and communication systems (PACS). In the past, this was acceptable, as hospitals built firewalls to create secure trusted enclaves of medical devices and data. Now, hospital networks are considered hostile, and all data should be encrypted. This is easier said than done; for a CT scanner to securely communicate with a PACS according to best practices, they would need to exchange digital certificates. Technically, CTs and PACS today can support “Secure DICOM.” But with current architectures, the onus is on the users (i.e. hospitals) to install certificates on each system. Based on our conversations with near a dozen companies involved in medical imaging, not a single company has cited a customer using “Secure DICOM.” Imaging has interoperability, but not secure interoperability.

Similarly, a glucose monitor, controller, and insulin pump from different manufacturers all need to be able to exchange certificates to “speak the same encrypted language” (in addition to verifying each others’ identity). Devices as small as glucose monitors and insulin pumps are usually built with low-power hardware, in which significant tradeoffs are made between battery life and software complexity. Some manufacturers may decide that traditional cryptography is not supportable on their hardware, which forces any interoperability between their device and a partner to rely on less secure protocols. The need for any diabetes device manufacturer to support a single less-secure protocol may actually compromise the security of that entire system.

What is needed for trust and identity in an interoperable medical device landscape?

Most cryptography currently being employed in medical devices was built for the internet and e-commerce use cases, where the browser needs only identify that it’s talking to the real Amazon. What happens when the server needs to identify the medical device? Or when the data needs to be stored for a long time, and its validity repeatedly verified? Should a medical device stop receiving updates when its certificate expires? No! Healthcare needs cryptography architectures that:

  1. Preserve clinical functionality
  2. Anticipate intermittent connectivity
  3. Anticipate multiple vendors needing to work together to ensure interoperability
  4. Consider the hardware and functional limitations of a broad range of devices

Browsers and e-commerce companies have addressed the need for interoperability by nominating a few “root certificate authorities.” If they trust you, then I trust you. But since the underlying use case and technology needs of IoMT devices are different from browsers, we may need different, unique organizations that can validate a device’s identity, even if it was made by a different manufacturer. Manufacturers aren’t using cryptography and certificate management this way, yet.

Patient safety requires security

Healthcare needs fit-for-purpose cybersecurity solutions. Security needs to be proactive (as opposed to reactive). We believe this is the only viable path for medical device security. Digital certificates, cryptography, and key management are at the core of these principles.

We are working with companies that represent the vanguard of medical device interoperability, including working through the stumbling blocks that go along with being pioneers. For MDMs building devices of the future, capable of trusting and securing communications with other devices, here are three simple recommendations based on what we see in the industry:

  1. Don’t assume your company’s established certificate authority will work for your device. The corporate solution for laptop and enterprise security was probably built without optimizing for certificate size, scalability (i.e., how much will it cost to provision tens of thousands of devices), or interoperability outside the enterprise. IT-centric certificates and hierarchies will not match the unique medical device use case (e.g., available device resources, certificate lifecycle, or handling of failures).
  2. Requirements stemming from product marketing and strategy can unintentionally result in unnecessarily weak or complex cryptography architecture. . For example, requirements for backwards compatibility can cause security architects to make shortcuts in design. Furthermore, sometimes those requirements disappear over time (i.e., compatibility was required in 2018, but isn’t required any longer due to changes in product strategy) We recommend designing for the forward-looking, ideal use case, and then examining the tradeoffs necessary to achieve backwards-compatibility. This leads to better-informed design decisions.
  3. Write it all down. Document your architecture, decisions, and tradeoffs so that you can communicate it to partners, updated as old cryptography algorithms become deprecated, and the architecture can live beyond the individuals who designed it.


The healthcare industry will move toward its own purpose-built, certificate-based cryptography architectures to achieve trust and identification between devices. We are excited and encouraged by the developments in standards and security over the last decade, but there will be many bumps on the road to true interoperability. We are committed to building the future of healthcare on a foundation of trust.

Want to talk medical device cryptography? View our cybersecurity solutions and contact us any time at to get started.




Proactive Healthcare Security in a Few Lines of Code

Recommended from Medium

How To Improve Your KYC Experience: Stop Treating Your Customers like Criminals

Join the AMA session with @CryptoTitans1 and John Chen; @UmbNetwork Head of Marketing, and get…

Ethical hacking

Why is it Important to Choose a PCI DSS Certified Contact Center?

Everything You Need to Know About the Upcoming Cyber Car Presale

2022: The Most Popular Types of DeFi Hacks

ThunderSwap smart contracts audit report

Raccoon Malware Compromises in the Philippines Part 1

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


More from Medium

Why do we need the online safety bill?

Working on the World’s To-Do List

The next big goal for sport? Environmental sustainability.

Climate Change And Cybersecurity Among Top Global Risks