Software update authentication and data validation from IEC 62304 and existing design controls — integrity controls formalize these into a three-domain requirement covering code, data, and execution state.
FDA Appendix 1.D requires allow-listing for software execution, disabled debug ports prior to delivery, tamper-evident seals, well-formedness validation of external data including range checking, and execution integrity monitoring.
Debug port closure in production builds, firmware signing and verification, and external data validation with range checking — open debug ports and unsigned firmware acceptance are frequently cited integrity deficiencies.
Maps to
FDA Cybersecurity: §Appendix 1.D Code, Data, and Execution Integrity
Requirement text
FDA's Premarket Cybersecurity Guidance (current edition February 3, 2026) recommends that manufacturers implement controls to protect code integrity, data integrity, and execution integrity across the medical device system. Code integrity controls should include authentication of firmware and software using cryptographic signatures or message authentication codes, allow-listing based on digital signatures to control execution, and disabling of unauthorized access to test and debug ports prior to delivery. Data integrity controls should verify that incoming data is not modified in transit or at rest and validate that data from external sources is well-formed. Execution integrity controls should use industry-accepted practices to maintain and verify integrity of code while executing on the device.
Why this clause exists
Integrity violations are the root cause of a wide class of cyber incidents — including firmware tampering, malicious data injection into control streams, and exploitation of debug ports left open in production devices. FDA Appendix 1.D addresses all three integrity domains because they require distinct controls: code integrity protects the software image itself, data integrity protects the information the device processes, and execution integrity protects the running state of the device against memory-based attacks (e.g., return-oriented programming exploits). The specific requirement to disable JTAG and UART ports before delivery reflects a recurring finding in medical device security assessments that debug ports left accessible in production units provide direct hardware-level access that bypasses all software authentication. The allow-listing requirement — permitting only digitally signed software to execute — reflects the regulatory recognition that, given the safety-critical nature of medical device software, preventing any unauthorized code execution is more important than operational flexibility. The prohibition on using CRCs as security controls (addressed jointly with authentication controls in Appendix 1.A) reflects that CRCs detect accidental corruption but not intentional modification.
What changed
FDA's September 2023 final guidance (updated February 2026) Appendix 1.D establishes three-domain integrity requirements (code, data, execution) as explicit design requirements. The specific requirements for allow-listing based on digital signatures, disabled debug ports, tamper-evident seals, and execution integrity monitoring (HIDS/HIPS) are formalized from prior best-practice guidance. The data integrity requirement to validate ranges against safe limits directly links data integrity controls to patient safety, not just cybersecurity.
Common gaps (what we see in audits)
- Debug ports left active in production devices — JTAG, UART, and other debug interfaces are routinely left enabled in production builds because disabling them adds engineering complexity. FDA Appendix 1.D recommends that all test and debug ports be disabled or restricted from unauthorized access prior to delivering products — an open debug port bypasses all software authentication and authorization controls.