Sign up for the QMED & MD+DI Daily newsletter.
A Guide for Cybersecurity Regulations for Medical Device Manufacturers
A look at how to navigate the ever-changing landscape of cybersecurity.
+1
11 Min Read
Image Credit: Urupong via iStock/Getty Images
The landscape of cybersecurity is always changing, which means for medical device manufacturers in the highly-regulated life sciences industry, so, too, are expectations from regulators. By understanding the new requirements of FDA and the U.S. Securities and Exchange Commission (SEC) and by learning how governance, risk, and compliance (GRC) technologies can improve, streamline, and mature an overall cybersecurity program in alignment with the latest guidance, medical device manufacturers and life sciences organizations can better protect their devices, networks, data, and patients.
FDA requirements
The Consolidated Appropriations Act, 2023[AA1] contains changes to the Federal Food, Drug, and Cosmetic Act [AA2] [AA3] that grant additional power to FDA to enforce requirements for cybersecurity in medical devices. Specifically, Section 3305, “Ensuring Cybersecurity of Medical Devices,” outlines four broad requirements for medical device manufacturers bringing cyber devices to market with premarket submission, including a 510(k), premarket approval application, product development protocol, and de novo or humanitarian device exemption. Medical device manufacturers must comply with four requirements:
Submit a plan for vulnerability identification, management, and disclosure
Provide reasonable assurances that devices are cyber secure when they go to market by integrating security into the design, development, and maintenance of devices, including implementing a patch management plan to distribute scheduled and as-needed device updates
Submit a software bill of materials (SBOM) containing all software components
Comply with other requirements to provide a reasonable assurance of cybersecurity
Organizations should ask to whom and to what types of devices these rules apply. The new requirements apply only to cyber devices, which according to FDA are devices that:
Include software
Can connect to the internet
Contain characteristics that could be vulnerable to cybersecurity threats
The first and third criteria must be true for software and characteristics validated, installed, or authorized by the manufacturer. While the criteria seem straightforward, several cases are ambiguous, including, for example, devices that connect to the internet indirectly through a Bluetooth connection to an internet-connected device. Therefore, the FDA is currently open to assisting manufacturers in determining if devices they are bringing to market meet the criteria to be considered cyber devices.
Specific medical device cybersecurity requirements vary based on the type of FDA submission and the properties of the device, such as the use of off-the-shelf software. However, requirements from the most recent premarket [HG4] and postmarket [HG5] FDA guidance apply to most cyber devices and are part of an FDA-recommended Secure Product Development Framework used to build sustainable systems and proactively identify, prioritize, and remediate risks. These requirements include:
Comprehensive system diagrams (security architecture views)
Threat modeling
Cybersecurity risk assessment
Security requirements testing, including penetration testing
SBOMs
Component support information
Vulnerability assessment
Unresolved anomaly assessment
Instructions for secure configuration and use
Plan for vulnerability identification, tracking, disclosure, and patching
In general, any documentation created through such activities should cross-reference related activities wherever possible. For example, vulnerabilities exploited during the penetration assessment should correspond to risks identified in the cybersecurity risk assessment, an entry in a vulnerability tracking solution, and controls identified in the system diagrams. In addition, identification, testing, and assessment activities should be performed throughout the total product life cycle so that the product is designed with security in mind and documentation is continually supported.
FDA provides additional details regarding each of these requirements in its premarket and post-market guidance. Plans for patching devices on the market should account for known changes in third-party support for software dependencies, such as the 2027 end-of-life date for the widely used SAP Business Suite 7. Additionally, FDA strongly recommends incorporating third-party data through participation in an industry-specific Information Sharing and Analysis Organization or by using tools such as X-Analytics that aggregate third-party data to inform cyber economic decision-making or the process of making choices about budgeting for and spending on cybersecurity.
In addition to risk identification, prioritization, and remediation activities, FDA provides recommendations for more granular cybersecurity design recommendations for eight security control categories: authentication; authorization; cryptography; code, data, and execution integrity; confidentiality; event detection and logging; resiliency and recovery; and updatability and patchability.
While maintaining compliance with the new and existing FDA requirements is a major undertaking, the following strategies can be helpful for many medical device manufacturers.
Design for security at every stage. Consider how security can be incorporated at each phase of FDA’s Total Product Life Cycle approach, especially early on, and document security-conscious activities. During the design process, try to identify critical components of devices most susceptible to cyberattacks and consider design modifications or built-in controls to address them, such as using strong encryption, integrity, and authentication controls when transmitting data between devices.
Maintain detailed documentation and diagrams. Build and maintain detailed system diagrams for hardware and software that are critical to many FDA requirements from the start of a project, such as threat modeling, SBOM creation, end-user documentation, among others.
Perform continual testing and vulnerability identification. Conduct regular security-specific testing, such as cybersecurity risk assessments and penetration tests, throughout the life cycle of the product and incorporate the results into documentation. Perform penetration tests during the build process, before submission, and regularly after a device has been brought to market. Document and address each finding associated with the penetration assessment to keep all documentation current.
Plan for future vulnerabilities and patching. Anticipate that vulnerabilities will be identified after a device goes to market. Maintain a plan for monitoring for new vulnerabilities, addressing issues quickly, deploying patches, and disclosing vulnerabilities to end users.
A proactive mindset of designing for security from the early stages, maintaining thorough and up-to-date system documentation, and continual testing and monitoring for vulnerabilities goes a long way toward securing medical devices and maintaining compliance with FDA regulations.
SEC requirements
As the cybersecurity landscape continues to evolve, organizations should anticipate widening enforcement from governing agencies. The SEC is no exception. The SEC staff initially issued its views on cybersecurity disclosure in 2011. The Commission followed with guidance[SM6] in 2018 and then issued new disclosure rules in July 2023 [AA7] with required reporting starting Dec. 18, 2023, for many registrants. The new requirements [SM8] focus on reporting an organization’s cybersecurity governance practices and timely reporting of material cybersecurity incidents.
Organizations that need to comply include all public companies that are subject to the reporting requirements of the Securities Exchange Act of 1934[RJ9] , other than asset-backed issuers. It is essential for these organizations to implement a thorough cybersecurity governance program that includes established incident response and reporting plans that align with the SEC’s expectations. The following actions represent a practical approach to accomplishing the new requirements:
Evaluate materiality. Determining whether an incident is material might be the most challenging aspect of the new rules. The SEC notes[SM10] that “information is material if ‘there is a substantial likelihood that a reasonable shareholder would consider it important’ in making an investment decision, or if it would have ‘significantly altered the “total mix” of information made available.’ ‘Doubts as to the critical nature’ of the relevant information should be ‘resolved in favor of those the statute is designed to protect,’ namely investors.”
Timely report any material incident. The new Item 1.05 of Form 8-K states that an organization must describe the nature, scope, and timing of an incident, as well as its associated material impact or reasonably likely material impact, within four business days of determining an incident, is material. To that end, organizations should confirm that incident response procedures and processes, including disclosure controls and procedures, are aligned to support the reporting timeline, and they should thoroughly document the event to perform the materiality assessment and provide adequate details needed to support Form 8-K.
Align with industry-standard frameworks. In the new guidance, Regulation S-K Item 106 (b)(1) requires reporting in the annual Form 10-K that describes how the organization has implemented “processes, if any, for assessing, identifying, and managing material risks from cybersecurity threats in sufficient detail for a reasonable investor to understand those processes.” That is, organizations must provide sufficient detail about how they have implemented their cyber risk management strategy and how they govern, from management to the board.
Practice, practice, practice. A well-defined IRP supports compliance and regulatory requirements, but an IRP that is not activated or practiced could prove useless when needed. For this reason, organizations should perform incident response simulations and tabletop exercises to ensure the program steps are accurate and to activate the muscle memory of those with incident response roles. When performing these activities, it is imperative that organizations perform tabletop exercises with a technical focus and with business leaders across the enterprise.
Given this definition, an organization should take a risk-based approach to determine how it intends to evaluate materiality, which likely will involve evaluation of incidents on a case-by-case basis. The framework or steps an organization should establish could consist of:
As part of the overall strategy of an incident response program (IRP), organizations should track and document all incidents, regardless of materiality, because the SEC requires reporting when a company determines it has been materially affected by a series of related incidents (such as the same threat actor, victim, asset, or vulnerability). To that end, it’s imperative to use technology to support incident tracking and the associated long list of details for each incident.
To transparently provide this information while not exposing details about the security environment, organizations can align to industry-accepted frameworks such as those defined by the National Institute of Standards and Technology Cybersecurity Framework 800-53, 800-171, and 800-181; the Center for Internet Security Critical Security Controls; ISO 2700-01/02; or a combination of multiple framework or compliance requirements orchestrated with a common control framework such as the Unified Compliance Framework or the Secure Controls Framework. By aligning to one or more industry frameworks, organizations can more easily fulfill this reporting requirement given the reliance on the authoritative sources of those frameworks.
A three-pronged approach can more effectively test technical controls, the technical response, and the business response the organization has implemented. The first prong is engaging with a qualified outside party to perform a ransomware simulation or a red team exercise to allow technical teams to test detection and response controls as well as the technical responses to a perceived threat. The second prong is performing traditional tabletop exercises in which IS and IT leaders gather (physically or virtually) to talk through the steps to take during a security event. The third prong includes tabletop exercises with leaders that support other areas of the organization (business lines, human resources, risk management, legal, and privacy officers) to further test established plans and how departments would coordinate responding to, operating in, and recovering from various security events with each other.
GRC technologies
Effectively managing risk across an enterprise while staying abreast of evolving compliance requirements can be a daunting task. GRC technologies, if appropriately configured and implemented, can help organizations track and monitor risk, support maturity of the security program, and act as a single source of truth for emerging regulations and compliance requirements.
In years past, organizations might have seen GRC platforms as too expensive, too complex, and unusable. Recently, however, many GRC technology companies have expanded platform capacity and performed an overhaul of their user interfaces. When configured appropriately with the business needs in mind and normalized with end users, these technologies can help mature a cybersecurity program. Three ways in which GRC technologies can help fulfill requirements from the FDA and SEC include:
Compliance integration. GRC technologies can use application programming interfaces (APIs) and low-code solutions to automate the generation of new or changing compliance and regulation standards directly into a solution. Subscribing to services or feeds and then using built-in APIs or engaging an outside party to develop low-code solutions can help organizations stay current with established and emerging regulations.
Efficient incident response. Enterprise GRC platforms provide an opportunity to elevate an IRP. If the GRC platform has been integrated with other technology in the organization or additional modules have been configured directly within, the IRP can be actionable and accurate given its reliance on the configuration management database, business impact analysis, business continuity plan, and overall plan response. GRC platforms can also help directly develop and execute tabletop simulation exercises and associated after-action reports.
Performance monitoring and reporting. GRC technologies provide real-time monitoring capabilities that can allow organizations to track key risk indicators (KRIs), given the risk register is up to date. The ability to produce real-time reports that include KRIs as well as key performance indicators helps organizations make more informed decisions while also providing the appropriate visibility to the board and outside entities as necessary.
Supporting compliance through technology
New regulations from FDA and SEC likely will encourage medical device manufacturers to increase transparency and improve their cybersecurity posture. GRC technologies can help streamline processes by providing a real-time picture of regulatory requirements, enterprise risks, and remediation efforts as well as help mature an organization’s cybersecurity program.
About the Author(s)
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
