How Code Integrity Protects Medical Device Software
Post Summary
Code integrity ensures that medical device software remains secure, untampered, and reliable, safeguarding patient safety and trust. Here's what you need to know:
- Definition: Code integrity uses cryptographic methods like code signing to verify that software hasn’t been altered.
- Risks of Compromise:
- Faulty software can disrupt life-critical devices like pacemakers or insulin pumps.
- Financial losses from breaches average $15 million per incident.
- Regulatory fines, reputational damage, and legal liabilities add to the stakes.
- How It Works:
- Secure Boot: Ensures only authorized software runs on startup.
- Runtime Checks: Continuously monitors for tampering during operation.
- Code Signing: Verifies software updates using cryptographic signatures.
- Regulations:
- The FDA mandates continuous software validation and risk-based testing.
- Global standards like ISO and SBOM requirements enhance transparency.
- Challenges:
- Supply chain attacks have surged by 247% since 2024, highlighting critical healthcare supply chain security challenges.
- Manufacturers must address testing fraud and balance innovation with security.
- Best Practices:
- Use cybersecurity frameworks (e.g., NIST SP 800-218, IEC 62443).
- Conduct regular security assessments and maintain detailed SBOMs.
- Employ tools like Censinet RiskOps™ for centralized risk management.
Top 8 security controls you need in medical device software.
sbb-itb-535baee
How Code Integrity Mechanisms Work
How Code Integrity Mechanisms Protect Medical Device Software
Secure Boot and Firmware Verification
Secure boot is a hardware-backed feature designed to ensure that only authorized software runs when a medical device powers on. It achieves this by establishing a cryptographic root of trust directly on the processor. During startup, a chain of trust verifies the digital signatures of each boot component, allowing only authorized code to execute. If any unauthorized modifications or code are detected, the device either refuses to boot or switches to a safe mode.
"Secure boot is a cybersecurity standard that ensures devices boot using only software trusted by the device manufacturer." - Sudeep Khuraijam, Security Leader [3]
The FDA’s 2022 guidance on medical device cybersecurity highlights secure boot as a critical measure for maintaining device integrity [3]. To enhance security, the software used during the boot process is often stored directly within the processor. However, manufacturers must eliminate all "back door" access points - often included for development purposes - before the device is released. If left open, these debugging interfaces could serve as entry points for attackers. While securing the boot process is essential, devices also need mechanisms to ensure integrity throughout their operation.
Runtime Integrity Checks
After a secure startup, runtime integrity checks take over to maintain protection throughout the device’s operational life. These checks are designed to ensure the device remains secure by continuously monitoring its infrastructure for anomalies that could indicate breaches or unauthorized changes. This is particularly important for safeguarding electronic protected health information (ePHI) and preventing unauthorized alterations to the device's software while it is in use.
"Continuous monitoring and logging of update processes can provide valuable insights into the security posture of the device over time, allowing for proactive measures to be implemented as needed." - CyberMed [2]
Effective runtime monitoring works by establishing baselines of normal activity, making it easier to detect irregularities. Best practices include centralizing log collection through a security incident and event management (SIEM) system, implementing privileged access management (PAM) to limit administrative access, and automating session termination after periods of inactivity. The HIPAA Security Rule also mandates technical safeguards to protect ePHI from improper changes, which often involves deploying runtime monitoring tools.
Cryptographic Code Signing
To complement secure boot and runtime monitoring, cryptographic code signing provides a powerful way to verify software updates and prevent tampering. This process ensures that only legitimate and unaltered software updates can run on a medical device. Here’s how it works: the manufacturer creates a SHA-256 hash of the software, so even the smallest change alters the hash. The hash is then signed using the manufacturer’s private key from a digital certificate. When the device receives the update, it calculates its own hash of the software and uses the manufacturer’s public key to verify the signature. If the two hashes match, the update is confirmed as authentic and unaltered.
"Code signing is the modern-day equivalent of holographic tags in consumer goods. It gives the end-user confidence that they are using a legitimate product that will be backed by the vendor." - Keyfactor [1]
A 2024 report found that 97% of IoT devices have firmware vulnerabilities [6], underscoring the importance of code signing. Advanced techniques include using ECDSA (Elliptic Curve Digital Signature Algorithm) instead of RSA, as it provides stronger security with smaller key sizes - ideal for medical devices with limited resources. Additionally, storing private signing keys in a Hardware Security Module (HSM) rather than on standard servers adds another layer of protection. Best practices also recommend integrating code signing into the continuous integration (CI) pipeline and establishing key rotation policies to mitigate risks if a private signing key is compromised [5].
Regulatory Requirements for Code Integrity
FDA Guidelines for Software Validation
The FDA requires continuous software validation under the Quality System regulation (21 CFR 820), which has been in place since 1978 and expanded in 1997 to include design controls. Unlike a one-time task, validation is an ongoing process that spans the entire software lifecycle, including updates after the product hits the market. A key aspect of meeting FDA compliance is traceability analysis, which links each requirement to its corresponding design elements, code modules, and testing activities. This ensures the software performs as intended.
"The validation process does not end when the device is shipped." - Food and Drug Administration [7]
The FDA also insists on a risk-based approach to validation. This means the level of testing and code review should match the software's safety risks and complexity. When software is updated, manufacturers are expected to perform regression analysis to evaluate the impact of changes and conduct appropriate regression testing. Even for off-the-shelf (OTS) software, where source code might not be accessible, manufacturers must validate these components through audits or rigorous "black box" testing. These principles align with international standards to create a robust compliance framework.
ISO and IEC Standards for Medical Device Software
In addition to FDA regulations, international standards provide essential guidance for maintaining code integrity. For example, the International Medical Device Regulators Forum (IMDRF) introduced the N73 guidance in April 2023, highlighting key principles for Software Bill of Materials (SBOM) transparency [8]. Technical standards like the Unified Extensible Firmware Interface (UEFI) Secure Boot also play a significant role by ensuring that only authorized firmware and software - those with trusted digital signatures - can run on medical devices. Together, these standards complement FDA requirements, creating a more comprehensive regulatory landscape.
Software Bill of Materials (SBOM) Requirements
An SBOM is essentially a detailed inventory of all software components within a medical device. This level of transparency is critical for code integrity because it allows healthcare organizations to quickly identify affected devices when vulnerabilities are found in specific software components. Manufacturers must maintain an accurate SBOM, which includes tracking their own code as well as third-party libraries, open-source components, and commercial software integrated into the device. When a security vulnerability is announced in a widely used component, an up-to-date SBOM enables faster risk assessment and quicker remediation. This proactive transparency strengthens both security and code integrity.
Challenges in Maintaining Code Integrity
Cyberattack Threats
Medical device manufacturers are grappling with a sharp rise in supply chain attacks targeting code integrity. From 2024 through the first quarter of 2026, these attacks surged by 247% [9]. Attackers have shifted focus, moving from individual healthcare providers to directly targeting manufacturers. This shift stems from the realization that compromising a single manufacturer can ripple across thousands of healthcare facilities.
"Attackers have recognized that breaching a single medical device vendor provides access to hundreds or thousands of healthcare facilities. The economics are devastatingly efficient: one compromise, thousands of victims." - WhyNotDoc [9]
In early 2026, several firmware updates were compromised due to developer accounts lacking multi-factor authentication. One high-profile case involved infusion pumps used by 23 Texas medical practices, where malicious code - signed with legitimate certificates - went undetected for three weeks. This breach led to the theft of 34,000 patient records. Another breach affected 847 medical facilities nationwide, while a pro-Iranian hacker group targeted Stryker, exposing patient data and device credentials worldwide [9].
The core issue lies in the trust between healthcare facilities and technology providers. Malicious code delivered through legitimate vendor channels, complete with valid digital signatures, bypasses traditional security defenses. Compounding the problem, many medical devices remain operational for 10–15 years with infrequent updates, allowing compromised code to persist undetected. This evolving threat landscape highlights the growing challenges in securing the medical device supply chain.
Supply Chain Complexity
The complexity of the supply chain adds another layer of difficulty to maintaining code integrity. Manufacturers frequently rely on external laboratories for safety and performance testing to speed up development. However, the FDA has flagged a concerning trend of "fabricated, duplicated... or otherwise unreliable" test results from these third-party facilities [11]. In 2025, multiple incidents revealed falsified or copied study results, leading the FDA to reject all data from implicated laboratories, affecting every manufacturer that relied on their findings [10][11].
"While a device sponsor may use a third-party lab for nonclinical studies, doing so does not relieve the device sponsor of the responsibility to ensure the accuracy of data included in their regulatory submission." - FDA [11]
These incidents force manufacturers to independently verify third-party testing results, significantly increasing development time and complexity. If integrity failures are uncovered, the FDA may invoke its Application Integrity Policy, requiring manufacturers to submit entirely new applications and undergo rigorous independent reviews. This adds further strain to an already intricate supply chain, making it harder for manufacturers to keep pace with innovation while adhering to strict security standards.
Balancing Innovation with Security
Manufacturers are caught in a constant struggle to balance the need for rapid innovation with the imperative to maintain uncompromised code integrity. When integrity issues arise, they can lead to regulatory rejections, delaying device approvals, disrupting supply chains, and limiting patient access to new technologies [10].
"Unreliable testing data may also delay or reduce access to new devices that the FDA ultimately authorizes for patients and health care providers and increase the potential for disruption in the supply chains for devices." - FDA [10]
To address these challenges, the FDA emphasizes the importance of a "culture of quality", where manufacturers ensure that both internal teams and external vendors meet strict standards [11]. This requires implementing thorough verification processes without slowing down the pace of innovation - an intricate balance that many organizations find difficult to achieve. These challenges underline the urgent need for robust practices to safeguard code integrity in the face of mounting technical and supply chain obstacles.
Best Practices for Protecting Code Integrity
Adopting Cybersecurity Frameworks
Healthcare organizations need structured approaches to safeguard the code in medical devices. Frameworks like NIST SP 800-218 (SSDF), IEC 62443, ISO 27034, and OWASP SAMM provide guidance for secure software development and reducing tampering risks. For instance, the SSDF outlines tasks such as protecting code from tampering (PS.1) and verifying release integrity (PS.2). Similarly, IEC 62443 offers essential requirements to maintain system integrity in medical devices.
Putting these frameworks into action involves several practical steps. Start by storing all forms of code - source, executable, and configuration - in repositories with restricted access. Use version control systems that log every change at the individual level, with commit signing to ensure accountability. Any code changes should be reviewed and approved by authorized owners before integration. These steps work alongside cryptographic protections applied during development. Additionally, separating development, build, and testing environments from production systems adds another layer of security. Using multi-factor authentication and network segmentation further reduces the risk of attackers moving laterally within the system. Together, these measures create a solid foundation for managing risks effectively.
Using Censinet RiskOps™ for Medical Device Risk Management
Managing risks tied to medical devices starts with visibility across the supply chain. Censinet RiskOps™ offers a centralized platform for healthcare organizations to conduct third-party risk assessments, track device vulnerabilities, and maintain regulatory compliance. The platform’s Censinet AITM™ feature speeds up the process of completing vendor security questionnaires - reducing it from days to seconds - by automating the summarization of vendor evidence and documentation. It also identifies hidden risks from fourth-party suppliers embedded within complex supply chains.
For organizations juggling multiple medical device vendors, each with its own security practices and update schedules, Censinet's command center provides a clear view of risks across the entire portfolio. This is especially crucial for devices with lifespans of 10–15 years, as it allows for ongoing monitoring of vulnerabilities and ensures vendors comply with code integrity standards. Automated workflows direct critical findings to the appropriate stakeholders, such as AI governance committees, ensuring timely resolution. By leveraging these tools, healthcare organizations can maintain continuous monitoring of code integrity throughout a device’s lifecycle.
Performing Regular Security Assessments
To further strengthen code integrity, regular security assessments are essential. Conducting vulnerability assessments and penetration tests helps identify and address weaknesses early. Creating a Software Bill of Materials (SBOM) for each medical device ensures quick identification of affected systems when vulnerabilities are discovered in third-party components.
Store release files and provenance data in secure, read-only repositories, and publish cryptographic hashes on trusted websites to enable fast integrity verification. Use code signing certificates from recognized certificate authorities so operating systems can validate the authenticity of executable code. These practices establish a detailed audit trail, which becomes invaluable when investigating potential breaches or addressing vulnerabilities in older medical devices. Together, they ensure a proactive approach to maintaining code integrity.
Conclusion
The Need for Continuous Monitoring
Maintaining code integrity requires ongoing vigilance throughout a device's lifecycle. Regulatory bodies have moved away from static, one-time approvals and now emphasize continuous lifecycle management. This shift reflects the reality that software updates and evolving cyber threats demand constant oversight [4]. The stakes are particularly high for AI and machine learning-enabled medical devices, where algorithms evolve over time. Monitoring these changes ensures that devices remain safe and effective [4].
The misuse of code signing certificates continues to pose significant financial risks, with potential losses reaching millions of dollars [1]. To mitigate these risks, robust protocols must be in place to protect these credentials. As the FDA highlights, "Medical devices are increasingly connected to the internet, hospital networks, and other medical devices... these same features also increase potential cybersecurity risks" [4]. Regulatory guidelines now prioritize post-market monitoring and patch management, requiring manufacturers to establish clear procedures for incident reporting and rapid responses to newly discovered vulnerabilities [4].
Collaboration Between Stakeholders
Beyond monitoring, collaboration plays a key role in strengthening software security. Ensuring code integrity requires coordination across the healthcare ecosystem. Manufacturers and healthcare organizations must work together to gather real-world performance data, which can inform updated risk assessments and improve software integrity controls. Organizations such as the International Medical Device Regulators Forum (IMDRF) are working to align global standards for software risk categorization and cybersecurity, creating a more unified framework [4].
Internally, collaboration is just as important. Engineering teams, regulatory affairs, and quality assurance departments must maintain a "digital chain of trust", ensuring that every code change is traceable from initial requirements to final release. Keyfactor emphasizes the importance of safeguarding code signing keys, noting, "For code signing to do its job, you'll need policies and procedures in place to keep the keys safe and ensure your brand is protected" [1].
Healthcare organizations can also utilize tools like Censinet RiskOps™ to monitor their medical device portfolios, ensure vendor compliance with code integrity standards, and coordinate responses to emerging threats. By fostering collaboration, stakeholders can safeguard patient safety, meet regulatory expectations, and uphold the trust that medical devices rely on.
FAQs
What happens if a code signing key gets stolen?
If a code signing key falls into the wrong hands, attackers could exploit it to push unauthorized firmware or software updates. This could lead to tampering with the software of medical devices, posing serious risks to both patient safety and the security of sensitive data. Safeguarding these keys is crucial to ensuring the reliability and trustworthiness of medical devices.
How can hospitals verify a device update is authentic before installing it?
Hospitals can ensure a device update is genuine by relying on cryptographic signatures, like firmware signing. This method verifies that the update originates from a trusted source and hasn’t been tampered with during transmission. By using cryptographic verification, medical devices are protected from unauthorized changes, preserving both their integrity and security.
How does an SBOM help respond faster to new vulnerabilities?
An SBOM speeds up responses to new vulnerabilities by allowing automated scans to pinpoint risks quickly. It improves supply chain visibility and simplifies risk management processes, helping organizations tackle threats more effectively and safeguard their software.
