Section 524B's patch clock has two different speeds

A disclosure policy is a mechanism, not a statement

524B(b)(1) requires a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits “in a reasonable time,” including coordinated vulnerability disclosure and related procedures. FDA's June 2025 final guidance, which replaced the 2023 version, spells out what a reviewer expects that plan to point to: a coordinated vulnerability disclosure policy an outside researcher can actually find and use — a stated point of contact, an intake channel for reports, and language telling a good-faith researcher they won't face legal action for reporting a flaw responsibly. A submission that describes the plan in a paragraph of prose, without a policy a researcher outside the company could locate and act on, has described an intention rather than the mechanism 524B(b)(1) is asking for.

Patching runs two different clocks

524B(b)(2) doesn't ask for a single patching commitment; it names two, running at different speeds. A manufacturer has to make postmarket updates and patches available on a reasonably justified regular cycle for known unacceptable vulnerabilities, and separately, as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risk. Those aren't two ways of describing the same discipline. A quarterly patch cadence can satisfy the first clock and still leave a manufacturer out of compliance with the second, because a critical vulnerability discovered the week after a quarterly release doesn't get to wait for the next scheduled one — the statute's own “as soon as possible” language is a different, faster standard than “on cycle,” and a change-control process that routes every vulnerability through the same release train hasn't built the second clock at all.

Both duties outlive the clearance

A cyber device's software bill of materials has to describe what's actually shipping, not what shipped at clearance. The disclosure policy and the patch commitment carry the same ongoing character, and arguably a harder one to evidence after the fact: an SBOM gap shows up as a missing line on a list, but a lapsed disclosure policy or a missed out-of-cycle patch only shows up if someone kept a record of what came in and when it went out. A vulnerability-handling log that tracks each report against which of the two clocks it triggered, and the date the fix actually shipped against that clock, is the difference between a policy a manufacturer can describe in an interview and one it can prove it ran.

Three obligations, three different failure modes

A device has to clear 524B's own three-part definition before any of 524B(b)'s three obligations attach in the first place. Once it does, the SBOM fails by omission — a component left off the list. The disclosure policy fails by inaccessibility — a plan that exists internally but that no outside researcher could ever find or use. The patch commitment fails by delay — a fix that exists but arrives after the clock it was supposed to meet. A cybersecurity readiness review that checks all three documents for existence and stops there has checked for the wrong failure mode in two of the three.

Where this meets the file

A postmarket cybersecurity tracker built around this structure needs a published, locatable disclosure policy as its own artifact — not a paragraph inside a broader security plan — and a log that timestamps every vulnerability against the regular-cycle or out-of-cycle clock it triggered, distinct from the SBOM's own line-by-line inventory. That structure is previewed in the launch catalog. If your program tracks the two clocks differently, the shelf takes that correction directly.