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 requires deny-by-default connection architecture, explicit least-privilege role differentiation, session timeouts, and documentation of the authorization model as part of premarket submission security architecture.
Role privilege separation (patient vs. provider vs. manufacturer), deny-by-default connection enforcement, and session timeout implementation — missing role differentiation and default-accept connection policies are common deficiency findings.
Maps to
FDA Cybersecurity: §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,' rejecting all unauthorized connections absent explicit permission.
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 identifies the core failure mode that authorization controls prevent: an actor who gains access to patient-level credentials should not be able to reach manufacturer maintenance routines or change medication dosage settings reserved for healthcare providers. Without role-differentiated authorization, a single credential compromise can provide full device access. The 'deny by default' design principle reflects the regulatory finding that many medical devices accepted all connections not explicitly rejected — the opposite of the least-privilege architecture FDA now recommends. The guidance recognizes that not all authorization must be cryptographically proven: in contexts such as NFC-based medical device programmers, physical proximity as a signal of intent can provide meaningful authorization evidence when supported by a benefit-risk assessment consistent with AAMI TIR57 or ANSI/AAMI SW96.
What changed
FDA's September 2023 final guidance (updated February 2026) Appendix 1.B formalizes authorization as a distinct, documented design requirement separate from authentication, requiring explicit least-privilege role modeling and deny-by-default architecture. Prior to 2023, authorization controls for medical devices were addressed only implicitly through user access control conventions. The specific requirement to differentiate privileges by role — including manufacturer service vs. healthcare provider vs. patient — reflects FDA's post-2023 focus on limiting lateral movement after a partial device compromise.
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 requires authorization models that differentiate privileges by role, preventing an actor with patient-level credentials from reaching maintenance functions or modifying clinical configuration parameters.