How should healthcare security teams reduce identity risk on legacy medical devices that cannot support MFA?

Healthcare teams should treat legacy devices as identity risk surfaces, not just asset-management problems. The practical approach is to inventory device-linked accounts, restrict access by behavior and necessity, and add compensating controls around authentication and privilege. Because many devices cannot be upgraded for MFA, protections must focus on least privilege, monitoring, and blocking unusual access attempts before they reach patient-facing systems.

Why Legacy Devices Become Identity Risk Hotspots

Legacy medical devices become identity risk hotspots when their access model cannot evolve as fast as the environment around them. If MFA cannot be added, the team is left with weaker controls at the exact point where a device may still touch patient care, clinical workflows, or sensitive systems. The security problem is not the device alone, it is the account, session, privilege path, and exception handling around it.

That is why identity risk on these devices should be treated as a control-design issue, not a patching issue. The most useful benchmark is often visibility, because organisations that cannot see device-linked accounts, shared access paths, or unused privileges cannot meaningfully limit them. NHI security research shows that only 1.5 out of 10 organisations are highly confident in securing non-human identities, which is a useful signal for any environment where devices depend on durable credentials and legacy access paths. In practice, teams usually discover the weakest identity path only after it has already become the easiest operational workaround.

How to Reduce Risk Without MFA

The first step is to inventory every device-linked account and classify what each one can reach. Separate service access, vendor access, maintenance access, and break-glass use, then remove standing access wherever the workflow allows it. For legacy devices, the control objective is not perfect identity modernisation, but reducing how far a compromised account can move and how long it can remain useful.

Restrict access to named users or tightly controlled jump paths instead of broad shared credentials.
Bind access to device behavior, source network, time window, and approved maintenance context.
Rotate credentials on a defined schedule, and immediately after vendor support events or staff turnover.
Log every successful and failed device login, then alert on unusual source, timing, or sequence patterns.
Segment the device so the account cannot laterally reach EHR, PACS, or administrative systems.

Compensating controls matter most when they are layered, because no single control replaces MFA cleanly. Stronger authentication at the gateway, least privilege at the account level, and monitoring at the session level should work together. If the device itself cannot challenge the user, then the surrounding environment must challenge the access path. The NHI breach research is a reminder of why this matters, since two-thirds of enterprises reported a successful cyberattack resulting from compromised non-human identities, which is exactly the kind of failure mode legacy device credentials can create.

These controls tend to break down when clinical teams rely on shared passwords for urgent workflows because exceptions quickly become the normal access path.

Common Exceptions and Trade-offs in Clinical Environments

Tighter access control often increases operational friction, so hospitals have to balance clinical availability against exposure. The hardest cases are devices used by many staff, devices maintained by third parties, and devices that are embedded in regulated vendor workflows. In those environments, the goal is usually not to eliminate every exception, but to make each exception explicit, time-bound, and observable.

There is no universal standard for every legacy device pattern, but current guidance suggests treating shared access as a temporary risk acceptance decision rather than a default operating model. If a device cannot support MFA, then the compensating design should become more specific, not more vague: narrow the account scope, narrow the network path, and narrow the approved use case. Where a vendor insists on remote service access, teams should require a separate access method, clear approval chain, and audit trail rather than reusing production credentials. For broader control alignment, the NIST Cybersecurity Framework 2.0 is useful for structuring governance, and the NIST SP 800-82 Rev 3, OT Security Guide is a strong companion where devices behave like operational technology assets.

When the same credential can unlock maintenance, administration, and patient-facing systems, the residual risk is usually too high for a broad exception.

Risk and Threat Considerations

Legacy medical devices create concentrated identity exposure because a single credential or shared access path may govern long-lived operational access. That makes them attractive to attackers seeking persistence, lateral movement, or quiet misuse of trusted access, especially where monitoring is weak and credential rotation is infrequent.

Failure mechanism: Compromise usually occurs through stolen passwords, reused vendor credentials, weak segmentation, or over-privileged shared accounts. Once inside, the attacker does not need to defeat the device, only the trust placed in the account and the network path around it.

Impact: The result can be unauthorized access to device functions, movement into adjacent clinical systems, disruption of care workflows, or exposure of sensitive patient environments. If access is not tightly bounded, a legacy device becomes a durable foothold rather than a single isolated asset.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC-1 — Identity Management, Authentication and Access Control	Legacy device access depends on account and session control.
	DE.CM-1 — Monitoring and Logging	Legacy device accounts need unusual access detection and auditability.
	PR.PT-4 — Communications and Control Networks	Segmenting legacy devices limits lateral movement from compromised access.
Recommendation — Restrict device accounts to the minimum authenticated access required. Log device logins and alert on abnormal source, timing, or sequence patterns. Segment legacy devices so compromised accounts cannot reach adjacent systems.
CIS Controls v8	6.3 — Authentication and Authorization Management	Compensating access controls are the core mitigation when MFA is unavailable.
	8.2 — Audit Log Management	Logging and review are needed to catch misuse of durable device credentials.
	12.1 — Network Infrastructure Management	Network restrictions reduce the blast radius of a legacy device compromise.
Recommendation — Tighten account scope and remove unnecessary access paths for legacy devices. Capture and review device authentication events for suspicious access. Constrain device reachability with network segmentation and approved access paths.
NIST SP 800-63	AAL2 — Authenticator Assurance Level 2	Illustrates the assurance gap when legacy devices cannot support stronger authentication.
	CSP2 — Credential Lifecycle Management	Legacy device credentials need disciplined rotation and revocation.
Recommendation — Use compensating controls to narrow access where the device cannot meet stronger assurance. Rotate and revoke device credentials on a defined lifecycle, especially after exceptions.

Practitioner Guidance

What to prioritise: Start with the devices whose accounts can reach the widest set of systems or support the most critical clinical workflows. Those are the access paths where a compromise creates the largest blast radius, so they deserve the strongest monitoring and the tightest exception handling first.

Decision rule: If an account is shared, long-lived, or usable outside a narrow maintenance window, treat it as high risk until the workflow is redesigned. If you cannot narrow the credential scope, narrow the network scope and increase alerting on unusual use patterns.

What good looks like: Every legacy device should have an owner, a purpose, a known credential lifecycle, and a clear record of who can use it and why. Good control is visible when access can be explained in minutes, not reconstructed after an incident.

Practitioner takeaway: The safest legacy-device pattern is not perfect modern authentication, it is tightly bounded access with enough visibility to detect when the old credential model starts behaving like an attack path.