Setting the standard for healthcare cybersecurity

We meet and go beyond the cybersecurity guidance provided by the FDA. See how we map our offerings to the FDA premarket cybersecurity guidance (Draft, April 2022).

Quality system inclusive of cybersecurity

FDA Guidance:

Section IV.A, Line 120
“Device manufacturers must establish and follow quality systems to help ensure that their products consistently meet applicable requirements and specifications.”
Section IV.A, Line 125
“In order to demonstrate a reasonable assurance of safety and effectiveness for certain devices with cybersecurity risks, documentation outputs related to requirements of the QSR may be one source."
Section IV.A, Line 134
“As part of QSR design controls, a manufacturer must “establish and maintain procedures for validating the devices design,” which “shall include software validation and risk analysis, where appropriate.”

Medcrypt solution

Demonstrate authenticity, including integrity, in device design

FDA Guidance:

Section IV.B, Line 166
“FDA will assess the adequacy of the device’s security based on the device’s ability to provide and implement the security objectives below throughout the system architecture.
Security Objectives
- Authenticity, which includes integrity
- Authorization
- Availability
- Confidentiality
- Secure and timely updatability and patchability."

Medcrypt solution

Medcrypt's cryptography solution can be used to manage an organization-specific private key that only your organization has access to.

Medcrypt Guardian can be used to sign firmware and software, which can be verified on the device before a firmware update, or as an application or configuration is loaded.

Device designed with failure mode for system consideration

FDA Guidance:

Section IV.B, Line 188
“Because exploitation of known vulnerabilities or weak cybersecurity controls should be considered reasonably foreseeable failure modes for systems, these factors should be addressed in the device design.”
Section IV.D, Line 232
“As cybersecurity is part of device safety and effectiveness, cybersecurity controls should take into consideration the intended and actual use environment."

Medcrypt Solution

Using Medcrypt Guardian, device configurations can be signed, and verified on application start. Should this configuration be changed, a desired failure mode (error message, warning, alert, etc.) can be specified by the device manufacturer.

Transparency

FDA Guidance:

Section IV.C, Line 197
“...it is important for device users to have access to information pertaining to the device’s cybersecurity controls, potential risks, and other relevant information.”
Section IV.C, Line 219
“Device cybersecurity design and documentation is expected to scale with the cybersecurity risk of that device.”
Section V.A.2, Line 424
“The device manufacturer is also expected to provide to users whatever information is necessary to allow users to manage risks associated with the device."

Medcrypt solution

Helm, Medcrypt's vulnerability management solution, enables management of a system's software bill of materials, including determining when vulnerabilities are relevant.

Medcrypt has developed a Cybersecurity Quality Fabric (CQ) that provides an easy-to-follow template and model implementation of a Secure Product Development Framework (SPDF), enabling medical device manufacturers to demonstrate compliance with evolving security regulations as well as ultimately produce safer devices.

Medcrypt solutions are accompanied by documentation to support FDA documentation and QMS requirements.

Security risk management

FDA Guidance:

Section V.A, Line 328
“FDA recommends that manufacturers establish a security risk management process that encompasses design controls (21 CFR 820.30), validation of production processes (21 CFR 330 820.70), and corrective and preventive actions (21 CFR 820.100) to ensure both safety and security risks are adequately addressed.”
Section V.A, Line 332
“FDA recommends that device manufacturers conduct both a safety risk assessment per ISO 14971:2019 and a separate, accompanying security risk assessment to ensure a more comprehensive identification and management of patient safety risks.”
Section V.A, Line 347
“Risk transfer, if appropriate, should only occur when all relevant risk information is known, assessed, and appropriately communicated to users and includes risks inherited from the supply chain as well as how risk transfer will be handled when the device/system reaches end of support and end of life and whether or how the user is able to take on that role (e.g., if the user may be a patient).”
Section V.A,2,(b),4 Line 517
“The security risk management report should:
-summarize the risk evaluation methods and processes, detail the security risk assessment, and detail the risk mitigation activities undertaken as part of a manufacturer’s risk management processes;
-provide traceability between the security risks, controls and the testing reports that ensure the device is reasonably secure.”

Medcrypt solution

Medcrypt has devleoped a Cybersecurity Quality Fabric (CQ) that provides an easy-to-follow template and model implementation of a Secure Product Development Framework (SPDF), enabling medical device manufacturers to demonstrate compliance with evolving security regulations as well as ultimately produce more secure devcies.

Medcrypt offers threat modeling expertise and support as well as a full online training program that enables medical device engineers to learn about this useful security methodology and sharpen their skills in live labs.

Medcrypt's Ghost is is a solution that can be added to existing designs, enabling the mitigation of confidentiality or authenticity risks through easy-to-implement encryption and signing Helm, MedCrypt's vulnerability management solution, enables management of a system's software bill of materials, including determining when vulnerabilities are relevant.

Threat Modeling

FDA Guidance:

Section V.A.1, Line 367
“As part of the risk assessment, FDA recommends threat modeling be performed throughout the design process and be inclusive of all system elements.”
Section V.A.1, Line 370
"Threat model should:
- identify system risks and mitigations as well as inform the pre- and post-mitigation risks considered as part of the security risk assessment
- state any assumptions about the system or environment of use (e.g. hospital networks are inherently hostile, therefore manufacturers are recommended to assume that an adversary controls the network with the ability to alter, drop, and replay packets)
- capture cybersecurity risks introduced through the supply chain, manufacturing, deployment, interoperation with other devices, maintenance/update activities, and decommission activities that might otherwise be overlooked in a traditional safety risk assessment processes.”
Section V.A.1, Line 381
“FDA recommends that premarket submissions include threat modeling documentation to demonstrate how the risks assessed and controls implemented for the system address questions of safety and effectiveness.”

Medcrypt solution

Medcrypt has developed a Cybersecurity Quality Fabric (CQ) that provides an easy-to-follow template and model implementation of a Secure Product Development Framework (SPDF), enabling medical device manufacturers to demonstrate compliance with evolving security regulations as well as ultimately produce more secure devcies. Medcrypt offers threat modeling expertise and support as well as a full online training program that enables medical device engineers to learn about this useful security methodology and sharpen their skills in live labs.

Third party software component

FDA Guidance:

Section V.A.2, Line 406
“Device manufacturers are expected to document all software components of a device and to mitigate risks associated with these software components.”
Section V.A.2, Line 410
“...manufacturers must put in place processes and controls to ensure that their suppliers conform to the manufacturer’s requirements."
Section V.A.2, Line 423
“the manufacturer should include in premarket submissions a plan of how the third party software component could be updated or replaced should support for the software end."

Medcrypt solution

Medcrypt has developed a Cybersecurity Quality Fabric (CQ) that provides an easy-to-follow template and model implementation of a Secure Product Development Framework (SPDF), enabling medical device manufacturers to demonstrate compliance with evolving security regulations as well as ultimately produce more secure devices. Helm, Medcrypt's vulnerability management solution, enables management of a system's software bill of materials, including determining when vulnerabilities are relevant.

SOFTWARE BILL OF MATERIALS

FDA Guidance:

Section V.A.2,(a), Line 443
“...an SBOM or an equivalent capability should be maintained as part of the device’s configuration management, be regularly updated to reflect any changes to the software in marketed devices, and should support 21 CFR 820.30(j) (Design History File) and 820.181 (Design Master Record) documentation. "
Section V.A.2,(a), Line 443
“...for each OTS component, the following should also be provided in a machine-readable format in premarket submissions”
- A. The asset(s) where the software component resides;
- B. The software component name;
- C. The software component version;
- D. The software component manufacturer;
- E. The software level of support provided through monitoring and maintenance from the software component manufacturer;
- F. The software component’s end-of-support date; and
- G. Any known vulnerabilities.”
Section V.A.2,(a), Line 480
“...manufacturers should also describe how the known vulnerabilities (item (G) above) were discovered to demonstrate whether the assessment methods were sufficiently robust."
Section V.A.2,(a), Line 494
“For each of these anomalies, FDA recommends that device manufacturers conduct an assessment of the anomaly’s impact on safety and effectiveness, and consult the Premarket Software Guidance to assess the associated documentation recommended for inclusion in such device’s premarket submission. "

Medcrypt solution

Helm, Medcrypt's vulnerability management solution, enables management of a system's software bill of materials, including determining when vulnerabilities are relevant, over the lifetime of a device.

SECURITY ARCHITECTURE

FDA Guidance:

Section V.B, Line 600
“FDA recommends that these plans and procedures include design processes, design requirements, and acceptance criteria for the security architecture of the device such that they holistically address the cybersecurity considerations for the device and the system in which the device operates. ”
Section V.B.1, Line 646
“FDA recommends that these procedures include design requirements and acceptance criteria for the security features built into the device such that they holistically address the cybersecurity considerations for the device and the system in which the device operates. ”
Section V.B.1, Line 650
“FDA recommends that an adequate set of security controls will include, but not necessarily be limited to, controls from the following categories:
- Authentication;
- Authorization;
- Cryptography;
- Code, Data, and Execution Integrity;
- Confidentiality;
- Event Detection and Logging;
- Resiliency and Recovery; and
- Updatability and Patchability.”

Medcrypt solution

SECURITY ARCHITECTURE VIEWS

FDA Guidance:

Section V.B.2, Line 705
“FDA recommends manufacturers develop and maintain security architecture view documentation as a part of the process for the design, development and maintenance of the system... The number and extent of the architecture views provided in the submission will be dependent on the attack surface(s) identified through threat modeling and risk assessments for the device”
Section V.B.2, Line 712
“FDA recommends providing, at minimum, the following types of views in premarket submissions:
-Global System View;
-Multi-Patient Harm View;
-Updatability/Patchability View; and
- Security Use Case View(s).”

Medcrypt solution

CYBERSECURITY TESTING

FDA Guidance:

Section V.C, Line 817
“FDA recommends verification and validation include sufficient testing performed by the manufacturer on the cybersecurity of the system through which the manufacturer verifies and validates their inputs and outputs, as appropriate.”
Section V.C, Line 817
“FDA recommends the following types of testing, among others, be provided in the submissions
- A. Security requirements;
- B. Threat mitigation;
- C. Vulnerability testing;
- D. Penetration testing”
Section V.C, Line 886
“FDA recommends that cybersecurity testing should occur throughout the SPDF.”

Medcrypt solution

Vulnerability Management Plans

FDA Guidance:

Section VI. B, Line 1012
“FDA recommends that manufacturers establish a plan for how they will identify and communicate vulnerabilities that are identified after releasing the device with users...FDA recommends that manufacturers submit their vulnerability communication plans as part of their premarket submissions so that FDA can assess whether the manufacturer has sufficiently addressed how to maintain the safety and effectiveness of the device after marketing authorization is achieved.”
Section VI. B, Line 1022
“Vulnerability communication plans should include the following elements:
- A. Personnel responsible;
- B. Sources, methods, and frequency for monitoring and identifying vulnerabilities (e.g., researchers, NIST NVD, third-party software manufacturers, etc.);
- C. Periodic security testing to test identified vulnerability impact;
- D. Timeline to develop and release patches;
- E. Update processes;
- F. Patching capability (i.e., rate at which update can be delivered to devices);
- G. Description of their coordinated vulnerability disclosure process; and
- H. Description of how manufacturer intends to communicate forthcoming remediations, patches, and updates to customers”

Medcrypt solution

Medcrypt has developed a Cybersecurity Quality Fabric (CQ) that provides an easy-to-follow template and model implementation of a Secure Product Development Framework (SPDF), enabling medical device manufacturers to demonstrate compliance with evolving security regulations as well as ultimately produce more secure devices. Helm, Medcrypt's vulnerability management solution, enables management of a system's software bill of materials, including determining when vulnerabilities are relevant, over the lifetime of a device.

LABELING RECOMMENDATIONS

FDA Guidance:

Section VI.A, Line 913
“When drafting labeling for inclusion in a premarket submission, a manufacturer should consider all applicable labeling requirements and how informing users through labeling may be an effective way to manage cybersecurity risks and/or to ensure the safe and effective use of the device. Any risks transferred to the user should be detailed and considered for inclusion as tasks during usability testing (e.g., human factors testing) to ensure that the type of user has the capability to take appropriate actions to manage those risks.”

Medcrypt solution

Utilize a Secure Product Development Framework (SPDF) or similar

FDA Guidance:

Section IV.A, Line 153
“A Secure Product Development Framework (SPDF) is a set of processes that help reduce the number and severity of vulnerabilities in products. An SPDF encompasses all aspects of a product’s lifecycle, including development, release, support, and decommission.”
Section V, Line 266
“The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. From a security context, these are also trustworthy and resilient devices. These devices can then be managed (e.g., installed, configured, updated, review of device logs) through the device design and associated labeling by the device manufacturers and/or users (e.g., patients, health care facilities)."
Section V, Line 275
“FDA recommends that manufacturers use device design processes such as those described in the QSR to support secure product development and maintenance."
Section V.A,2,(b),5, Line 538
“As part of using an SPDF, manufacturers should update their security risk management report as new information becomes available, such as when new threats, vulnerabilities, assets, or adverse impacts are discovered during development and after the device is released"
Section V.A,2,(b),5, Line 545
“Over the service life of a device, FDA recommends that the risk management documentation account for any differences in the risk management for fielded devices (e.g., marketed devices or devices no longer marketed but still in use)."
Section V.A,2,(b),5, Line 556
“At a minimum, FDA recommends tracking the following measures and metrics:
-Percentage of identified vulnerabilities that are updated or patched (defect density).
-Time from vulnerability identification to when it is updated or patched.
-Time from when an update or patch is available to complete implementation in devices deployed in the field."

Medcrypt solution

Medcrypt has developed a Cybersecurity Quality Fabric (CQ) that provides an easy-to-follow template and model implementation of a Secure Product Development Framework (SPDF), enabling medical device manufacturers to demonstrate compliance with evolving security regulations as well as ultimately produce more secure devices.

Helm, Medcrypt's vulnerability management solution, enables management of a system's software bill of materials, including determining when vulnerabilities are relevant.

We live and breathe healthcare cybersecurity

A medical device may look like just another IoT device, but regulatory constraints and their unique use case require a healthcare-first approach to cybersecurity. MedCrypt's solutions are built specifically for medical devices, which means clinical functionality, patient safety, and care delivery are always the highest priority.