Documenting Update Cadence for an FDA 524B Submission

The 524B(b)(2)(B) update cadence requirement is the one most sponsors underdocument. Teams put real engineering work into signed packages, verified boot, and rollback paths, then describe the cadence in two vague sentences buried inside the postmarket plan. Reviewers can tell, and the resulting Additional Information letters all read the same way: name the regular cycle, name the out-of-cycle path, justify both. This post walks through what reviewers actually expect to see for each, the wording patterns that satisfy them, and the deficiency patterns that recur when sponsors leave either side ambiguous.

Key Takeaways

• 524B(b)(2)(B) has two halves: a regular update cycle and an out-of-cycle expedited path. The submission must document both, separately.
• "Reasonably justified" is the operative phrase for the regular cycle. The justification is what reviewers grade, not the cadence itself.
• The out-of-cycle path needs severity triggers (CVSS or equivalent), timeline targets, decision authority, and a customer-communication channel.
• Update cadence belongs in the SPDF narrative and the postmarket plan, with a single source of truth and consistent wording across both.
• The most common deficiency is naming a cycle without justifying it, or naming a cycle without the out-of-cycle counterpart.

Table of Contents

• What 524B(b)(2)(B) Actually Says
• Where Update Cadence Belongs in the Submission
• Documenting the Regular Cycle
• Documenting the Out-of-Cycle Path
• Customer Communication of the Cadence
• Worked Example: Cadence Statement for a Class II Connected Device
• Deficiency Patterns Reviewers Flag
• How Blue Goat Approaches Cadence Documentation
• FAQ

Why this matters

Section 524B(b)(2)(B) is the postmarket-update provision of the cyber device statute, added to the FD&C Act by the Consolidated Appropriations Act, 2023. The FDA's February 3, 2026 final guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," is the operative interpretation. The guidance ties cadence documentation back to AAMI SW96:2023 security risk management, AAMI TIR57:2016/(R)2023 risk management for medical device security, and IEC 81001-5-1:2021 software lifecycle for health software. Reviewers expect cadence statements that reference these standards by name. The FDA's CDRH performance data through FY2024 (CDRH FY2024 Performance Report) puts cybersecurity among the top three deficiency categories in 510(k) and PMA Additional Information letters. Inside the cybersecurity bucket, the (b)(2)(B) cadence gap is one of the most repeatable patterns: the submission describes update capability (signed packages, verified boot) without documenting update cadence (when, how often, what triggers expedited). Capability without cadence does not satisfy (b)(2)(B). Both have to be in the submission.

What 524B(b)(2)(B) Actually Says

The text of 524B(b)(2)(B) requires the manufacturer to make available postmarket updates and patches to the device and related systems on a reasonably justified regular cycle to address known unacceptable vulnerabilities, and, as soon as possible out of cycle, to address critical vulnerabilities that could cause uncontrolled risks.

Two operative requirements live inside that sentence:

• A regular cycle that is reasonably justified and addresses known unacceptable vulnerabilities.
• An out-of-cycle path that triggers as soon as possible for critical vulnerabilities that could cause uncontrolled risks.

The statute uses different severity language for each path. "Known unacceptable" governs the regular cycle. "Critical" with "uncontrolled risks" governs out-of-cycle. The submission needs to define both severity thresholds in the manufacturer's own risk framework so a reviewer can see which vulnerabilities take which path.

Where Update Cadence Belongs in the Submission

Cadence documentation belongs in three places, with the same wording in each:

• The SPDF (Secure Product Development Framework) narrative under the section that covers postmarket activities. This is the sponsor-side description of how the cadence is built into the development process.
• The postmarket cybersecurity plan required by 524B(b)(1). This is the operational description of how cadence runs in the field, with the CVD intake, severity triage, CAPA linkage, and customer communication.
• The labeling (security documentation provided to the customer), which surfaces the cadence and the expedited path to the operating health-delivery organization (HDO).

A single source of truth wins. Pick one document (usually the postmarket plan) as the canonical cadence definition and have the SPDF narrative and the labeling reference it explicitly. Reviewers flag mismatches between the three immediately.

Documenting the Regular Cycle

The regular cycle has three documentation components reviewers look for:

• The cadence itself. Pick one model and name it: time-based ("quarterly minor releases, semiannual major releases"), severity-driven ("any known unacceptable vulnerability bundled into the next scheduled release within 90 days"), or hybrid ("scheduled quarterly with a 30-day window for known unacceptable findings"). Vagueness ("on a regular basis," "as needed") draws a deficiency.
• The justification. This is what 524B(b)(2)(B) actually grades. Tie the cadence to the device's risk profile, the deployment model (connected vs. air-gapped), the change-control burden on the customer, and the verification-and-validation cycle. A cardiac implant with an over-the-air channel justifies a different cadence than a benchtop analyzer that requires a service visit.
• The change-control linkage. Name the design control procedure that governs cadence changes. Cadence is a design decision; if marketing wants to change it next quarter, the change has to flow through design controls, not a side conversation.

A reviewer reading the cadence section should be able to answer: what is the cycle, why is that cycle appropriate for this device, and how does the manufacturer change the cycle if conditions change.

Documenting the Out-of-Cycle Path

The out-of-cycle path has four documentation components:

• Severity triggers. Define which vulnerabilities take the expedited path. Most manufacturers use CVSS v3.1 base + temporal as a starting point with device-specific environmental adjustments. Name the threshold (e.g., "any vulnerability with adjusted CVSS ≥ 9.0, or any vulnerability that could cause uncontrolled patient harm regardless of CVSS").
• Timeline targets. Name the target windows: triage within 24-72 hours, patch development within X days, validation within Y days, customer-available within Z days. The statute says "as soon as possible," which reviewers read as "as soon as possible for this device class," not instantaneously. Document the targets and the engineering basis for them.
• Decision authority. Name the role (not the person) authorized to declare an out-of-cycle release: typically the Chief Product Security Officer or equivalent, with escalation to the executive sponsor for releases with significant change-control impact.
• Customer communication. Name the channel: customer security advisory, ICS-CERT/CISA coordination, HSCC notification, direct customer security contact list. The expedited path is useless if customers do not know a patch dropped outside the regular cycle.

The out-of-cycle path is where deficiency letters cluster. Sponsors describe a regular cycle in detail and then say "expedited patches will be issued as needed for critical issues," which fails on every one of the four components above.

Customer Communication of the Cadence

See also: Does FDA Section 524B Apply to Legacy Devices?, FDA Section 524B Explained Subsection by Subsection: What Each Requirement Means in 2026, and Medical Device Incident Response Plan: FDA Expectations 2026.

Both the regular cycle and the out-of-cycle path have to be visible to the HDO, not just to the sponsor's engineering team. The 2026 guidance expects security documentation provided to the customer (sometimes packaged as an MDS2 supplement or a security white paper) to state:

• The regular update cycle and what triggers a release.
• The out-of-cycle process and the customer's expected role in deploying expedited patches.
• The notification channel the customer should subscribe to.
• The expected time between patch availability and the recommendation to deploy.

A reviewer who sees a strong internal cadence definition but no customer-facing surface still flags it. The submission has to show that the cadence is operational, not just documented.

Worked Example: Cadence Statement for a Class II Connected Device

A defensible cadence section for a Class II connected patient-monitoring device reads like this (paraphrased structure, not a template to copy verbatim):

Regular update cycle. [Device] follows a quarterly minor release and semiannual major release cycle. Known unacceptable vulnerabilities identified through the vulnerability monitoring sources named in §[X] of the postmarket plan are bundled into the next scheduled release within 90 days of triage. The cadence is justified by (a) the device's continuous network connectivity, which allows over-the-air delivery without service visits, (b) the medium clinical impact of a typical configuration change, and (c) the customer's [named hospital system tier] change-control workflow, which supports a 90-day deployment window without operational disruption. Cadence changes flow through [named SOP] in the manufacturer's design control system.

Out-of-cycle expedited path. Any vulnerability with adjusted CVSS v3.1 ≥ 9.0, or any vulnerability that a security risk assessment per AAMI SW96:2023 classifies as causing uncontrolled patient harm regardless of CVSS, triggers the expedited path. Triage within 24 hours, patch development within 7 days, V&V within 7 days, customer-available within 21 days, target. Declaration authority is the [named role]. Customers are notified through (a) the [named] customer security advisory list, (b) HSCC channels, and (c) ICS-CERT coordination where appropriate. Communication includes the recommended deployment window for the HDO.

That paragraph satisfies (b)(2)(B) because both halves are named, both are justified, and both have operational detail a reviewer can grade.

Deficiency Patterns Reviewers Flag

Recurring deficiency patterns on (b)(2)(B):

• Cadence without justification. "Quarterly minor releases" with no explanation of why quarterly is appropriate for this device class.
• Out-of-cycle path described as "as needed." No severity threshold, no timeline targets, no decision authority.
• Customer-facing surface missing. Internal cadence documented; security documentation provided to the customer does not mention it.
• Mismatch between SPDF and postmarket plan. Two different cadence definitions across documents because nobody picked a single source of truth.
• No change-control linkage. Cadence presented as an engineering preference rather than a design-controlled decision.
• Severity language conflated. The submission uses "critical" and "unacceptable" interchangeably without mapping either to the manufacturer's risk framework.

How Blue Goat Approaches Cadence Documentation

We document update cadence as a single source-of-truth section in the postmarket plan, referenced verbatim from the SPDF narrative and the customer-facing security documentation. The regular cycle gets a named cadence model, a justification tied to the device's risk profile and deployment model, and a change-control linkage. The out-of-cycle path gets severity triggers anchored in CVSS plus AAMI SW96:2023 security risk classification, timeline targets, named decision authority, and customer notification channels. Severity language is mapped explicitly to the manufacturer's risk framework so reviewers can see which vulnerabilities take which path. Our engineers hold CISSP, OSCP, and prior military red-team credentials. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our FDA premarket cybersecurity service or read the 524B subsection-by-subsection walkthrough.

FAQ

What does 524B(b)(2)(B) require for update cadence?

Two things: a reasonably justified regular update cycle for known unacceptable vulnerabilities, and an as-soon-as-possible out-of-cycle path for critical vulnerabilities that could cause uncontrolled risks. The submission has to document both separately, with severity thresholds, timeline targets, and the justification for each.

How often does the regular cycle have to be?

The statute does not name a frequency. It names a standard: "reasonably justified." Quarterly is common for connected Class II devices, semiannual is common for devices with heavier customer change-control overhead, and annual is sometimes acceptable for low-risk or air-gapped devices. The cadence has to match the device's risk profile and deployment model, and the justification is what reviewers grade.

Does "as soon as possible" mean immediately?

No. Reviewers read "as soon as possible" as "as soon as possible for this device class given the V&V and deployment realities." A patch that requires safety verification on a Class III implant cannot be released in 48 hours. Document realistic timeline targets and the engineering basis for them. Vague "as soon as possible" with no target draws a deficiency.

Where does the cadence statement live in the submission?

In the SPDF narrative, the 524B(b)(1) postmarket plan, and the security documentation provided to the customer. Pick the postmarket plan as the canonical source and reference it from the other two. Mismatches between documents are an immediate deficiency.

What severity thresholds should I use for the out-of-cycle path?

Most sponsors anchor on CVSS v3.1 base + temporal with device-specific environmental adjustments, plus an explicit override for any vulnerability the security risk assessment under AAMI SW96:2023 classifies as causing uncontrolled patient harm. CVSS alone is not sufficient because it does not capture device-specific patient impact. Both layers belong in the threshold definition.

Does the customer need to see the cadence?

Yes. The 2026 final premarket guidance expects security documentation provided to the customer to surface both the regular cycle and the out-of-cycle process, including the notification channel and the recommended deployment window. A strong internal cadence with no customer-facing surface is incomplete.

Ready to document update cadence the way reviewers expect?

If your cybersecurity section names an update mechanism but does not document cadence with a regular cycle, an out-of-cycle path, severity triggers, and timeline targets, you are leaving 524B(b)(2)(B) deficiency exposure on the table. We can structure the cadence documentation so every reviewer question has a labeled answer. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.

---

About the author. Christian Espinosa, Founder, Blue Goat Cyber, CISSP. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance, including Section 524B(b)(2)(B) update cadence documentation. Read more about Christian.