Medical Device Authentication and Access Control | Blue Goat

Part of our FDA 2026 medical device cybersecurity submission series. For the full overview, start with FDA Cybersecurity Requirements for Medical Devices (2026).

Reviewed September 17, 2026

A medical device that cannot prove who issued a command is a device that cannot prove the command was safe. Attackers who gain access to an infusion pump, imaging console, or hospital network gateway rarely need to break a cryptographic algorithm. They need a hardcoded password, a shared service account, or a role that grants more privilege than the job requires. These are design decisions, not accidents, and reviewers at the FDA now treat them as gating issues under Section 524B of the FD&C Act. Manufacturers who cannot show a role and privilege matrix, credential lifecycle plan, and tamper-evident audit trail are increasingly seeing these gaps surface as Additional Information requests during 510(k) and PMA review. This page consolidates what manufacturers need to know about authentication, authorization, and accountability for connected medical devices, including biometrics, credential storage, and the logging evidence that supports nonrepudiation.

Why This Matters

Authentication and access control failures are not abstract IT risk in a medical device. A compromised login on an infusion pump or a surgical robot console can lead to altered dosing, falsified diagnostic results, or an unauthorized firmware push. That is why the FDA folded authentication and authorization into its core premarket cybersecurity expectations rather than treating them as optional hardening.

Under the February 3, 2026 final guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," reviewers expect authentication and access control to be treated the same way software lifecycle requirements are treated under IEC 62304: as design-controlled engineering artifacts with traceable requirements, verification tests, and residual risk documentation. AAMI's SW96 standard, recognized by the FDA under recognition number 13-131, gives manufacturers a structured way to document these controls inside a security risk management file.

The FDA's own performance data shows cybersecurity deficiencies, including access control gaps, are among the top categories cited in 510(k) and PMA Additional Information letters. Manufacturers who treat authentication as a checkbox rather than a threat-modeled control tend to discover the gap only after a reviewer flags it, which adds review cycles and delays clearance. Building the evidence up front, tied to a real role and privilege matrix and a tested credential lifecycle, is the difference between a smooth review and a stalled one.

Authentication vs Authorization vs Accountability

Authentication, authorization, and accountability are three separate controls that get conflated in casual conversation but must be documented separately for the FDA. Authentication answers "who or what is this." Authorization answers "what is this identity allowed to do." Accountability answers "what did this identity actually do, and can we prove it."

The FDA's guidance splits authentication further into two categories: entity authentication, which verifies the identity of a user or connected device, and data authentication, which verifies that information has not been altered and originated from a trusted source. A device can authenticate a clinician correctly and still fail if it cannot prove a firmware image or sensor reading is genuine.

[KEY REQUIREMENT] Premarket submissions should document authentication, authorization, and accountability as three distinct control categories, each with its own threat model entries, design requirements, and verification evidence. Treating them as one bundled "login system" is a common source of reviewer questions.

What the February 3, 2026 Guidance Expects

The February 3, 2026 final guidance expects manufacturers to show authentication and access control as part of a Secure Product Development Framework, not as a bolt-on feature. This guidance is the current version in a chain that started with draft guidance in September 2023 and an interim update in June 2025 before finalizing this year.

Reviewers want to see multi-factor authentication for privileged and remote access paths, unique credentials per user or per device, automatic session timeouts, and a "deny by default" posture for unrecognized connections. They also expect a documented privilege matrix showing which roles can perform which actions, and evidence that authorization checks are enforced at the device or server layer rather than only hidden in a user interface.

For credential management specifically, the guidance expects a defined lifecycle: how credentials are provisioned, rotated, revoked, and recovered, including for service and maintenance accounts that rarely get the same scrutiny as clinician logins. Nonrepudiation evidence, meaning logs and signatures that tie an action back to a specific identity without possibility of denial, rounds out the expected control set.

[KEY REQUIREMENT] A credential lifecycle plan covering provisioning, rotation, revocation, and emergency recovery is expected documentation, not an optional appendix, and it must explicitly cover service and maintenance accounts.

Hardcoded Credentials, Shared Accounts, and Service Accounts

Hardcoded credentials remain one of the most common and most damaging findings in medical device security assessments because they cannot be changed without a firmware update. A single hardcoded password shared across every unit of a product line means one leaked credential compromises the entire fleet, not one device.

Shared accounts create a related but distinct problem: they destroy accountability. If three clinicians or two service technicians use the same login, an audit log showing "admin logged in and changed therapy limits" cannot identify who actually made the change, which defeats the nonrepudiation goal the FDA expects logging to support.

Service and maintenance accounts deserve particular attention because they are often the highest-privilege accounts in the system and the least monitored. These accounts are frequently long-lived, shared across a field service team, and exempted from the password policies applied to clinical users. A threat actor who compromises a service account often inherits capabilities well beyond what any clinical role would ever need.

[KEY REQUIREMENT] Every account, including service and maintenance accounts, needs a unique identity, a defined privilege scope, and a rotation or expiration policy. Shared or hardcoded credentials should be treated as a design defect to remediate before submission, not a known limitation to disclose.

Biometrics in Clinical Settings: Benefits and Spoofing Limits

Biometric authentication, including fingerprint and iris recognition, improves usability in clinical settings where clinicians move between devices quickly and cannot type long passwords in gloves. It is not, however, immune to spoofing, and the FDA expects that limitation to be threat-modeled rather than ignored.

Textured contact lenses have been demonstrated to interfere with older or poorly configured iris recognition systems, and photographs or masks have similarly been used against facial recognition systems lacking liveness detection. Modern Presentation Attack Detection, defined under ISO/IEC 30107-3, substantially reduces this risk, but only when it is actually implemented, validated with adversarial test cases, and not just assumed to work because the vendor's marketing says so.

The practical takeaway for manufacturers is that biometrics should support, not replace, layered authentication for high-risk functions such as changing therapy limits or pushing firmware. Every biometric implementation needs a documented fallback authentication method for when the sensor fails or is unavailable, and biometric templates need hardware-backed secure storage so they cannot be extracted and replayed.

[KEY REQUIREMENT] Threat models for biometric authentication must include presentation attack scenarios and document PAD verification results, template storage design, and a fallback authentication path, not just normal-use accuracy rates.

Designing Roles and Privileges: Permissions vs Rights

See also: SweynTooth BLE Vulnerability in Medical Devices, Home Use vs Hospital Device Cybersecurity Requirements, and Indications for Use, Predicates, and Cybersecurity Scope.

Rights and permissions are related but distinct concepts, and conflating them is a common source of over-privileged roles. Rights define policy-level intent, such as "clinicians can configure therapy settings." Permissions are the specific, enforceable actions that implement that intent, such as "can change dose limits" or "can view configuration history."

If a manufacturer only defines rights and skips the permission-level breakdown, roles tend to become bundles of unrelated capabilities granted for convenience. A field service role built to run diagnostics can end up able to disable safety checks simply because no one separated "can initiate self-test" from "can modify safety parameters" at the permission level.

Role-based access control combined with scoped permissions is the model that scales best across a device UI, a cloud portal, APIs, and service tooling. Adding step-up authentication for high-impact actions, and time-bound elevation for service workflows, closes the gap between what a role is broadly trusted to do and what a specific action should require in the moment.

[KEY REQUIREMENT] A role and permission matrix, tested with server-side enforcement checks rather than interface-only restrictions, is standard evidence reviewers expect for access control claims in a premarket submission.

Offline vs Online Password Attacks and Credential Storage

Online and offline password attacks require different defenses, and confusing the two leads manufacturers to over-invest in one while leaving the other exposed. Online attacks, such as password spraying or credential stuffing, hit a live login interface and can be slowed with rate limiting, account lockouts, and multi-factor authentication. Offline attacks happen after an attacker has already stolen a password database or extracted credentials from firmware, and they crack hashes on their own hardware with no interaction with the device at all.

Offline attacks do not trigger lockouts or alerts because the device is never contacted again after the theft. Resistance to them depends almost entirely on password storage design: whether the manufacturer used a purpose-built password hashing algorithm with unique salts and an appropriately tuned work factor, rather than a fast general-purpose hash or, worse, reversible encryption.

For medical devices specifically, the credential stores most often overlooked are firmware images, configuration backups, and manufacturing or service databases, not just the clinician-facing login. A penetration test that only exercises the login screen misses the offline exposure entirely.

[KEY REQUIREMENT] Password storage should use a modern, purpose-built hashing algorithm with unique per-user salts and work factors sized to current attacker hardware, verified as part of the same testing that covers online lockout and MFA behavior.

Logging That Actually Supports Nonrepudiation

Nonrepudiation means an identity cannot credibly deny having performed an action, and that guarantee only holds if the underlying logs are complete and tamper-evident. A log that records "admin changed configuration" without a unique actor identity, an accurate timestamp, and protection against after-the-fact editing cannot support an investigation or a regulatory inquiry.

Effective nonrepudiation logging captures the actor, the action, the affected object, the outcome, and the timestamp for every privileged action, not just failed login attempts. Digital signatures on log entries, secure timestamping, and write-once or cryptographically chained storage prevent an attacker who gains access from quietly editing the trail behind them.

This matters across the entire product lifecycle. Premarket, it validates that software updates and diagnostic outputs are authentic. Postmarket, it is often the only evidence available to reconstruct what happened during an incident or to support a recall investigation.

[KEY REQUIREMENT] Audit logs for privileged actions should be cryptographically protected against tampering and tested for completeness, since a log that can be silently edited provides no real nonrepudiation evidence during an FDA inquiry or postmarket investigation.

How Blue Goat Cyber Approaches This

Blue Goat Cyber's medical device practice treats authentication, authorization, and audit logging as design-controlled engineering outputs rather than a submission checklist. Every access control claim gets tied to a threat model entry, a verification test, and a documented residual risk in the security risk assessment, so the evidence traces cleanly from requirement to result.

Engagements test both the online attack surface, including MFA, lockout behavior, and role enforcement, and the offline exposure in credential stores extracted from firmware, configuration files, and backups. Testers hold CISSP and OSCP certifications, with backgrounds that include military red-team operations. See our medical device penetration testing services for the full scope of how access control and credential storage get validated before submission.

Frequently Asked Questions

What is the difference between authentication and authorization in medical devices?

Authentication verifies who or what is connecting to a device, using a password, token, certificate, or biometric. Authorization decides what that verified identity is allowed to do once connected, typically enforced through role-based permissions and least-privilege rules. A device can authenticate correctly and still fail if authorization checks are missing or only enforced in the interface rather than the server or device logic.

Does the FDA require multi-factor authentication on medical devices?

The February 3, 2026 final guidance recommends multi-factor authentication for privileged and remote access paths as a baseline expectation, particularly for administrative, service, and cloud accounts. It is not an absolute mandate for every interaction, but manufacturers who skip MFA on high-risk functions should expect reviewers to ask why, and should document a compensating control if MFA is not feasible.

Are biometrics secure enough for medical device authentication?

Biometrics can be secure when implemented with Presentation Attack Detection, hardware-backed template storage, and a documented fallback authentication method. They should not be the sole control for high-risk functions like changing therapy settings or pushing firmware. Manufacturers need adversarial spoofing test evidence, not just normal-use accuracy data, to support a biometric authentication claim.

What is the difference between offline and online password attacks?

Online attacks hit a live login interface and can be slowed with rate limiting, lockouts, and MFA. Offline attacks happen after an attacker steals a password database or extracts credentials from firmware, then cracks the hashes on their own hardware without touching the device again. Offline resistance depends on password storage design, specifically modern hashing algorithms with unique salts, not on login-page defenses.

Why do hardcoded and shared credentials keep showing up in FDA deficiency letters?

Hardcoded credentials cannot be changed without a firmware update, so one leaked password compromises every unit in the field. Shared accounts destroy the audit trail because a log entry cannot identify which specific person performed an action. Both undermine the accountability and nonrepudiation evidence the FDA expects, which is why reviewers flag them repeatedly.

CTA

If your device's authentication, access control, or audit logging design has open questions ahead of a submission, a discovery session can identify the gaps before a reviewer does. Book a Discovery Session to review your access control architecture and evidence plan with our team.