Healthcare software operates in a threat environment where the consequences of tampered or fraudulent software extend beyond data theft to patient safety. A compromised update to an electronic health record system can alter drug dosages in medication management modules. Malicious firmware on a connected medical device can affect device behavior. A tampered diagnostic algorithm can produce incorrect clinical outputs. Code signing is the technical control that makes software tampering detectable before it executes.
This article covers the specific importance of code signing for healthcare software, the regulatory frameworks that reference or require cryptographic software integrity controls, and the practical implementation considerations for healthcare software publishers.
Why Healthcare Software Requires Stronger Integrity Controls
Software integrity matters in every sector. In healthcare it matters differently, because the failure modes extend to patient harm rather than only data or financial loss.
Consider the attack surface of a mid-size hospital: electronic health record (EHR) systems managing medication orders, clinical decision support tools providing diagnostic recommendations, laboratory information systems processing test results, networked medical devices monitoring patients in real time, and the software update mechanisms that keep all of these current. Each of these systems receives software updates. Each update is a potential injection point for malicious code if the integrity of the update is not cryptographically verified before installation.
A tampered update that alters how a medication management module calculates weight-based dosing, or that modifies the threshold at which a vital sign monitor triggers an alert, or that corrupts the calibration data in an insulin delivery system, is not a data breach. It is a patient safety incident. Code signing is the control that makes such tampering detectable: the signature verification fails if a single byte of the software has been modified after signing.
Healthcare had the highest average data breach cost of any industry for fourteen consecutive years through 2024, reaching $9.77 million per incident (IBM Cost of a Data Breach 2024), and maintained the longest average breach lifecycle at 279 days to identify and contain (IBM 2025 report). The combination of high sensitivity data, critical operational systems, and patient safety implications creates a regulatory and risk environment that demands stronger software integrity controls than most other sectors.
The Regulatory Framework: HIPAA, FDA, and IEC 62304
HIPAA Security Rule: Technical Safeguard for Integrity
The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and business associates to implement technical security measures to guard against unauthorized access to electronically protected health information (ePHI) transmitted over electronic communications networks, and to protect the integrity of ePHI.
The Technical Safeguard standard at 45 CFR 164.312(e)(2)(i) specifically requires implementation of audit controls for systems containing ePHI, and the integrity controls standard at 45 CFR 164.312(c)(1) requires covered entities to implement policies and procedures to protect ePHI from improper alteration or destruction.
The HHS Office for Civil Rights January 2026 Cybersecurity Newsletter explicitly addressed risks from unpatched software and the need for integrity of systems that create, receive, maintain, or transmit ePHI. The newsletter stated that the HIPAA Security Rule risk analysis provision requires an accurate assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI, including risks from unpatched software.
Code signing operates as a technical implementation of these integrity requirements: it provides a cryptographically verifiable record of the software’s state at time of publication, enabling automated detection of any post-publication modification before the software is installed on systems that process ePHI.
FDA Section 524B: Cybersecurity of Medical Devices
The Consolidated Appropriations Act, 2023 (signed December 29, 2022) added Section 524B to the Federal Food, Drug, and Cosmetic Act, with requirements effective March 29, 2023. Section 524B requires that manufacturers of cyber devices demonstrate reasonable assurance of cybersecurity for premarket submissions including 510(k), PMA, De Novo, and other pathways.
The specific cybersecurity requirements in Section 524B(b) include update and patch mechanisms with cryptographic validation. This is the most direct regulatory citation of code signing in healthcare: software updates for connected medical devices must be distributed with cryptographic validation that allows the device or its installation process to verify the update’s authenticity and integrity before applying it.
The FDA issued final guidance on June 27, 2025 (Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions) adding Section VII addressing Section 524B recommendations. This guidance reinforces that manufacturers must document their approach to update integrity verification in premarket submissions.
Section 524B applies to ‘cyber devices’ defined as devices that include software, can connect to the internet or another network, and therefore have cybersecurity risks. The requirements took full effect March 29, 2023. Premarket submissions received by FDA before that date are not subject to the new requirements, but any subsequent change requiring premarket review does subject the new submission to Section 524B.
Software Bill of Materials and Code Signing
Section 524B also requires manufacturers to provide a Software Bill of Materials (SBOM) including commercial, open-source, and off-the-shelf software components. The SBOM requirement and code signing requirements are complementary: the SBOM documents what components are in the software, while code signing ensures the components delivered match what was documented. An SBOM without integrity verification of the delivery mechanism provides limited assurance; an attacker who can tamper with the delivery can substitute components while the SBOM lists the legitimate ones.
IEC 62304: Medical Device Software Lifecycle
IEC 62304 is the international standard for medical device software lifecycle processes. It applies to software that is itself a medical device (Software as a Medical Device, or SaMD) and to software embedded in medical devices. IEC 62304 defines safety classifications (A, B, C) based on the severity of harm that could result from a software failure.
While IEC 62304 does not mandate code signing by name, its requirements for software configuration management, change control, and traceability of software versions create the operational context in which code signing becomes the practical implementation of version integrity controls. Class C software (failure could result in death or serious injury) requires the highest level of configuration control and verification, which in practice means cryptographically verified software distribution.
How Code Signing Addresses Healthcare-Specific Risks
EHR and clinical software updates
Electronic health record systems receive updates frequently: security patches, feature releases, regulatory compliance updates. Each update changes the software running on systems that directly affect patient care. Code signing ensures that the update a hospital IT department installs was produced by the EHR vendor and has not been modified since. Without signature verification, a man-in-the-middle attack on the update distribution channel, or a compromised update server, could deliver a tampered installer that looks identical to the legitimate one.
The practical control: EHR vendors sign their installers and update packages. Hospital IT departments verify signatures before installation, either manually or through automated update management tools that check Authenticode signatures. A valid signature from the expected publisher means the update matches what the vendor released. A missing or invalid signature is a hard stop.
Medical device firmware
Connected medical devices including infusion pumps, patient monitors, imaging equipment, and implantable devices that communicate with external systems receive firmware updates. The integrity of firmware updates is directly patient safety relevant: a tampered firmware image that modifies how a pump calculates flow rates, or how a monitor interprets sensor readings, can harm patients.
FDA Section 524B’s requirement for cryptographic validation of updates directly addresses this threat. A device that verifies the cryptographic signature of a firmware update before applying it will reject a tampered image regardless of how it was delivered. The signature is the last line of defense when network controls, supply chain security, or update server security have failed.
Clinical decision support and AI diagnostic software
Diagnostic algorithms, clinical decision support tools, and AI-based imaging analysis software increasingly influence clinical decisions. These tools are regulated as SaMD under FDA’s framework. A tampered algorithm that systematically produces different outputs than the validated, approved version is not just a software defect: it is a deviation from the cleared or approved version of the device, with patient safety implications.
Code signing provides a cryptographic link between the validated, cleared software version and what is actually running in clinical environments. Version control and deployment records answer ‘what was installed,’ but only signature verification answers ‘is what is installed identical to what was published.’
Practical Implementation for Healthcare Software Publishers
Certificate type and validation level
For healthcare software distributed to hospitals, clinics, and healthcare networks, an OV (Organization Validation) code signing certificate is the minimum appropriate choice. OV certificates display the verified organization name in Windows UAC dialogs and Authenticode signature details, establishing publisher identity alongside integrity verification.
EV (Extended Validation) is required specifically for kernel-mode Windows drivers. For most healthcare software (EHR clients, medical device management software, diagnostic applications), OV provides the appropriate level of assurance.
Healthcare organizations with formal vendor approval processes sometimes specify named Certificate Authorities in their procurement requirements. When deploying to enterprise hospital networks, confirm with the IT procurement team whether specific CAs are required or preferred.
What to sign in a healthcare software package
- Installers and update packages: the primary executable and MSI or equivalent installer. The installer is what hospital IT departments handle; its signature is what they check before deployment.
- All DLLs and executables in the installation: particularly those involved in data access, calculation, or communication. A signed installer that deploys unsigned DLLs provides incomplete protection.
- Firmware images: for medical device manufacturers, firmware update packages that will be distributed to devices and verified at installation time.
- Configuration files using document signing where applicable: clinical configuration files (drug libraries, alert thresholds) that influence clinical behavior can be signed using document signing (separate from Authenticode) to detect unauthorized modification.
Timestamp requirements
Timestamping is not optional for healthcare software. A signed installer or update package without a timestamp becomes unverifiable after the code signing certificate expires. A hospital that installed software six months ago and needs to verify it today, or a regulator auditing whether the software installed on clinical systems matches the approved version, needs a signature that remains verifiable after certificate expiry. RFC 3161 timestamps from a trusted timestamp authority provide exactly this: a cryptographic record that the signature was valid at signing time, which remains verifiable indefinitely regardless of the certificate’s validity period.
Build environment and signing key security
Healthcare software publishers should apply the same rigor to signing key security as to ePHI security. The private key used to sign healthcare software is the root of the trust that hospitals and regulators place in the publisher’s software. Compromise of the signing key means an attacker can sign malicious software that appears to come from the publisher.
Practical controls: private keys stored on FIPS 140-2 Level 2+ hardware (required since June 2023 for all commercially issued code signing certificates), signing operations limited to a dedicated build machine or cloud HSM, key usage logged and monitored, and a defined incident response procedure for potential key compromise that includes immediate certificate revocation and reissuance.
The Audit Trail: Code Signing as Evidence in Healthcare
Healthcare environments face audits: HIPAA audits from OCR, FDA inspections, and hospital vendor audits. Code signing creates a verifiable audit trail that supplements other documentation:
- Each signed release is cryptographically tied to the organization’s verified identity: the Organization field of the certificate is validated by the CA, creating an independent attestation of publisher identity that supplements internal records.
- The timestamp provides a legally defensible record of when software was published: in an FDA inspection or HIPAA audit, being able to demonstrate that the software installed at a specific clinical site matches a specific signed release, and that the release was published before a specific date, is auditable evidence that supports the organization’s compliance narrative.
- Certificate revocation provides an emergency control: if a signing key is compromised or a software release is found to be defective, the certificate can be revoked. Systems checking revocation will reject the signature of subsequent installs from that certificate, providing a mechanism to prevent further deployment of the compromised version.
Code Signing Across Healthcare Software Types
| Software type | Regulatory context | Signing priority | What to sign |
| EHR / practice management | HIPAA Security Rule integrity safeguards | High | All installers, update packages, DLLs involved in ePHI handling |
| Connected medical device firmware | FDA Section 524B: cryptographic update validation required | Mandatory for Section 524B compliance | Firmware images, OTA update packages, configuration bundles |
| SaMD (diagnostic/AI algorithms) | FDA SaMD framework, IEC 62304 | High for cleared/approved versions | Release builds of the algorithm, model packages, configuration files |
| Clinical decision support tools | HIPAA integrity safeguards; may fall under FDA depending on risk | High | Installers, update packages, configuration files affecting clinical outputs |
| Hospital IT utilities | HIPAA integrity safeguards | Standard | Executables and DLLs deployed to clinical endpoints |
Frequently Asked Questions
Does HIPAA explicitly require code signing?
HIPAA does not name code signing specifically. The Security Rule requires technical safeguards for integrity of ePHI and for systems that handle ePHI, and the standard for those safeguards is ‘reasonable and appropriate’ based on risk assessment. Code signing is a well-established technical control for software integrity. A HIPAA risk analysis that identifies unsigned software updates as a risk to ePHI integrity, and that does not implement code signing or an equivalent control, would be difficult to defend to an OCR auditor. The January 2026 OCR Cybersecurity Newsletter’s emphasis on software patch integrity further strengthens the case that cryptographic integrity verification of software updates is a reasonable and appropriate safeguard.
Does FDA Section 524B require a code signing certificate specifically?
Section 524B requires cryptographic validation of updates, not a specific certificate type or technology. A code signing certificate from a publicly trusted CA (Sectigo, DigiCert, SSL.com) is the standard implementation of cryptographic update validation for Windows-based medical device software. For embedded firmware on devices that do not run Windows, symmetric or asymmetric cryptographic verification using manufacturer-held keys is the typical approach. The FDA’s premarket submission guidance requires manufacturers to document their specific approach; a publicly trusted code signing certificate is a well-understood, auditable implementation that reviewers recognize.
What should healthcare software publishers do if a signing key is compromised?
Treat it as a security incident with the same urgency as an ePHI breach. Immediately revoke the compromised certificate through the issuing CA, which adds the certificate to the CA’s CRL and OCSP responder. Notify software recipients that signatures from the compromised certificate should not be trusted, providing the certificate thumbprint and revocation date. Obtain a new certificate and re-sign affected software packages. Assess which signed releases were distributed during the period the key may have been compromised. Document the incident and response for HIPAA risk management records and for FDA postmarket surveillance documentation if the signed software includes cyber devices.
Gloria Bradford is a renowned expert in the field of encryption, widely recognized for her pioneering work in safeguarding digital information and communication. With a career spanning over two decades, she has played a pivotal role in shaping the landscape of cybersecurity and data protection.
Throughout her illustrious career, Gloria has occupied key roles in both private industry and government agencies. Her expertise has been instrumental in developing state-of-the-art encryption and code signing technologies that have fortified digital fortresses against the relentless tide of cyber threats.