Harbor Labs was engaged by a non-US manufacturer of a wearable insulin pump to help resolve a series of disqualifying issues in their 510(k) submission. The manufacturer had already submitted their package to the FDA for review, but had been rejected due to several deficiencies related to their cybersecurity content and test reports.

As a foreign manufacturer unfamiliar with the nuances of the FDA cybersecurity review process, and despite feedback from the reviewer on the deficiencies in their submission, the client was still uncertain how best to remedy these deficiencies in a way that would meet regulatory approval. Moreover, the client was facing schedule pressures and it was imperative that their submission package be redone immediately.

Harbor Labs began the engagement with an extensive gap analysis, reviewing the client’s documentation to identify misordered or mislabeled content, and to note any required content that was absent. Upon completion of the gap assessment, Harbor Labs produced a checklist of tasks to be completed prior to resubmission, including a revised risk assessment and threat model, the production of new architectural views, and a new set of penetration and vulnerability testing. Harbor Labs was engaged to perform a complete overhaul of the submission, reproducing the entirety of all required content.

The client submitted their revised package to the FDA and received 510(k) clearance and authorization to sell in the US market almost immediately.

Harbor Labs partnered with a medical device manufacturer preparing for a 510(k) premarket submission. In executing its cybersecurity risk management process, Harbor Labs identified two critical security gaps the manufacturer had to address before submission. The identified gaps included the use of third-party networking components that the manufacturer could not control or influence beyond applying security best practices to configuration and firmware management, and a lack of secure boot and firmware update security controls.

Third-Party Networking Components

To address third-party device trust and supply chain risk, Harbor Labs assessed each networking component individually with administrative access to the device’s configuration utility. Using this access, Harbor Labs was able to:

1. Obtain firmware version information for a software composition analysis (CVE lookup).
2. Document third-party component names and version strings in a CycloneDx SBOM, providing automated vulnerability lookup.
3. Cross-validate each component against a public CVE database.
4. Investigate third-party device manufacturer support and software update and patch practices.
5. Manually audit the device as it was configured by the medical device manufacturer and intended for deployment.
6. Run network analysis and fingerprinting tools to ensure the device’s configuration is correct and enforced.

Harbor Labs then helped the manufacturer create cybersecurity labeling regarding the above in its Instructions for Use (IFUs), outlining safe configuration and maintenance of the third-party components.

Secure Boot and Firmware Update

Harbor Labs designed a PKI-based digital signature protocol that used NIST-approved algorithms to achieve firmware and firmware update authentication. To accomplish its design, Harbor Labs:

1. Verified that the manufacturer’s selected microcontroller supported the required cryptographic engine and SHA-256 hashing to validate firmware signature.
2. Configured secure boot logic to validate ECDSA signatures using a key pair generated via an open-source crypto library, wolfSSL, ensuring compatibility.
3. Recommended the root private key be stored in a tamper-evident Hardware Security Module (HSM) with multi-party control using Shamir’s secret sharing.
4. Recommended the firmware signing key be managed via a Key Management Service (KMS).
5. Implemented a robust firmware update process requiring that update packages be digitally signed, version-checked, and cryptographically verified before installation.

These controls ensured rollback prevention, boot-time verification, and certificate revocation.

Harbor Labs provided practical solutions to help the manufacturer meet FDA cybersecurity guidelines. Their guidance allowed the manufacturer to continue using third-party components without sacrificing transparency or control and to establish a secure, flexible firmware lifecycle. The result was a more resilient product and a smoother path toward regulatory approval and customer trust.

Harbor Labs was engaged by an industry leading manufacturer of automated external defibrillators (AED) to help resolve a security issue that was impeding both regulatory approvals and corporate business objectives.

The AED in question was the subject of an academic research paper, published several years prior, that analyzed the manufacturer’s deployment model and the methods used to update device firmware post-market. The authors of this paper highlighted several security flaws in the manufacturer’s model that would have made it susceptible to eavesdropping and a man-in-the-middle attack.

When brought to the attention of FDA regulators, the CDRH/Office of Device Evaluation deemed the reported vulnerabilities severe enough to warrant a hold letter. At the time the hold was issued, the client had nearly 500,000 devices in market, restricting their ability to update their fielded systems or to sell and deploy new units. Despite several attempts by the client to redesign the patch model to meet FDA approval, the lead FDA examiner continued to identify vulnerabilities in their designs that disqualified them.

At this point, Harbor Labs was brought in to assess the client’s patch model and to assist in the Q-Submission process. Harbor Labs engineers reviewed the client’s cloud distribution network, key generation and management processes, and signing policies, and compared them against common FDA regulatory criteria.

After identifying the flaws in the system, Harbor Labs redesigned the client’s architecture and processes, and provided engineering consulting to assist in its implementation. The final architecture featured a secure signing PC with a read-only disk image connected to a pre-provisioned HSM for local digital signing of the firmware. SAML-based authentication was integrated with the client’s Microsoft Active Directory to control access for authorized firmware uploads. A cloud-based AWS distribution network with a serverless architecture implementing a RESTful-API was used to apply an outer digital signature to the firmware package and distribute the update to authenticated, authorized AEDs. Harbor Labs developed a Python module that exposed a class-based interface for integrating the RESTful API into the client’s tooling and internal software. After implementing this design, Harbor Labs performed functional testing and wrote user documentation before handover to the client

The Harbor Labs design was submitted to the FDA via a Q-Submission. With every disqualifying characteristic of the client system now remediated and verified by Harbor Labs, the client was approved to resume commercial sales.

At Harbor Labs, one of our most common services is reviewing the cybersecurity content of the premarket submissions of Medical Device Manufacturers (MDMs).

When we provide this service, my team is brought in to perform a third-party review of the client’s cybersecurity processes, procedures, and overall product cybersecurity posture. This review will result in the production of a Cybersecurity Threat Assessment (CTA) — our process for creating a threat model, performing a cybersecurity risk assessment, mapping cybersecurity requirements, mitigating and compensating controls, and performing pen testing/cybersecurity testing.

In our many engagements performing this type of analysis, we have had a unique opportunity to see a broad variety of MDM submissions and the resulting FDA feedback. And in the process, we have noted a pattern of common pitfalls that cause MDMs to be delayed or disqualified from receiving regulatory approvals. In this blog post, I have compiled an outlined list of must do’s to avoid the common cybersecurity obstacles that hinder regulatory approval.

1. Threat Model

   • You must have a threat model.
   • The FDA outlines this requirement and advises how to perform it in the following resources:
     • Content of Premarket Submission for Management of Cybersecurity in Medical Devices
     • Playbook for Threat Modeling Medical Devices.
   • Threat model methodologies include:
     • STRIDE
     • Attack Trees
     • Kill Chain
     • DREAD
   • Your threat model must also include:
     • Assets
       • For example, assets include servers, end-user devices, smartphones, laptops, PCs, embedded systems, cloud services, virtual machines, etc.
     • Communication or data flows
       • For example, define the type of data, its sensitivity (e.g., PHI), and the assets that send and receive it.
     • Risk actors
       • For example, define insider threats such as rouge developers or cloud admins.
     • Threats
       • For example, an attacker with physical access to a medical device may connect to its JTAG interface.
     • Trust boundaries
       • For example, a medical device does not need to trust the network that it transmits data on.
     • You must create a threat model diagram.
       • Your threat model diagram must depict assets, communication flows, and trust boundaries.

2. Cybersecurity Risk Assessment

   • You must perform a risk assessment that considers cybersecurity vulnerabilities, defects, and exploits impacting patient safety.
   • You must also risk assess general cybersecurity risks that do not impact patient safety.
     • Confidentiality
     • Integrity
     • Availability
     • Privacy
   • You must create cybersecurity requirements, mitigation controls, and compensation controls.
     • Cybersecurity requirements prescribe how a device is secured.
       • For example, “All device network communication shall be secure.”
     • Mitigating and compensation controls implement the requirement to remove or reduce risk.
       • For example, “HTTPS using TLS 1.3 shall be used to ensure data is encrypted in transit.”
     • The FDA outlines this requirement and advises how to perform it in the following resources:
       • Content of Premarket Submission for Management of Cybersecurity in Medical Devices
       • The FDA also describes how to perform threat modeling in the Playbook for Threat Modeling Medical Devices.
     • The FDA recommends following and implementing risk assessment methodologies described in
       • NIST SP 800-30
       • IEC 62304
       • ISO 14971
       • Mitre’s Medical CVSS Rubric
     • You must include several types of cybersecurity risk assessment documentation, including, but not limited to:
       • Security Requirements Traceability Matrix
       • Device hazard analysis
       • Penetration Testing (see Cybersecurity Testing below)

3. Cybersecurity Testing

   • You must perform cybersecurity testing against your device and related systems.
     • Related systems refer to computers, servers, cloud platforms, and software services that communicate and, generally, integrate with your device. This concept is referred to as a system of systems.
     • Types of testing include:
       • Network enumeration
         • For example, identify computing devices reachable from a network. Perform port scans and OS fingerprinting.
         • Tools include:
           • Nmap
           • Testssl
       • Penetration Testing
         • For example, passively eavesdrop on network communication and actively insert, modify, drop, or jam network communication.
         • Tools include:
           • Nmap
           • Nessus
           • Metasploit
           • Burp Suite
           • Charles Proxy
           • Wireshark
           • Scapy
       • Static analysis
         • Software Component Analysis (SCA)
           • Tools include:
             • npm-audit
             • bundler
             • OWASP dependency-check
         • Static Application Security Testing (SAST) or Source Code Analysis Tools
           • Tools include:
             • SonarQube
             • Bandit
             • Brakeman
       • Dynamic Analysis
         • For example, perform input injection on running software.
           • Tools include:
             • Charles Proxy
             • MITM proxy
             • Burp Suite
             • ZAP
             • Scapy
       • DDoS and performance testing
         • Empirical analysis of network performance under artificial or malicious load
           • Throughput
           • Latency
           • Packet loss
           • Jitter
           • Tools include:
           • Hping
       • Fuzzing
         • Dynamic analysis technique to provide random, invalid, and unexpected inputs to a running software program or service
           • Example tools:
             • BooFuzz
             • AFL
             • Scapy
   • You must identify OTS software and SOUP incorporated in your device and related systems, and you must perform a vulnerability assessment of it.
   • You must create a Software Bill of Materials (SBOM).
     • You should determine software vulnerabilities using the NIST National Vulnerability Database.

4. Cybersecurity Monitoring

   • You must implement audit and logging capabilities in your devices and related systems.
     • Auditing and logging functionality include detecting, monitoring, logging, and alerting.
     • Depending on your architecture, for example, a cloud-based backend, you may use standard IDS, IPS, and SEIM solutions to meet the requirement.

5. Cybersecurity Plan

   • You must create a plan that describes your overall cybersecurity approach.
     • This approach must incorporate the threat model, cybersecurity risk assessment, and testing procedures above.
     • This approach must also include a process and procedures for:
       • Continuous software vulnerability analysis
       • Incident response to a vulnerability or compromise
       • Software patching and updating

6. Device Configuration and Deployment

   • You must set your device’s default configuration to the most robust security setting.
     • For example, a firewall may be enabled that blocks all ports except for those running services. Only TLS 1.3 is enabled. MFA is required to authenticate users accessing services external but integrated with the device, etc.
   • You must also clearly label and inform your device’s users on operating and configuring their device based on cybersecurity best practices.
     • For example, make it clear that disabling the firewall creates severe risks for your device. Allowing TLS 1.0 compromises the integrity and confidentiality of your network-based communication. Password-only authentication is susceptible to phishing and brute-force attacks, etc.
       • In many cases, you may forgo allowing your end-user to reduce security. In our experience, there is a lot of concern around this approach from MDMs.
     • The FDA outlines this requirement and advises how to perform it in the following resources:
       • Content of Premarket Submission for Management of Cybersecurity in Medical Devices

7. Cryptography, Risk Assessment, and Software Generally

   • Risk assess known vulnerabilities for OTS software and SOUPs and provide a rationale if you decide not to update immediately.
   • Use TLS 1.3 or TLS 1.2 with cipher suites that use authenticated encryption with associated data (AEAD) for bulk encryption.
     • See RFC 8446.
   • Digitally sign and verify software updates using FIPS 140-3 approved algorithms such as ECDSA.
     • See FIPS 140-3
     • See NIST SP 800-140C
   • Enforce access controls (authentication and authorization) server-side.
   • Risk assess cloud services regarding access control, security configuration (e.g., encryption at rest and transit), etc. Don’t assume that using a third-party cloud provider is good enough.
   • Enable encryption at rest wherever possible.
   • Apply and enforce the principle of least privilege.
   • Use hardware security modules and critical management services on the backend where
   • Do not hardcode any password, credential, secret, API key, etc.

To summarize, the MDM must create processes and procedures memorialized in the cybersecurity plan. As a part of that plan, you must describe your threat modeling, cybersecurity risk assessment, and cybersecurity testing process. Then, you must execute these processes when developing and assessing your device. Lastly, you must provide this information and the testing results in your formal submissions to the FDA, regardless of whether it’s a Pre-Sub, 510(k), or PMA.

Our advice–be clear, consistent, and concise when describing your cybersecurity. Perform testing and provide the results as evidence that support your position that your device and its related systems are secure.

It is an increasingly common practice in the medical device industry to integrate third-party smart devices such as phones and tablets into medical device architectures and operational models.

After examining several such systems, Harbor Labs has identified a broad set of unique cybersecurity risks in smart devices that may impact patient safety and privacy. To understand these risks, let us examine the design and function of a fictitious insulin delivery system called FakePump.

FakePump is a medical device that can read a patient’s blood glucose levels and in response, administer the appropriate insulin therapy. The patient wears the device at all times. FakePump has a Bluetooth Low Energy (BLE) wireless interface that can pair to the patient’s iPhone and send and receive data. The patient must install the FakePump iOS App on their iPhone to enable device communication.

Data sent from FakePump includes periodic blood glucose levels and events such as an insulin injection. Data received from the FakePump app contains commands such as inject N-units of insulin. The app forwards all received data to a content delivery network (CDN) managed by the device manufacturer called FakePump.io. The CDN stores patient data and exposes APIs for mobile and website applications to access and manipulate collected data.

A physician, caretaker, or patient may access this data via the application or CDN.

In the FakePump architecture, the iPhone is untrusted. The manufacturer has limited or no control over the smart device, while the patient has complete control. The manufacturer can minimally influence a patient’s iPhone’s hardware and software capabilities by setting a minimum iOS version supported by its iOS app. For example, the FakePump manufacturer may set the minimum iOS version to 11. This setting guarantees that Secure Enclave is available, and SFSafariViewController enforces cookie space separation between Safari and iOS apps. These features provide secure storage for the iOS app’s private crypto keys and restrict access to web-based access tokens.

However, this constitutes minimal control. A patient may jailbreak his or her device, thereby ignoring iOS app requirements. A jailbroken device may enable an attacker to access all app data previously subject to application sandboxing. More troubling, an attacker may access the FakePump iOS application binary and reverse engineer it.

These risks are inherent to any architecture that requires a smart device, including both iOS and Android devices. A reverse-engineered FakePump iOS app is a serious risk, as the effort would reveal all implementation and protocol-level app defects. These defects include hardcoded credentials, secrets, keys, improper or lack of input sanitization, rolling credential practices, insecure fallback mechanisms for data transmission, improper use of system libraries and functionality and outdated software dependencies with known vulnerabilities.

A reverse-engineering effort puts FakePump user safety at risk. It reveals details about the iOS app and the pump and CDN, such as tokens, passwords, keys and authentication methods. An attacker may use this to their advantage to spoof or tamper with data and commands.

Even when we assume the iPhone to be unmodified, cybersecurity risks related to software implementation are manifold. For instance, if the FakePump iOS app implements any of the following, it directly impacts patient safety and privacy:

The iOS app stores configuration data such as user credentials using UserDefaults.

• Sensitive data must never be stored using UserDefaults. Encryption is not enabled, and other applications may access the data even if application sandboxing is enabled (e.g., using app extensions).
• Instead, the Keychain Services API should be used to encrypt and store sensitive data.

The iOS app copies sensitive data, including PHI and PII, to the UIPasteboard (also called clipboard).

• Sensitive data must never be copied to the UIPasteboard because it is accessible to all iOS apps.

The iOS app does not protect against screenshots when PHI is displayed.

• Protecting against screenshots is a unique requirement that is only really been explored by apps like Snapchat. Currently, the iOS application can receive a notification when a user takes a screenshot. At a minimum, the iOS app should log the action.

The iOS app does not use Certificate Transparency (CT) when establishing TLS connections.

• Apple prescribes that all certificates issued after October 15, 2018, must meet its CT policy.

It should be noted that the cybersecurity risks presented in this paper were encountered in the course of Harbor Labs’ medical security analysis consulting, and were present in actual medical device architectures that included smart devices. Presenting these risks through a fictitious medical device is intended to illustrate the breadth of the patient safety and privacy issues that can be present in such architectures so that they may be avoided in future deployments.

This past week, I had the opportunity to brief policy analysts from the FDA on the growing Do-It-Yourself (DIY) trend in the global diabetes community.

The DIY movement combines the functionality of a smart device, an insulin pump, a continuous glucose monitor (CGM), and specialized open-source software and hardware allowing users to hack their systems and deliver a customized insulin therapy to treat their diabetes. My presentation focused on the research my staff and I have been conducting with these open-source software packages and the security vulnerabilities we have discovered.

My interest in this research stems from my academic and professional career in medical device security, as well as the fact that I am T2D insulin-resistant. I appreciate the perspective of the diabetes community and understand that their motivation in modifying these insulin delivery systems is based entirely on their desire to improve diabetes management, whether for themselves or the dependents they care for. However, as a medical security professional, I find the vulnerabilities in these DIY solutions and the fact that they have bypassed the regulatory security review process to pose a potential risk to patient safety.

Still, FDA policy must always take into account the medical needs and voices of the user community and balance that against the risks and regulatory purview of the agency. I was encouraged to find that while my audience shared my concern over the potential security risks being introduced through the DIY movement, they likewise shared my respect for the motivations of the DIY diabetics community and the importance of identifying the policies that would best accommodate the movement.

Harbor Labs has been asked to return to meet with additional policy staff, and I look forward to continuing this dialogue and helping to craft sound and responsible policies that serve the interests of all parties.