A Look at the New NIST Guidelines for Healthcare-at-Home Devices

Recently, I have been developing smart home devices in my free time to gain more experience with different data communication protocols, and because they are an area of IoT that I find especially worthwhile to explore. I like that the sole purpose of a smart home is to make daily life easier; to make a home feel more...well...homey. One area of smart home development that I am particularly interested in is Healthcare-at-Home (HaH) devices. These are healthcare products that integrate with a smart home to improve, sustain, and monitor a person’s health. For instance, there has been recent research into devices that can predict heart attacks simply by being present in a room. Imagine if such a device were connected to your smart home and could immediately alert your doctor if it detected a potential event.

There are also more everyday uses for this technology. In theory, a diabetic could connect their glucometer to a smart home system and receive alerts when their blood sugar drops. A pill bottle could automatically request a refill when it begins to run empty. HaH devices are quickly becoming a realistic part of the future of healthcare. I recently had the opportunity to speak with several healthcare professionals about how they use technology in their practices, and they all emphasized the same point: technology is the future of at-home care.

What the NIST Guidelines Cover

The U.S. National Institute of Standards and Technology just recently published guidelines for Mitigating Cybersecurity and Privacy Risks in Telehealth Smart Home Integration. I read them, and learned a little more about what smart home healthcare device development requires.

First, they provide a theoretical high-level architecture for an example HaH device.

From the NIST Cybersecurity White Paper

There are four domains:

1. The Patient’s Home

2. The Voice Assistant Platform (like Siri, Alexa, etc.)

3. Healthcare integration Solution (points the voice assistant to the healthcare provider, consider it a middleman)

4. Healthcare Delivery Organizer (hospitals, clinics, etc.)

Key Security Risks

Term: I will use the term “bad actor” to mean “someone with no business knowing a patient’s personal information”

There are five main risks addressed by the guidelines:

1. Data exfiltration

   A Bad Actor accesses to a patient’s data by intercepting unencrypted communications.

2. Data manipulation

   A Bad Actor changes your health data by catching it and changing it somewhere along the line.

3. Denial of service

   A Bad Actor (or careless user) sends the Voice Assistant Platform or the Healthcare Integration Solution too much information too fast, and it stops working. This can also be done on accident by a confused user.

4. Operating system or application disruption

   A Bad Actor changes the voice commands a patient sent or alters the code in the Healthcare Integration Solution, making it give the wrong results.

5. Unauthorized access

   A Bad Actor gains too much access to the patient’s HaH without their permission.

Now looking back at the original reference architecture, we can visualize the locations that are particularly susceptible to these risks.

From the NIST Cybersecurity White Paper

Recommended Security Tactics

To ameliorate these risks, they recommend paying special attention to six privacy security tactics:

1. Access control

   Reduce the number of people who can access these systems by implementing passwords and multifactor authentication requirements. This fulfills the NIST’s property of least privilege.

2. Authentication

   At every step of data access a system should authenticate themselves to ensure only the right people have access to a patient’s data. This is also considered a Zero Trust concept.

3. Continuous monitoring

   A system should monitor network traffic for unusual patterns or spikes/dips in traffic. This will reduce the probability of a DDoS attack. The goal is for a system to work as predicted, and it should notify someone otherwise.

4. Data security

   All data should be encrypted when it is in transit and when it is being stored. That way if someone does get a hold on a patient’s data, it cannot be read.

5. Governance

   Keep a record of everyone who has access to a patients data and account information. That way if there are any issues, there is detailed information on who has access.

6. Network segmentation

   In a patient’s home, an HaH device should be distinct from their personally owned IoT devices. Since by HaH device is prescriptive by definition, it should not be used for non-medical purposes, or be associated with devices or accounts that are non-prescriptive.

From the NIST Cybersecurity White Paper

Security as Software Architecture

This paper finishes by reminding healthcare providers that their responsibility to security extends beyond the provided guidelines. Any HaH program should exist in harmony with their organization’s current cybersecurity strategy and exist within the context of their challenges. They will still need to educate patients on data safety practices, safeguard their health records, and encourage patients’ autonomy in their healthcare.

I thought this paper was a really good read, especially as someone learning about good software architecture practices. Even in school, we only briefly cover these topics; this is the first time I’ve seen an example of how cybersecurity can be considered at an architectural level.

If you have any interesting insights, please feel free to reach out!

Citation

Pulivarti R, Littlefield K, Patrick B, Wang S, Williams R (2025) Mitigating Cybersecurity and Privacy Risks in Telehealth Smart Home Integration (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper (CSWP) NIST CSWP 34. https://doi.org/10.6028/NIST.CSWP.34