Aligning Medical Device Architecture with NIST Cybersecurity Frameworks

A connected medical device is only as secure as the systems it depends on. From embedded software and wireless connections to cloud platforms and hospital networks, every component introduces potential vulnerabilities. A security breach could do more than expose sensitive information. It could disrupt patient monitoring, alter critical device settings, or interfere with treatment.

But how can manufacturers address these risks without compromising clinical performance?

The NIST medical device security approach draws on the NIST Cybersecurity Framework (CSF) 2.0, which helps manufacturers manage cybersecurity risks across connected medical devices, embedded systems, and supporting infrastructure.

Manufacturers can use this framework for connected infusion pumps, patient monitors, medical imaging systems, and medical software, depending on their cybersecurity risks. CSF 2.0 builds on CSF 1.1 by broadening its scope and introducing Govern as a separate function, placing greater emphasis on cybersecurity oversight and accountability.

How the Six NIST CSF 2.0 Functions Apply to Medical Device Architecture

NIST CSF 2.0 consists of six interconnected functions: Govern, Identify, Protect, Detect, Respond, and Recover. They operate together rather than as sequential stages, helping manufacturers organise security responsibilities, technical controls, and supporting evidence.

Although all six functions contribute to cybersecurity, their architectural roles differ. Govern concentrates on organisational decisions and accountability. The remaining functions inform product capabilities, engineering requirements, and operational processes.

How to Align Medical Device Architecture with NIST Cybersecurity Frameworks

Applying NIST guidance to medical device architecture requires a clear engineering process that connects clinical requirements with security decisions.

Step 1. Define the Medical Device's System Boundaries and Clinical Functions

Document the device's intended clinical use, operating conditions, authorised users, and functions essential to patient safety. For NIST cybersecurity medical device planning, this establishes the scope of the security assessment.

Examine the complete system, including:

Hardware: 

• Processors
• Sensors
• Actuators
• Memory
• Communication modules

Software: 

• Firmware
• Operating systems
• Libraries
• Clinical algorithms

Interfaces: 

• Ethernet
• USB
• WiFi
• Bluetooth and other communication channels

External systems: 

• Mobile applications
• Clinician dashboards
• Cloud services
• Hospital networks

Maintenance infrastructure: 

• Update mechanisms
• Remote access interfaces
• Manufacturer support systems

Develop an architecture diagram showing component connections, data flows, trust boundaries, and responsibility for manufacturer, hospital, and supplier systems. Identify clinical functions vulnerable to altered data, interrupted communication, or unauthorised commands.

Step 2. Establish SBOM and Component Supply Chain Governance

Once the system boundaries are defined, establish a Software Bill of Materials (SBOM) covering the device's software components and their dependencies. Include proprietary software, commercial packages, open source libraries, and Software of Unknown Provenance (SOUP), where applicable.

For each component, record:

• Identification: Component name, supplier, version, and relevant dependencies.
• Support status: Maintenance availability and known support limitations.
• Supplier responsibility: Ownership of security updates and vulnerability communication.
• Component governance: Approval requirements for introducing or replacing software dependencies.

NIST CSF 2.0 addresses supplier accountability and supply chain risk management through its Govern function, particularly category GV.SC. 

Section 524B of the FD&C Act also requires manufacturers of qualifying cyber devices to provide an SBOM covering commercial, open source, and off the shelf software components. 

Establish a process for maintaining the SBOM whenever software dependencies change. This gives manufacturers a reliable component record for subsequent security assessments.

Step 3. Select Relevant NIST CSF Outcomes and Identify Security Gaps

With the system scope established, select NIST CSF 2.0 categories and subcategories that match the device's cybersecurity risks, deployment conditions, and manufacturer responsibilities.

NIST uses Current and Target Profiles to assess organisational cybersecurity practices. Manufacturers can adapt this approach to individual products, although it does not constitute an official medical device certification.

Build the comparison in three stages:

1. Current Profile: Record existing capabilities, including credential management, firmware verification, network restrictions, security logging, and software update mechanisms.
2. Target Profile: Define the required security outcomes, such as individual device identities, limited administrative privileges, authenticated updates, and better detection of suspicious activity.
3. Gap assessment: Compare both profiles to identify missing controls, inadequate protections, and capabilities requiring improvement.

Document each gap against its relevant CSF subcategory, affected component, and proposed corrective action.

Step 4. Conduct Architecture Level Threat Modelling and Cybersecurity Risk Assessment

Threat modelling examines how attackers could exploit weaknesses in the device architecture and affect its intended operation. Start with identifying assets requiring protection, including clinical measurements, therapy settings, patient records, credentials, firmware, and configuration data.

Assess potential attack paths through network services, wireless connections, mobile applications, APIs, debug ports, removable media, and maintenance interfaces. Pay particular attention to trust boundaries where information or commands pass between independently controlled systems.

You can use the STRIDE methodology to examine six threat categories:

• Spoofing: Impersonating legitimate users or devices
• Tampering: Altering software, commands, or clinical data
• Repudiation: Disputing actions without adequate evidence
• Information disclosure: Accessing confidential information
• Denial of service: Disrupting access to device functions
• Elevation of privilege: Obtaining permissions beyond authorised access

For example, a compromised companion application could allow an attacker to modify therapy settings if the medical device fails to independently verify command authorisation.

Assess how cyberattacks could affect clinical functions and patient safety. Altered sensor readings may lead to incorrect treatment, while disrupted telemetry could delay critical care. Evaluate potential harm across multiple patients using the FDA's Multi Patient Harm View.

Manufacturers should consider these findings within their ISO 14971:2019 safety risk management activities, while keeping cybersecurity exploitability distinct from the probability of clinical harm.

Step 5. Map Cybersecurity Risks to Architectural Security Requirements

Once cybersecurity risks are assessed, translate significant threats into specific requirements for the affected device components. Each requirement should describe the expected security behaviour, the control needed to achieve it, and how engineers will verify its implementation.

For NIST healthcare cybersecurity, manufacturers can map relevant CSF 2.0 subcategories to technical requirements and supporting evidence. 

The following example shows how a firmware integrity requirement can be documented.

Requirements must also be precise enough to verify. Simply specifying "secure communications" is insufficient. Engineers should identify the communicating endpoints, authentication requirements, information requiring protection, approved protocols, and measurable acceptance criteria.

Maintain a traceability record connecting each applicable NIST subcategory to its technical requirement, implemented safeguard, verification result, and supporting documentation. This allows reviewers to determine whether identified risks have been addressed through the actual device design.

Step 6. Implement Security Controls Across Medical Device Components

Implementing security controls requires attention to how individual components behave under normal and abnormal conditions. A safeguard suitable for a hospital server might consume excessive memory or processing resources on an embedded device. The implementation must account for these differences.

1. Credential Provisioning and Access Enforcement

Determine how each device receives its initial credentials during manufacturing or commissioning. Avoid embedding identical secrets across an entire product line. Store sensitive credentials in protected hardware where supported, and establish procedures for replacing compromised credentials without requiring unnecessary device replacement.

2. Boot Process and Firmware Protection

Design the startup sequence so that software verification occurs before protected code executes. Engineers must decide where cryptographic verification keys reside and how the device handles failed integrity checks. Hardware write protection or restricted firmware access can provide additional protection where supported.

3. Cryptographic Key Management

Encryption alone does not address the full security of clinical information. Define how keys are generated, stored, renewed, and retired. Consider whether cryptographic operations occur within dedicated hardware or software, particularly when the device has limited computational resources.

4. Application and API Execution Boundaries

Separate processes according to their responsibilities. A cloud communication service should not automatically receive permission to modify clinical control functions. Enforce validation at the receiving interface and establish restrictions on the operations available to each software component.

5. Update Installation and Failure Handling

Use a controlled installation process that preserves a trusted software state where technically feasible. For devices supporting separate firmware partitions, an inactive partition can receive the new version before activation. Define what happens if power fails during installation and how incomplete changes are handled without compromising clinical safety.

6. Event Storage and Monitoring

Embedded devices often have limited storage capacity. Decide which events remain locally available and which can be transferred to a protected external logging system. Establish storage limits, timestamp handling, and procedures for preserving relevant records when connectivity is interrupted.

7. Operation During Infrastructure Failures

Some clinical functions depend on external services, while others can continue locally. Document the device's behaviour when a network connection disappears or a remote security service becomes unavailable. Any fallback operation must follow the device's safety requirements, with clearly defined restrictions and appropriate operator notifications.

Step 6. Secure External Communications and Third Party Integrations

Document every communication pathway connecting the medical device to hospital networks, clinician applications, cloud platforms, and vendor systems. Specify the endpoints, protocols, ports, and external services required for operation.

Apply security measures according to the risks associated with each connection:

• Endpoint authentication: Verify the identity of communicating systems using mutual authentication or another suitable mechanism
• Data transmission: Protect clinical information and commands through encrypted channels and integrity verification
• Network segmentation: Restrict communication to authorised network segments and necessary services
• API security: Validate incoming requests and enforce permissions for each external integration
• Remote maintenance: Restrict service access to approved personnel and permitted activities, with controlled session termination
• Third party dependencies: Assess the security practices, vulnerability management processes, and availability requirements of external providers

Manufacturers must document supported network configurations, required protocols, security dependencies, and deployment assumptions. Healthcare organisations are responsible for implementing the applicable protections within their managed environments.

Finally, assess how compromised external services or network interruptions affect clinical functions. Define which operations can continue locally and when the device must restrict external commands or notify operators.

Step 7. Verify the Architecture Through Cybersecurity Testing

Test the implemented architecture to determine whether its security controls perform as intended. NIST CSF 2.0 defines cybersecurity outcomes, while the FDA's medical device cybersecurity guidance recommends testing that demonstrates the effectiveness of security controls.

Select testing methods according to the device's exposed interfaces, identified threats, and technical characteristics.

• Static application security testing (SAST): Examine source code for insecure functions, coding weaknesses, and potential vulnerabilities
• Software composition analysis (SCA): Identify known vulnerabilities in external libraries and other software dependencies
• Penetration testing: Attempt to exploit weaknesses in applicable hardware interfaces, firmware, wireless connections, applications, APIs, and cloud environments
• Fuzz testing: Submit malformed or unexpected inputs to supported protocols and interfaces to identify parsing errors, crashes, and unsafe behaviour
• Access control testing: Attempt unauthorised operations to verify authentication, permission enforcement, and privilege separation
• Update and recovery testing: Check firmware acceptance and rejection behaviour, interrupted installations, and restoration procedures

A successful laboratory test alone is insufficient. Repeat relevant security assessments under representative clinical workflows and expected network conditions. Include failure scenarios where security mechanisms could affect device performance or availability.

Maintain evidence of the exact software versions and configurations tested. Reports should describe the methodology, findings, corrective actions, retesting results, and any unresolved risks.

Step 8. Document NIST Alignment and Prepare Regulatory Evidence

Organise cybersecurity documentation into a controlled evidence package that demonstrates how security decisions influenced the final device design. Each record should be traceable to the relevant product version and available for technical or regulatory review.

The evidence package should include:

Architecture records: 

• System diagrams
• Data flows
• Trust boundaries
• Attack surface representations

NIST mapping: 

• Applicable CSF outcomes
• Associated security requirements
• Implementation status

Risk documentation: 

• Threat models
• Cybersecurity risk assessments
• Unresolved vulnerabilities
• Residual risk decisions

Design evidence: 

• Security specifications
• Technical justifications
• Software bill of materials (SBOM)
• Third party component assessments

Verification records: 

• Security testing reports
• Identified weaknesses
• Corrective actions
• Retesting results

Operational procedures: 

• Software maintenance
• Vulnerability handling
• Incident response
• Recovery instructions

Maintain a central traceability matrix connecting identified threats to security requirements, affected components, implemented controls, and supporting test evidence. This helps reviewers examine the technical justification for each security decision without searching through disconnected records.

Keep documentation under formal version and change control. Any modifications to software, interfaces, or system architecture should trigger a review of affected security assessments and evidence.

Step 9. Maintain Architecture Security Throughout the Device Lifecycle

After release, monitor vulnerabilities, assess clinical consequences, and validate security patches. Reassess threats when integrations or deployment conditions change. Update risk records, coordinate vulnerability disclosure, and plan for unsupported components. 

Design maintenance capabilities early so future remediation protects patient safety without unnecessarily disrupting essential clinical operations.

NIST Frameworks and Standards Supporting Secure Medical Device Architecture

NIST CSF 2.0 defines cybersecurity outcomes but does not specify every engineering practice needed to achieve them. Manufacturers can use other NIST publications for more detailed technical guidance, alongside medical device standards addressing software development and patient safety.

The following resources serve different purposes within nist medical device security planning.

How Medysec Supports NIST Alignment and Medical Device Cybersecurity Readiness

Medysec helps medical device manufacturers strengthen product cybersecurity while preparing for regulatory compliance. Our services support FDA 510(k), EU MDR, EU IVDR, and CE Mark requirements, alongside cybersecurity assessments for connected medical devices and healthcare software.

Our FDA cybersecurity services cover premarket preparation, postmarket security, deficiency response, and SaMD cybersecurity. We assist manufacturers in addressing regulatory expectations and preparing the necessary technical documentation.

For manufacturers following NIST CSF 2.0, Medysec provides medical device penetration testing to identify vulnerabilities in device hardware, firmware, and communication interfaces. Our application and cloud penetration testing services examine security weaknesses in connected applications and supporting infrastructure.

These assessments help manufacturers evaluate security controls, address identified vulnerabilities, and maintain technical evidence relevant to their cybersecurity and compliance requirements.

Contact Medysec to discuss your device architecture, testing requirements, and regulatory documentation needs.

Is Your Medical Device Secure?

Check your medical device security risks and find the right steps to protect patient data and meet cybersecurity requirements.

Speak with Our Experts →

Conclusion

A medical device's security depends on decisions made throughout its design, development, and maintenance. NIST medical device security guidance helps manufacturers establish clear requirements based on system architecture, cybersecurity threats, and clinical risks. These requirements need practical safeguards and thorough testing to confirm their effectiveness. 

As vulnerabilities and technologies change, manufacturers must continue reviewing their security measures while protecting device functionality, clinical reliability, and patient safety.

FAQs

Is the NIST Cybersecurity Framework mandatory for medical device manufacturers?

No. NIST CSF adoption is generally voluntary. Manufacturers can choose to use it for cybersecurity risk management. However, applicable FDA requirements and other legal obligations remain mandatory regardless of whether a manufacturer adopts the framework.

Does NIST CSF 2.0 require zero trust architecture for medical devices?

NIST CSF 2.0 does not prescribe a particular security architecture. Manufacturers can apply zero trust principles, such as explicit identity verification and least privilege, where appropriate to support cybersecurity outcomes without implementing a complete zero trust architecture.

Can legacy medical devices align with NIST cybersecurity frameworks?

Yes. Older devices can be evaluated against relevant NIST outcomes, even when hardware limitations or unsupported firmware prevent certain upgrades. Manufacturers should assess feasible compensating controls, document remaining risks, and determine whether continued operation is acceptable.

What cybersecurity architecture documentation does the FDA expect?

The FDA recommends documentation covering system architecture, security controls, threat models, cybersecurity risk assessments, and verification results. The precise evidence needed depends on the device's characteristics, applicable regulatory requirements, and the type of submission being prepared.

How often should medical device architecture be reassessed for cybersecurity risks?

There is no universal reassessment interval prescribed by NIST CSF. Manufacturers should review security risks when vulnerabilities emerge, components change, or deployment conditions evolve. Continuous vulnerability monitoring and planned reviews help maintain security throughout the supported device lifecycle.