Patch and Update Mechanism Testing for FDA Section 524B(b)(1)

Published June 11, 2026

Key Takeaways

• Patchability is statutory under Section 524B(b)(1). It is not optional for any cyber device.
• The Feb 2026 guidance expects test evidence of the patch path, not just a description of it.
• Reviewers expect specific test cases: signature bypass attempts, rollback to a vulnerable signed version, update channel spoofing, partial / interrupted updates, post-update integrity.
• The patch mechanism lives in eSTAR v7.0 Slot 6 (Controls); the test evidence lives in Slot 7 (Testing).
• The most common deficiency is "Provide evidence of patchability demonstrating compliance with Section 524B(b)(1)" — issued when a submission describes the mechanism but shows no exercising tests.

Table of Contents

• Key Takeaways
• Why this matters
• What Section 524B(b)(1) actually requires
• The test cases reviewers look for
• What an acceptable patchability evidence package looks like
• Common deficiency patterns
• How Blue Goat Cyber tests patch mechanisms
• FAQ

Why this matters

The Feb 3, 2026 final guidance is the first FDA cybersecurity document to enforce statutory patchability requirements. Section 524B(b)(1) was added to the FD&C Act in 2023 and made effective in March 2023. The 2026 guidance operationalizes it. Reviewers are now actively flagging submissions where the patch mechanism is described but not tested.

The clinical consequence is direct. A device that cannot be patched is a device that accumulates risk over its deployed lifetime. The agency's framing is that an unpatchable connected device should not reach market.

What Section 524B(b)(1) actually requires

The statute requires manufacturers to:

1. Design the device so it can be updated and patched.
2. Demonstrate the ability to update and patch in a reasonably and reliably timely manner.
3. Maintain the ability to do so across the deployed lifetime.

The Feb 2026 guidance translates that into evidence the submission must contain:

Two words carry the weight: reasonably (means there is an explicit SLA, not "best effort") and reliably (means the mechanism has been exercised under realistic and adverse conditions). Both require test evidence.

The test cases reviewers look for

A patchability evidence package that passes review on first read contains, at minimum, these test cases:

Signature verification

• Apply a valid signed update — expect success.
• Apply an update with an invalid signature — expect rejection and logged event.
• Apply an update signed by a different (untrusted) key — expect rejection.
• Apply an update with a malformed signature block — expect rejection without crash.

Anti-rollback / version monotonicity

• Apply an older signed update than the currently installed version — expect rejection with logged event.
• Attempt to flash a known-vulnerable signed historical version — expect rejection.
• Verify that the rollback policy is enforced at the bootloader (not just the application).

Update channel authentication

• Spoof the update server (DNS / certificate manipulation) — expect TLS validation failure and update abort.
• Replay a captured-then-modified update — expect signature failure or replay protection.
• Run the update over a network with on-path adversary tooling — confirm integrity is preserved.

Partial / interrupted updates

• Interrupt the update at multiple points (network drop, power loss, watchdog reset) — expect either successful resumption or safe rollback to the prior known-good image.
• Verify the device never boots into a partially-updated state.
• Verify the device remains clinically safe during the update window (or documents the safe down-state).

Post-update integrity

• After a successful update, verify the bootloader chain still passes attestation.
• Verify logs record the update with a tamper-resistant entry.
• Verify any keys rotated as part of the update are usable and that the prior keys are revoked.

Patch delivery SLA

See also: Docker Containers in Medical Devices: What the FDA Expects You to Test, DAST vs Penetration Testing: What the FDA Requires, and eSTAR v7.0 Cybersecurity for IVDs vs nIVD Submissions.

• Document the measured time from a representative CVE disclosure → patch availability → patch deployment.
• Provide evidence (a CAPA record, a previous patch cycle log) that this SLA has been achieved in practice — not just promised.

What an acceptable patchability evidence package looks like

A Section 524B(b)(1) evidence package that reviewers accept on first read typically contains:

• Update mechanism design description (filed in eSTAR Slot 6) with the cryptographic primitives, key management, channel design, and failure-mode handling
• Test plan mapping each of the test categories above to specific test IDs
• Test report with results for each test ID, including evidence (logs, screenshots, packet captures) for the negative cases
• SLA narrative stating the time-from-CVE-disclosure-to-deployed-patch target and the prior-cycle evidence supporting it
• Postmarket commitment referenced from the Cybersecurity Management Plan and the Vulnerability Management Plan
• Operator-facing labeling describing how the update reaches the deployed device

This evidence sits across eSTAR v7.0 Slots 1 (Management Plan), 6 (Controls), and 7 (Testing), with cross-references that let a reviewer follow the thread.

Common deficiency patterns

The four deficiency patterns we see most often on patchability:

1. Mechanism described, not tested. The submission has an update-mechanism diagram but no Slot 7 test report exercising it. Most common pattern by a wide margin.
2. No anti-rollback evidence. Devices that prevent unsigned updates but happily accept older signed-and-vulnerable versions. Reviewers ask explicitly for rollback test cases now.
3. No documented SLA. A general statement that "patches will be delivered promptly" with no measurable time target.
4. No partial-update safety analysis. Reviewers ask "What happens if power is lost at byte N of the update?" If the answer is not in the submission, it becomes an AI request.

How Blue Goat Cyber tests patch mechanisms

Our pen testers run patch mechanisms through every test case above on a calibrated bench: signature manipulation, key substitution, rollback attempts to known-vulnerable signed versions, update-server impersonation with HackRF and rogue cert, repeated mid-update interruption with controlled power and network conditions, and post-update attestation. We deliver the Section 524B(b)(1) evidence package as part of the Slot 6 + Slot 7 attachments, with the traceability matrix back to the threat model.

If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our penetration testing service and the related FDA Cybersecurity Testing Requirements Taxonomy.

FAQ

Does Section 524B(b)(1) apply to my device?

If the device meets the Section 524B definition of "cyber device" — software validated by the sponsor, able to connect to the internet, and containing technological characteristics that could be vulnerable — then yes. That bar is intentionally low; almost every modern connected device qualifies. Use our Cyber Device Applicability tool to confirm.

Is "reasonably and reliably timely" a defined SLA?

The statute does not specify a number. Reviewers expect the sponsor to state the SLA and back it with evidence that the SLA has been met in practice. Typical SLAs we see accepted are "critical CVE → patch available within 30 days, deployed within 90 days" for non-life-sustaining devices and shorter for life-sustaining devices.

Can patches be delivered manually (by a service technician)?

Yes, with documented evidence the manual process meets the SLA. Pure-OTA is preferred but not required. The mechanism must be reliable and timely; the delivery mode is the sponsor's choice.

What if the device has no field-update capability today?

That is a design problem, not a documentation problem. Section 524B(b)(1) effectively requires field-updateable designs for new submissions. If the device cannot be updated, the path forward is design change before submission, not narrative-only justification.

How is this different from change control after clearance?

Change control (letter to file, special 510(k), PMA supplement) governs what regulatory submission a future change requires. Section 524B(b)(1) governs whether the device can deliver the change to the field at all. They are complementary, not substitutes. See our posts on letter to file vs new 510(k) and PMA supplement cybersecurity changes.

Where does the SBOM fit?

The SBOM (Slot 5) drives the vulnerability management feed that triggers patch cycles. A patch mechanism without an SBOM-driven monitoring process is a patch mechanism with no input signal. See SBOM vulnerability management.

Ready to test your patch mechanism?

If you are preparing a 510(k), De Novo, or PMA submission and have not yet exercised the patch mechanism under negative conditions, we will scope the testing to Section 524B(b)(1) and deliver an eSTAR-ready evidence package. Request a scoping call.

---

Christian Espinosa — Founder, Blue Goat Cyber. CISSP, ex-military red team. Has tested patch and update mechanisms across more than 250 FDA-submitted medical devices, including infusion pumps, implantables, and connected diagnostics. More on the author.

Related reading

• The SPDF Playbook
• eSTAR v7.0 Cybersecurity Attachments mapping