User access control concepts from design inputs and risk management — authorization extends these into a formally documented least-privilege role model covering all device functions.
FDA Appendix 1.B recommends designing devices to "deny by default", an authorization model that incorporates least privilege "by differentiating privileges based on the user role (e.g., caregiver, patient, healthcare provider, system administrator) or device functions", and "automatic timed methods to terminate sessions within the medical device system where appropriate for the use environment".
Role privilege separation (patient vs. provider vs. manufacturer), deny-by-default connection enforcement, and session timeout implementation.
Maps to
FDA Cybersecurity Guidance: §Appendix 1.B Authorization
Requirement text
FDA's Premarket Cybersecurity Guidance (current edition February 3, 2026) recommends that medical device manufacturers implement an authorization scheme that enforces the principle of least privileges. Authorization should differentiate privileges based on user role (e.g., caregiver, patient, healthcare provider, system administrator) or device function, ensuring that system resources are only accessed in accepted ways by accepted parties. Devices should be designed to 'deny by default' (that is, what is not expressly permitted by a device is denied by default); for example, the device should generally reject all unauthorized connections.
Why this clause exists
Authorization — the enforcement of privileges after identity has been established — is the mechanism that limits the damage an attacker can cause even after successfully bypassing or stealing authentication credentials. FDA Appendix 1.B gives an example: "in a situation in which a malicious actor has gained access to a credential associated with patient privileges, that malicious actor should not be able to access device resources or functionality reserved for the manufacturer or for the healthcare provider, such as device maintenance routines or the ability to change medication dosage amounts." Without role-differentiated authorization, a single credential compromise can provide full device access. The guidance recommends that devices be designed to "deny by default" ("that which is not expressly permitted by a device is denied by default"), and that the device "should generally reject all unauthorized connections (e.g., incoming TCP, USB, Bluetooth, serial connections)". The guidance says "While authentication schemes based on cryptographically proven designs are generally considered more robust and are therefore preferred, meaningful authorization checks can be performed based on other compelling evidence (e.g., benefit/risk assessment in accordance with AAMI TIR57 or ANSI/AAMI SW96 and associated supporting justification and as evidenced through security testing)." It gives the example that "a medical device programmer that is capable of Near-Field Communications (NFC) could have elevated privileges that are granted based on a signal of intent over NFC that cannot physically be produced by another unauthorized device over Radio-Frequency (RF) (e.g., a home monitor)."
What changed
FDA's September 2023 final guidance (updated February 2026) Appendix 1.B (Authorization) says: "Within an adequately designed authorization scheme, the principle of least privileges ... should be applied to users, system functions, and others, to only allow those entities the levels of system access necessary to perform a specific function." Among the recommended design implementations it lists are an authorization model that incorporates least privilege "by differentiating privileges based on the user role (e.g., caregiver, patient, healthcare provider, system administrator) or device functions", and designing devices to "deny by default".
Common gaps (what we see in audits)
- No role-differentiated access control — single privilege level for all users — Devices that provide the same access level to patients, caregivers, and healthcare providers violate least-privilege principles. FDA Appendix 1.B recommends an authorization model that incorporates least privilege "by differentiating privileges based on the user role (e.g., caregiver, patient, healthcare provider, system administrator) or device functions", and gives the example that an actor holding patient-privilege credentials "should not be able to access device resources or functionality reserved for the manufacturer or for the healthcare provider, such as device maintenance routines or the ability to change medication dosage amounts".