FDA finalized "Content of Human Factors Information in Medical Device Marketing Submissions" on May 29, 2026, replacing the December 2022 draft. There is a town hall on July 22. Every summary I have read treats it as a usability document, which it is. But read it next to the premarket cybersecurity guidance and something jumps out. The two documents describe the same user, and only one of them knows the other exists.
Here is the specific text. The premarket cyber guidance (the QMSR-aligned version FDA reissued February 3, 2026, superseding the June 2025 final) says in its labeling section: "Any risks transferred to the user should be detailed and considered for inclusion as tasks during usability testing (e.g., human factors testing) to ensure that the type of user has the capability to take appropriate actions to manage those risks." The footnote cites FDA's human factors guidance directly.
Now go the other direction. The new HF guidance has no cybersecurity section. Per FDA's own Federal Register notice, the changes from draft to final were additional risk-based factors, new examples and appendices, and scope clarifications. None of them added one. Cyber tells you to hand risks to the HF process. The HF process has no idea they are coming.
The cyber guidance's labeling section enumerates what it expects users to actually do: respond upon detection of a cybersecurity vulnerability or incident. Download version-identifiable manufacturer-authorized software and firmware. Act on security event notifications covering configuration changes, login attempts, and anomalous network traffic. Back up and restore authenticated configurations. Make user-configurable changes, some of which the guidance admits "could increase security risk." Sanitize the device at decommissioning.
Every one of those is a user task in the exact sense the HF guidance means it. And the HF guidance's core instrument, the use-related risk analysis, works by decomposing user tasks into possible use errors, then hazards, then severity of harm. A critical task is one where a use error could produce serious harm.
So run the security tasks through that machine. A nurse dismisses a security alert because it renders like every other alarm on the unit. A biomed tech restores a backup configuration that was never authenticated. A user sideloads firmware because the authorized download procedure takes four steps and the vendor portal link is stale. Those are use errors, and they can land on the same severity tiers as any clinical use error. By FDA's own definitions, several security tasks are candidate critical tasks. I have not yet seen a URRA that includes them.
The URRA covers what a legitimate user does wrong by accident. A threat model covers what an adversary does on purpose. Underneath, they are the same analysis: an interface, a failure mode, a hazard, a harm severity. Different actor, same skeleton.
AAMI TIR57 already exists to bridge ISO 14971 safety risk and security risk, and this seam is exactly where it earns its keep. If your threat model enumerates initial access through the device's own user interface, you already have most of a security-aware URRA sitting in a different document under different vocabulary. Nobody merges them because the HF team and the product security team file to different sections of the submission and usually to different reviewers.
Decision Point B in the new guidance asks whether a modification touches the user interface, intended users, intended uses, use environment, training, or labeling. Now think about what a 524B-driven security patch actually does. It changes an authentication flow. It adds a security notification. It rewrites the IFU's security instructions. Those are UI and labeling changes, so they enter the HF flowchart. Postmarket cyber remediation now generates HF submission-category questions whether or not it ever generates new HF testing.
Decision Point D, new in the final, cuts the other way. It lets a manufacturer argue against submitting HF validation data based on UI use history, UI complexity, and the adequacy of existing risk control measures. The guidance defines complex user interfaces to include devices involving "management such as programming, monitoring, and/or maintenance." That is a security management console, described exactly. And "existing risk control measures" for any connected device includes its security controls, which means the argument for skipping HF validation now runs partly through the security architecture.
The premise under all of this is old news to anyone who has watched security controls survive contact with a clinical environment. Controls that fail human factors get bypassed. Shared credentials. The workstation that never locks because locking it slows a code response. The cyber guidance's phrase "risks transferred to the user" is FDA acknowledging, in its own vocabulary, that usability failure is a security failure.
Questions for the July 22 town hall closed on June 12, so the agenda is already set. My bet is cybersecurity does not come up once. The gap will sit there until either an HF reviewer asks why the patch installation procedure was never validated with users, or a cyber reviewer asks why the URRA contains no security tasks. Both are legitimate questions today.