FDA Postmarket Cybersecurity

FDA postmarket cybersecurity management is a lifecycle risk process for marketed and distributed devices. It turns architecture knowledge, threat models, SBOMs, vulnerability intelligence, customer communication and patch validation into decisions about patient harm and field action.

Lifecycle risk

FDA's postmarket guidance is still the primary FDA postmarket cybersecurity guidance. It is built around the reality that medical devices remain in use while new vulnerabilities, attack techniques, third-party component issues and deployment changes appear after release.

The postmarket file should therefore preserve enough design knowledge to assess a new signal quickly: device architecture, intended environment, safety and essential performance, threat model, SBOM, supported versions, compensating controls, logging, update paths and customer responsibilities.

Patient-harm framing

FDA's postmarket cybersecurity risk decision focuses on whether a vulnerability could create patient harm, including death or physical injury. Privacy or business-impact concerns can still matter, but they are not the patient-harm test in this guidance.

Lifecycle maintenance

A postmarket process monitors vulnerability sources, evaluates new information, validates fixes, communicates with users and updates fielded devices through planned and urgent paths.

Fielded-version awareness

The same component vulnerability can have different risk consequences across versions, configurations, use environments and compensating controls. The assessment must preserve that context.

Controlled and uncontrolled risk

FDA divides postmarket cybersecurity vulnerability risk into controlled and uncontrolled risk. The decision is not whether a vulnerability exists. The decision is whether the residual patient-harm risk is acceptable after existing or available controls are considered.

Controlled risk

Controlled risk means the residual risk of patient harm is sufficiently low or acceptable. Routine security updates, routine patches and best-practice labelling changes usually sit here when they only address controlled risk.

Uncontrolled risk

Uncontrolled risk means the residual risk of patient harm is unacceptable because existing mitigations or compensating controls are insufficient. FDA expects timely remediation and may expect reporting under 21 CFR part 806 unless the guidance's enforcement-discretion conditions are met.

Uncontrolled risk is present when there is unacceptable residual risk of patient harm due to insufficient risk mitigations and compensating controls.

FDA postmarket cybersecurity guidance, December 2016

Routine updates and patches

FDA treats many cybersecurity updates and patches as ordinary device enhancements when they improve security or remediate vulnerabilities associated with controlled risk. Those routine updates are generally not the kind of correction or removal that must be reported under 21 CFR part 806.

That boundary is narrow. An update is not routine when it is needed to reduce uncontrolled risk or when there is a reasonable probability that exploitation could cause serious adverse health consequences or death. The manufacturer still needs validation, distribution control, customer communication and records even when no 806 report is expected.

  • Routine security updates can include patches, hardening changes and labelling updates for secure configuration or best practice.
  • Routine status depends on patient-harm risk, not on whether the change is technically small.
  • The same patch can be routine for one product configuration and urgent for another if the residual patient-harm risk differs.

Postmarket programme

A credible FDA postmarket programme is an operating process, not a document filed away after clearance or approval. It needs named responsibilities, monitoring sources, intake channels, triage criteria, validation capacity, customer communication paths and records that support later FDA review.

Connection to premarket files

The FDA premarket and postmarket files should not be separate worlds. A premarket threat model becomes the baseline for postmarket triage. A premarket SBOM becomes the component inventory for vulnerability monitoring. A premarket security architecture becomes the map for deciding whether a new vulnerability can reach a safety-relevant function.

  • Keep the SBOM current for marketed configurations and preserve version context for fielded devices.
  • Update threat models when deployment assumptions, update paths, external services or vulnerabilities change.
  • Use postmarket findings to update risk management, labelling, customer instructions, support plans and future premarket submissions.
  • Do not treat a postmarket disclosure plan as a substitute for a validated patch process.

Primary sources

Sources