Code and Data Integrity Controls for Medical Devices

Reviewed September 17, 2026

Integrity failures let attackers run unauthorized code, silently alter patient data, or roll a device back to a version with a known vulnerability, and the FDA has identified integrity gaps as a root cause behind a meaningful share of medical device cyber incidents. A device can have strong network controls and still be compromised if its firmware isn't signed, its update mechanism accepts an older vulnerable image, or its stored configuration data can be modified without detection. These are not abstract concerns: they determine whether a compromised device keeps running undetected or fails safely and visibly. The February 3, 2026 final guidance treats code, data, and execution integrity as core premarket documentation requirements, and reviewers expect named mechanisms and test results for each. This article breaks down signed firmware, secure boot, anti-rollback, and integrity checks at rest and in transit, along with the evidence each one requires.

Why This Matters

The FDA's February 3, 2026 final guidance, which follows the September 2023 and June 27, 2025 final guidances, identifies integrity violations, unauthorized changes to code, stored data, or the execution state, as a primary root cause of cyberattacks against medical devices. That framing puts code, data, and execution integrity controls at the center of premarket cybersecurity review rather than treating them as a secondary hardening step.

Integrity controls matter because they determine whether a compromise stays contained or spreads silently. A device with signed firmware and a working secure boot chain will refuse to run tampered code and can log the failure for postmarket review. A device without these controls may run modified firmware indefinitely, exposing patient data or device function without any visible signal that something is wrong. Similarly, without anti-rollback protection, an attacker who obtains an older signed firmware image, one with a since-patched vulnerability, can downgrade the device and reopen a fixed hole.

Standards referenced alongside the FDA guidance, including IEC 81001-5-1, ISO 27001, and ANSI/AAMI SW96:2023 (recognition number 13-131), all point to the same expectation: integrity controls need a defined mechanism, a verification method, and evidence that the mechanism was tested against realistic tampering attempts, not just described in a design document.

What Is Signed Firmware and Why Does It Matter?

Signed firmware is firmware that carries a cryptographic signature the device verifies before installing or executing it, and it matters because it's the primary control preventing unauthorized code from running on a medical device. The manufacturer signs each release with a private key, and the device holds the corresponding public key to verify that signature before accepting an update.

Without code signing, any firmware image that reaches the device's update mechanism, whether through a compromised update server, a man-in-the-middle attack, or physical access, can be installed and executed. With it, an attacker needs the manufacturer's private signing key, not just access to the update channel, to get unauthorized code running.

[KEY REQUIREMENT] Signature verification must occur before the new firmware image is written to the active partition, not merely logged after installation, so that an invalid signature blocks the update rather than being recorded as an exception.

How Does a Secure Boot Chain Work?

A secure boot chain works by validating each stage of startup, bootloader, operating system, and application, against a signature anchored to a hardware root of trust, so that no stage runs unless the previous stage confirms it's authentic. The root of trust itself is a key or hash burned into silicon that software cannot alter, which is what prevents an attacker from simply patching out the verification step.

A partial implementation, one that verifies only the first-stage bootloader and then trusts everything after it unconditionally, still leaves the device vulnerable to tampering at the application layer. Full-chain verification, sometimes called chain of trust, closes that gap by extending signature checks through every stage that executes before the device reaches normal operation.

What Is Anti-Rollback Protection?

Anti-rollback protection is a mechanism that prevents a device from installing or running a firmware version older than one it has already run, and it matters because an old, validly signed firmware image can still carry a vulnerability that a newer release fixed. Without this control, an attacker who obtains a legitimate older firmware image can push a downgrade and reopen a patched hole, all while the signature check passes because the image is genuinely signed by the manufacturer.

The typical implementation uses a monotonic counter stored in tamper-resistant hardware that increments with each firmware version, and the bootloader refuses to load any image whose version number is lower than the counter. Manufacturers should test this explicitly by attempting to install a known older signed image and confirming the device rejects it rather than assuming the version check logic works as designed.

How Should Integrity Checks Work at Rest and in Transit?

Integrity checks at rest and in transit should confirm that stored data, configuration, calibration, and patient records, and data moving between components or to external systems have not been altered without detection. At rest, this typically means cryptographic hashes or authenticated encryption applied to stored data, checked before the data is used. In transit, it means authenticated communication protocols where any modification to the payload invalidates the message.

See also: CVSS Scoring for Medical Devices: A Complete Walkthrough, Healthcare Cybersecurity Companies: A Buyer's Selection Guide, and Medical Device Software Development: A Compliance Guide.

[KEY REQUIREMENT] Data validation must apply to all incoming data, including data from other device components and external systems, not just data arriving over the network, since the FDA guidance treats any external data source as untrusted until validated.

What Evidence Does the FDA Expect for Each Control?

The FDA expects a named mechanism and a corresponding test result for each integrity control, submitted as part of the cybersecurity documentation rather than described only in narrative form. For code integrity, that means evidence that signature verification actually blocks an unsigned or modified image. For anti-rollback, evidence that a deliberate downgrade attempt is rejected. For data integrity, evidence that tampered data at rest or in transit is detected rather than silently accepted.

Reviewers look for this evidence tied back to the risk assessment required under ISO 14971, so that each identified integrity risk maps to a specific control and a specific test outcome. A generic statement that "firmware is signed" without version-specific test evidence, or a claim that "data integrity is maintained" without a description of the validation method, is the kind of gap that generates an additional information request.

How Hash Collisions Threaten Integrity Controls

A birthday attack is the mechanism that determines how much collision resistance a hash function actually provides, and it matters here because every integrity control described above, signed firmware, secure boot, anti-rollback, depends on a hash that an attacker cannot forge a collision for. The math is less forgiving than intuition suggests: for an n-bit hash, generic collision-search effort is roughly 2^(n/2), not 2^n, meaning collision resistance is effectively half the stated output length.

This matters for signed firmware specifically. A signature typically operates over a hash of the firmware image, not the image itself, so if the underlying hash is weak or truncated, an attacker who can find two inputs producing the same hash could get a fraudulent image accepted under a signature that was validly generated for something else. The same risk applies to SBOM component identifiers and CI/CD artifact hashes, where truncation "to save space" or lingering use of MD5 or SHA-1 in build tooling quietly weakens the same integrity chain this article describes for secure boot and anti-rollback.

The practical fix is consistent with the rest of this article's evidence expectations: use SHA-256 or stronger for anything feeding a signature or integrity check, never truncate without a quantified rationale, and use HMAC or a full signature rather than a plain hash wherever forgery resistance, not just accidental corruption, is the actual threat. Documenting this choice as part of the same risk-to-verification chain covering signed firmware and secure boot gives reviewers one consistent integrity story instead of a gap between the update mechanism and the cryptographic primitive underneath it.

How Blue Goat Cyber Approaches This

Blue Goat Cyber's medical device practice treats code, data, and execution integrity as design-controlled engineering requirements, verified through direct testing rather than accepted as design claims. That includes attempting to load unsigned or downgraded firmware images to confirm secure boot and anti-rollback actually hold, and testing whether tampered configuration or telemetry data is detected by the device's own integrity checks.

Findings feed directly into the risk assessment and premarket documentation, so the evidence reviewers expect under the February 3, 2026 guidance is already in hand before submission. This work is scoped as part of our FDA premarket cybersecurity services, which cover firmware validation, penetration testing, and the supporting SBOM and threat model documentation.

Frequently Asked Questions

What is code integrity in a medical device?

Code integrity means the device's firmware remains authentic and unmodified throughout its lifecycle, verified through mechanisms like code signing, hash comparisons, and secure boot. It ensures that only firmware the manufacturer authorized can execute on the device.

How does the FDA view data integrity?

The FDA expects manufacturers to validate incoming data, whether from a network connection, another device component, or an external system, and to protect stored data from undetected modification. This applies to configuration, calibration, and patient data alike, both at rest and in transit.

Why does anti-rollback protection matter if firmware is already signed?

A signed older firmware version still passes signature verification even though it may contain a since-patched vulnerability. Anti-rollback protection adds a version check on top of signature verification so a device can't be downgraded to a validly signed but outdated, vulnerable image.

Does the FDA mandate specific integrity mechanisms?

The February 3, 2026 final guidance doesn't mandate one specific technology, but it does require manufacturers to identify integrity risks in the risk assessment and to implement and test corresponding controls. Reviewers expect a named mechanism and verification evidence, not just a statement that integrity was considered.

CTA

Blue Goat Cyber tests whether your firmware signing, secure boot, and anti-rollback controls actually hold under direct attack, before a reviewer or attacker finds the gap. Schedule a discovery session to validate your device's integrity controls.

Continue the Security controls & architecture series

Dive deeper with these companion articles:

• FDA Medical Device Cybersecurity Labeling
• Security Architecture Views: The FDA's Four Required Diagrams
• Microkernel Architectures for Medical Devices
• What Is a Write Blocker? Hardware vs Software
• Section 524B(b)(2): Medical Device Cyber Duties
• Functional vs Non-Functional Device Requirements
• SaMD vs SiMD: What Manufacturers Need to Know