Managing Software Vulnerabilities: How to Utilize ISA/IEC 62443 and Software Bills of Materials

By Gabe Siftar, Matt Nowell
June 25, 2023


• Categories: 01-Digital Health, 04-Product Design & Development, 05-Quality/Regulatory, Compliance Management, Cybersecurity, RC - Device Design & Manufacturing

In recent years, more and more medical device manufacturers (MDMs) have come to rely on software bill of materials, or SBOMs. Some do this to help track licensing while others do so as part of a product vulnerability management process. In all cases, organizations who utilize SBOMs may have a leg up when it comes to the recently announced Refuse to Accept Policy (RTA) that was signed into law under section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act).

This new guidance was created in response to executive order 14028, Improving the Nation’s Cybersecurity. In short, the policy states that applications for medical devices filed after October 1, 2023, that qualify as cyber devices will be subject to a new process that gives the FDA the ability to issue RTA decisions based on cybersecurity-related elements of the submission filing. Although the act went into effect March 29, 2023, the FDA intends to work collaboratively with sponsors submitting before the October date rather than issue RTA decisions at this time.

Achieving Transparency with SBOMs

For the uninitiated, SBOMs are machine-readable inventories of software components akin to an ingredients list. Medical devices qualifying as cyber devices contain software that is typically built using components from third parties—referred to in ISA/IEC 62443 as “product suppliers”—in addition to custom code. SBOMs enable the tracking of attributes such as component source, version, and the relationships between those components.

Among the changes made to the current draft of the FDA’s “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” include security risk management recommendations that fall under the concept of a secure product development framework (SPDF). These updates are dependent on the consumption, creation, maintenance, and distribution of SBOMs. In the spirit of collaborative, efficient, and accurate exchange of SBOM data, the adoption of standards-based, machine-readable formats such as OWASP’s CycloneDX or The Linux Foundation’s SPDX, is a great place to start.

Including an SBOM as part of the device submission is important, but the exchange of SBOMs and associated vulnerability details should be facilitated with both product suppliers and asset owners. Doing so will help manufacturers meet the FDA’s labeling recommendations intended to give users the information needed to safely operate the devices throughout the product’s lifetime. This promotes an ongoing process of vulnerability identification and coordinated management through the product lifecycle and makes it a shared responsibility between product suppliers and asset owners.

Using ISA/IEC 62443 for Guidance

The FDA’s new recommendations clearly call for a supply chain vulnerability management process and the capability to ingest, generate, maintain, and distribute SBOMs. They do not, however, offer prescriptive advice as to how this can be accomplished.

Organizations that don’t yet have SBOM capabilities might wonder where to turn for guidance. The ISA/IEC 62443 series of standards, which define requirements, processes, and best practices for designing, implementing, and maintaining secure systems, is a great place to start. Although initially targeting industrial automation and control systems (IACS), these standards have since been adopted in diverse industry sectors including medical devices. In fact the FDA considers ISA 62443 parts 1-1, 2-1, 3-1, and 4-1 as recognized consensus standards.

The ISA/IEC 62443 series of standards enable the production and consumption of SBOMs at various points in the supply chain, starting with the product supplier (e.g., software component supplier), then manufacturers (e.g. medical device manufacturer) and finally by the asset owner (e.g. healthcare delivery organization). Notable examples include:

• Part 2-1: Security program requirements helps the asset owner establish and maintain the organizational capabilities required to securely operate a device over its lifecycle. This includes recommending that end users implement risk management practices that incorporate supply chain security. Adoptions of SBOMs can provide a valuable input to this process, enabling ongoing identification of vulnerabilities as well as the assessment of patches. Ideally this process can be automated with the right combination of tooling, standards based SBOMs, and the willing participation of upstream suppliers.
• Part 4-1: Product security development life-cycle requirements targets the product’s development team. Among other practices, it requires device developers to consider cybersecurity controls as a design input. Ideally this will be practiced recursively throughout the supply chain to provide end-to-end transparency.

Adoption of both SBOMs and the ISA/IEC 62443 series of standards can help ensure that medical devices not only breeze through FDA’s premarket submission process but also can be operated safely and securely by end users throughout their service life.

To learn more about ISA/IEC 62443, visit the ISA Global Cybersecurity Alliance website.