Balancing Security Controls with Usability in Medical Devices: A Risk-Based Approach

A security control that slows a clinician down in an emergency is a safety risk, not just an annoyance. The way out is not weaker security. It is a risk-based design process in which every control is assessed for the safety risk it introduces, emergency access is designed on purpose, and the trade-offs are written down. FDA's premarket cybersecurity guidance (February 2026), AAMI TIR57, and ANSI/AAMI SW96 all describe this interface between safety and security. This post turns it into a working method.

Why security and usability collide in medical devices

In enterprise IT, a locked-out user calls the help desk. In a hospital, a locked-out nurse has a patient in front of them. The same control carries a different cost.

AAMI TIR57 names the problem directly. When you add a risk control for one kind of risk, you have to reassess the design for the risk it introduces in the other domain. Its example is the one every device team recognizes: adding authentication might create the risk that the device cannot be accessed in an emergency. TIR57 also tells manufacturers to balance usability, device safety, and device security, and to document the trade-offs.

FDA's guidance says the same thing from the regulator's side. Section V.A states that security and safety risk management processes "should also ensure that risk control measures for one type of risk assessment do not inadvertently introduce new risks in the other," and it points to TIR57 and SW96 for how the two processes should interface. Section IV.D adds that cybersecurity controls "should also take into consideration the intended and actual use environment."

Three features of medical devices make this harder than it sounds:

• Users vary. The same device may be operated by a surgeon, a nurse, a biomedical technician, a home caregiver, and a patient with reduced dexterity or vision.
• Time is clinical. Seconds spent on a login screen are seconds not spent on the patient.
• Environments are hostile to ceremony. Gloves, low light, noise, and interruptions all defeat controls that assume a desk and a keyboard.

Our book chapter on understanding stakeholder security needs covers how to capture those users and settings before you pick controls.

What FDA actually expects

It helps to be precise about what is a statutory requirement and what is a recommendation.

The statute. For cyber devices, Section 524B(b)(2) of the FD&C Act requires manufacturers to "design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure." Reasonable assurance of safety and effectiveness is the separate standard applied to the 510(k), De Novo, or PMA itself. Section VII.E of the guidance explains that FDA treats cybersecurity as part of that safety and effectiveness determination.

The quality system. Since February 2, 2026, the Quality Management System Regulation (QMSR) at 21 CFR Part 820 incorporates ISO 13485:2016. ISO 13485 Clause 7.3 now stands where the old 21 CFR 820.30 design controls did. The guidance cites ISO 13485 Subclause 7.3 for design and development and Subclause 7.1 for risk management, and recommends security risk management be built into those processes.

The guidance. Four points in the February 2026 document bear on usability:

• Section V.B.1: effective cybersecurity relies on security being "built in" to a device and not "bolted on" after the design is done. Usability trade-offs made late are exactly the bolt-on pattern.
• Section V.B.1: FDA recommends controls from eight categories, including authentication, authorization, event detection and logging, and resiliency and recovery. Appendix 1 gives implementation recommendations for each.
• Section VI.A: "Any risks transferred to the user should be detailed and considered for inclusion as tasks during usability testing (e.g., human factors testing)." This is the explicit link between the cybersecurity file and the human factors file.
• Section V.A.2: security risk is assessed on exploitability, not probability. That is why security and safety risk need separate assessments that feed each other, as our post on risk assessment using CVSS describes.

None of this asks you to weaken controls for convenience. It asks you to choose controls that are strong and usable in the real environment, and to prove both.

A risk-based method

Here is the process we use. It runs inside the design controls you already have.

1. Model threats and use-related risks together

Threat modeling identifies how an attacker reaches a harm. Use-related risk analysis, per FDA's human factors guidance and IEC 62366-1, identifies how a use error reaches a harm. Run them against the same set of use scenarios. A scenario like "night-shift nurse adjusts infusion rate during a code" belongs in both analyses. See our post on threat modeling for cloud-connected devices for the security half.

2. Score each risk on its own terms

Security risk is scored on exploitability and the harm an exploit could cause. Safety risk is scored on severity and probability under ISO 14971. Keep the two scales separate and define how a security risk transfers into the safety risk assessment. FDA's guidance (Section V.A.2) asks you to describe that transfer method in the submission.

3. Evaluate every control in both directions

For each proposed control, ask two questions. Does it reduce the security risk to an acceptable level? Does it create a new safety or use-related risk? TIR57 asks for this coupling check explicitly. Where the answer to the second question is yes, you have three options: pick a different control, add a compensating design element such as emergency access, or accept the residual risk with a documented benefit-risk rationale.

4. Write down the trade-off

Document the control considered, the risk it introduced, the alternative chosen, and the evidence. FDA's Appendix 1 notes that authorization decisions can rest on a benefit-risk assessment "in accordance with AAMI TIR57 or ANSI/AAMI SW96" supported by security testing. That only works if the assessment exists on paper.

Emergency access, designed on purpose

Emergency access is where most of the tension lives, so it deserves its own design effort rather than a workaround discovered in the field.

TIR57 defines emergency access as a process or mechanism that lets a user quickly reach the intended functionality in urgent situations by bypassing the established access controls. Its Annex A points out that in an emergency, the hospital may need access without any prior relationship with the patient or the device, and the attending clinician expects that access immediately.

The techniques TIR57 describes, in paraphrase:

• Location-controlled access. Relax controls only inside a physically secured setting such as a procedure room.
• A limited emergency mode. Expose the functions needed to stabilize the patient, and nothing else.
• Access logging. Record who invoked emergency access and when.
• Secondary protocols for emergency use. A separate path that is simpler but constrained in scope.
• Proximal communication. Very short-range links, measured in centimeters, that use physical presence as the trust signal.

Two design rules make these safe. First, emergency access must be positively initiated. A deliberate action, not a timeout or a default. Second, every use is logged and reviewable, which TIR57 says is important to deter abuse.

FDA's Appendix 1 fits this pattern. It recommends that "for device operations where non-authenticated behavior could lead to harm, devices should implement additional, non-routine signals of intent based on physical actions, such as a momentary switch." It also gives the example of a programmer granted elevated privileges through a Near Field Communication signal of intent that a distant radio device cannot physically produce. Event detection and logging is one of the eight control categories, so the log of emergency use is a security control in its own right.

Control patterns that hold up in the clinic

The table below pairs common controls with the usability risk they create and a pattern that resolves it. Each pattern is one FDA or TIR57 recommendation applied with the user in mind.

Control	Usability risk it creates	Pattern that resolves it
Password login on a bedside device	Delay and lockout during urgent care; weak passwords chosen to save time	Role-based authorization with least privilege; badge or proximity authentication for routine clinical functions; strong multi-factor authentication reserved for privileged service and admin access
Automatic session timeout	Interrupts a procedure in progress	Time the session to the use environment, which FDA's Appendix 1 allows "where appropriate"; extend sessions while the device is actively in use; never lock mid-delivery of therapy
Authentication on a patient-operated home device	Patient with reduced memory or dexterity cannot operate the device	The MITRE playbook notes passwords "might not be appropriate" for these users; use device pairing, biometrics, or possession-based factors instead
Encrypted and authenticated commands to an implant	Slower pairing; no path for an unfamiliar clinician in an emergency	Proximal communication for trust establishment; limited emergency mode; logged emergency access per TIR57
Deny-by-default network posture	Integration friction with hospital systems	Keep deny-by-default, document the interfaces users must configure in labeling, and validate the setup tasks in human factors testing

The common thread: hard controls on privileged and remote paths, lighter but still authenticated controls on the routine clinical path, and a designed emergency path with logging.

Test the balance, don't assume it

Two kinds of testing prove the design works.

Human factors testing. FDA's human factors guidance describes formative evaluations during design and a validation test on the final design with representative users performing critical tasks. If a security control sits on a critical task, that task belongs in the test. If labeling transfers a security risk to the user, Section VI.A of the cybersecurity guidance says to consider that task for usability testing too. Include the emergency access path as a scenario.

Security testing. Section V.C of the guidance expects evidence that each security control was implemented and tested, plus vulnerability and penetration testing. The emergency path is an attack surface and should be in scope for the penetration test. A bypass that is easy for a nurse and hard for an attacker is the goal, and only testing both sides shows you achieved it.

Where the evidence goes in the submission

FDA's Appendix 4 Table 1 lists six documentation types broken into fourteen elements. None of them is a "usability trade-off" document. The trade-offs live inside the existing elements:

• Cybersecurity Risk Management Report. The threat model and cybersecurity risk assessment show each control, the risk it addresses, any new risk it introduces, and the benefit-risk rationale where you accepted residual risk.
• Architecture views. The security use case views in Section V.B.2 are the natural home for the emergency access flow and the routine clinical access flow, with the controls on each. Our post on how cybersecurity starts with security architecture covers the views.
• Testing. Security test reports covering the controls, and human factors reports covering the tasks those controls touch.
• Labeling. Section VI.A items such as recommended security controls for the use environment, how the device responds to security events, and secure configuration instructions.

Traceability ties it together: security requirement to control to risk to test to label. Our post on the documents FDA expects for software and cybersecurity shows how the packages fit, and the FDA cybersecurity requirements post covers each element.

After launch

The guidance's Section IV.D warns that "the effectiveness of cybersecurity controls may degrade as new risks, threats, and attack methods emerge." The reverse also happens. Field data shows which controls clinicians work around, and a worked-around control protects no one. Feed complaint data, service logs, and emergency access logs back into both risk assessments, and treat a usability failure of a security control as a security finding. Our post on post-market cybersecurity responsibilities covers the monitoring loop.

Security that clinicians will actually use

The balance between security controls and usability is not a compromise between two goods. It is a single risk management problem with two kinds of risk. Model both, score both, check every control in both directions, design emergency access deliberately, test with real users and real attackers, and document the trade-offs where FDA will look for them. Done that way, the control that protects the patient from an attacker never becomes the control that keeps the clinician from the patient.

Need help with security control selection and documentation for your device? Email us at info@cybermed.ai.

Sources

• FDA. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final guidance, February 3, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-system-considerations-and-content-premarket-submissions
• FDA. Applying Human Factors and Usability Engineering to Medical Devices. Final guidance, February 3, 2016. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices
• AAMI TIR57:2016 (R2023). Principles for medical device security, Risk management. Association for the Advancement of Medical Instrumentation.
• ANSI/AAMI SW96:2023. Standard for medical device security, Security risk management for device manufacturers. Association for the Advancement of Medical Instrumentation.
• MITRE and Medical Device Innovation Consortium. Playbook for Threat Modeling Medical Devices. November 2021. https://www.mitre.org/news-insights/publication/playbook-threat-modeling-medical-devices
• IEC 62366-1:2015. Medical devices, Part 1: Application of usability engineering to medical devices. https://www.iso.org/standard/63179.html
• ISO 14971:2019. Medical devices, Application of risk management to medical devices.
• Federal Food, Drug, and Cosmetic Act, Section 524B (21 U.S.C. 360n-2). https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title21-section360n-2&num=0&edition=prelim