Devices and systems should be designed to protect assets and functionality in order to reduce the risk of multi-patient harm due to the loss of authenticity, availability, integrity, and confidentiality. Specifically, protection mechanisms should prevent all unauthorized use (through all interfaces); ensure code, data, and execution integrity (subversion of system functionality/safety/security features); and as appropriate, protect confidentiality of data (insofar as its release could be leveraged to effect multi-patient harm. As a part of premarket submissions, manufacturers should submit documentation demonstrating how these design expectations are met.

Prevent Unauthorized Use‍

Authentication is used to prevent unauthorized access to device functions and to prevent unauthorized software execution. Authorization enforces privileges associated with authentication credentials and/or roles to reject all disallowed behavior.
The following outline provides recommended design implementations of authentication, authorization, and encryption:

• Limit access to trusted users and devices only
  -    Limit access to device through the authentication of users (e.g. user ID and password, smartcard, biometric)
  -    Use automatic timed methods to terminate sessions within the system where appropriate for the use environment.
  -    Employ a layered authorization model by differentiating privileges based on the user role (e.g. caregiver, patient, health care provider, system administrator) or device functions.
  -    Use appropriate authentication (e.g., multi-factor authentication to permit privileged device access to system administrators, service technicians, maintenance personnel).
  -    Strengthen password protection. Do not use credentials that are hard coded, default, easily-guessed, easily compromised (i.e. passwords which are the same for each device; unchangeable; can persist as default; difficult to change; and vulnerable to public disclosure). Limit public access to passwords used for privileged device access.
  -    Consider physical locks on devices and their communication ports to minimize tampering.
• Authenticate and check authorization of safety-critical commands
  -    Use authentication to prevent unauthorized access to device functions and to prevent unauthorized (arbitrary) software execution.
  -    Require user authentication before permitting software or firmware updates, including those affecting the operating system, applications, and anti-malware.
  -    Use cryptographically strong authentication resident on the device to authenticate personnel, messages, commands and as applicable, all other communication pathways.
  -    Authenticate all external connections. For example, if a device connects to an offsite server, then it and the server should mutually authenticate, even if the connection is initiated over one or more existing trusted channels.
  -    Authenticate firmware and software. Verify authentication tags (e.g., signatures, message authentication codes (MACs)) of software/firmware content, version numbers, and other metadata. The version numbers intended to be installed should themselves be signed/have MACs. Devices should be electronically identifiable (e.g., model number, serial number) to authorized users.
  -    Perform authorization checks based on authentication credentials or other irrefutable evidence. For example, a medical device programmer should have elevated privileges that are granted based on cryptographic authentication or a signal of intent that cannot physically be produced by another device, e.g., a home monitor, with a software-based attack.
  -    Devices should be designed to “deny by default,” i.e., that which is not expressly permitted by a device is denied by default. For example, the device should generally reject all unauthorized connections (e.g., incoming TCP, USB,Bluetooth, serial connections).
  -    The principle of least privilege should be applied to allow only the level of access necessary to perform a function.

Ensure Trusted Content by Maintaining Code, Data, and Execution Integrity

• Code integrity
  -    Only allow installation of cryptographically verified firmware/software updates. Use cryptographically signed updates to help prevent unauthorized reduction in the level of protection (downgrade or rollback attacks) by ensuring that the new update is more recent than the currently installed version.
  -    Where feasible, ensure that the integrity of software is validated prior to execution, e.g., ‘whitelisting’ based on digital signatures.
• Data integrity
  -    Verify the integrity of all incoming data (ensuring it is not modified in transit or at rest, and it is well-formed/compliant with the expected protocol/specification).
  -    Ensure capability of secure data transfer to and from the device, and when appropriate, use methods for encryption and authentication of the end points with which data is being transferred.
  -    Protect the integrity of data necessary to ensure the safety and essential performance of the device.
  -    Use current NIST recommended standards for cryptography or equivalent-strength cryptographic protection for communications channels.
  -    Use unique per device cryptographically secure communication keys to prevent leveraging the knowledge of one key to access a multitude of devices.

Maintain Confidentiality of Data

Manufacturers should ensure the confidentiality of any/all data whose disclosure could lead to patient harm (e.g., through use of credentials, encryption). Loss of confidentiality of credentials could be used by a threat to effect multi-patient harm. Lack of encryption to protect sensitive information "at rest" and “in transit” can expose this information to misuse that can lead to patient harm.

‍