What identity controls does the HIPAA Security Rule require?

The technical safeguards cover access control (unique user identification, an emergency access procedure, automatic logoff, and encryption), person or entity authentication to verify users are who they claim to be, and audit controls that record and examine access to systems holding ePHI. In practice that means unique identities, no shared logins, role-based access with reviews, and logged break-glass access.

Does HIPAA allow shared logins on clinical workstations?

Shared logins break the unique user identification requirement and the audit trail, because access to a record can no longer be attributed to one person. Healthcare teams solve the speed problem with badge tap-and-go and passwordless approaches built for shared workstations, giving fast re-authentication and automatic session termination without losing clinical context, instead of generic logins left open.

Is MFA required for HIPAA compliance?

The current Security Rule requires person or entity authentication rather than naming MFA, though HHS proposed requiring MFA in January 2025 and has not finalized that rule. MFA for remote and privileged access is what good practice looks like. In the August 2026 McKesson incident, McKesson confirmed that attackers targeted employee corporate accounts and took data from third-party applications; the attackers claim, without confirmation, that voice phishing yielded Okta credentials. Either way, phishing-resistant MFA, a help desk verification procedure, and step-up authentication on bulk data access are the controls that matter for ePHI.

How should emergency break-glass access work under HIPAA?

HIPAA requires an emergency access procedure, and it has to be usable by a clinician in a real emergency. Make the break-glass path controlled and fast, log every use, and review each use afterwards. Break-glass access that is neither logged nor reviewed is a common pitfall, because it leaves a path to ePHI with no attribution.

What is the most commonly missed HIPAA audit control in integrations?

Application service accounts that read patient records on a user's behalf without carrying that user's identity through. The audit controls safeguard means you must be able to answer who viewed this record and why years later, so every access to ePHI needs attribution to a unique human at the moment of access, retained and searchable.

HIPAA Identity Controls: Securing Access to ePHI

Identity Controls for HIPAA

By SWI Community Team · Updated 2026-11-05 · 10 min

HIPAA's Security Rule requires safeguards for electronic protected health information (ePHI), and its access-related standards are about identity: who can reach ePHI, how they are authenticated, and how access is controlled in fast-moving clinical settings.

What HIPAA expects of identity

The Security Rule's technical safeguards include:

Access control: unique user identification, emergency access procedure, automatic logoff, and encryption.
Person or entity authentication: verify that a user is who they claim to be.
Audit controls: record and examine access to systems with ePHI.

These sit in 45 CFR 164.312. The administrative safeguards add access authorization and access establishment and modification under 164.308(a)(4), which is where provisioning approvals and access reviews are anchored.

The proposed Security Rule update

HHS published a proposed rule to strengthen the Security Rule on 6 January 2025 (90 FR 898, RIN 0945-AA22; comments closed 7 March 2025). It would remove the distinction between required and addressable specifications and require MFA across relevant systems. It is not final: the Fall 2025 Unified Agenda lists it under long-term actions with a final action date of July 2027. The current rule still applies, but building to the proposal's MFA expectation now avoids rework. See the healthcare vertical for the wider regulatory picture.

What good looks like

Unique identities for every clinician and staff member, no shared logins, with MFA for remote and privileged access.
Fast, secure authentication suited to clinical workflows, where badge tap-and-go and passwordless reduce friction on shared workstations. This is why healthcare-specific access vendors exist.
Role-based access to ePHI with periodic access reviews, and prompt deprovisioning of leavers.
Emergency (break-glass) access that is controlled, logged, and reviewed.

Common pitfalls

Shared workstation logins that break unique-user attribution.
Standing broad access to ePHI without review, a common audit finding.
Break-glass access that is neither logged nor reviewed after use.

Healthcare vertical guide, IAM audit preparation. Vendors: IGA, MFA.

The audit-controls requirement is the architecture driver

Of HIPAA's technical safeguards, audit controls shape systems the most, because "who viewed this record and why" has to be answerable years later. That means access to ePHI needs attribution to a unique human at the moment of access, retained, and searchable.

Everything that breaks attribution breaks the control: shared workstation sessions left open, generic clinical logins, and application-level service accounts that read records on a user's behalf without carrying the user's identity through. That last one is the subtle case and the one most often missed in integration design.

Clinical workflow is the real constraint

Security controls that add seconds to a workflow repeated hundreds of times a shift do not survive, and clinicians will route around them. This is why badge tap-and-go and passwordless approaches specifically designed for shared workstations exist as a healthcare category, rather than being a generic MFA deployment.

Design for the shift, not for the audit: fast re-authentication on a shared terminal, automatic session termination that does not lose clinical context, and a break-glass path that a clinician can actually use in an emergency and that generates a reviewed record afterwards. See break-glass.

What incidents actually look like

Healthcare breaches in 2026 continued to run through identity rather than through exotic exploitation. In the August 2026 McKesson incident, McKesson confirmed a cybersecurity incident targeting employee corporate accounts, with unauthorized access to and exfiltration of data from third-party applications. The attackers, ShinyHunters, claim they voice-phished employees from a lookalike domain, took their Okta credentials, and used the single sign-on session to reach Salesforce and Snowflake; McKesson has not confirmed that chain (our coverage).

The controls that would have changed that outcome are the ones HIPAA already implies: phishing-resistant MFA so a relayed code is worthless, a help desk verification procedure that does not rely on caller-supplied facts, and step-up authentication on bulk data access.

Where to start

Inventory every path to ePHI. Clinical applications, shared workstations, integrations and service accounts, and vendor access, noting which ones carry a unique human identity through to the record.
Remove shared logins. Give every clinician and staff member a unique ID (164.312(a)(2)(i)), and use badge tap-and-go or passwordless re-authentication on shared terminals so speed does not depend on generic accounts.
Put MFA on remote and privileged access first, on phishing-resistant factors, in line with what the proposed rule would require.
Write down and test the emergency access procedure (164.312(a)(2)(ii)) as a break-glass path that is logged and reviewed after every use.
Anchor provisioning and reviews in policy under 164.308(a)(4): documented approval for each grant, periodic access reviews, and prompt deprovisioning of leavers.

Frequently asked questions

What identity controls does the HIPAA Security Rule require?: The technical safeguards cover access control (unique user identification, an emergency access procedure, automatic logoff, and encryption), person or entity authentication to verify users are who they claim to be, and audit controls that record and examine access to systems holding ePHI. In practice that means unique identities, no shared logins, role-based access with reviews, and logged break-glass access.
Does HIPAA allow shared logins on clinical workstations?: Shared logins break the unique user identification requirement and the audit trail, because access to a record can no longer be attributed to one person. Healthcare teams solve the speed problem with badge tap-and-go and passwordless approaches built for shared workstations, giving fast re-authentication and automatic session termination without losing clinical context, instead of generic logins left open.
Is MFA required for HIPAA compliance?: The current Security Rule requires person or entity authentication rather than naming MFA, though HHS proposed requiring MFA in January 2025 and has not finalized that rule. MFA for remote and privileged access is what good practice looks like. In the August 2026 McKesson incident, McKesson confirmed that attackers targeted employee corporate accounts and took data from third-party applications; the attackers claim, without confirmation, that voice phishing yielded Okta credentials. Either way, phishing-resistant MFA, a help desk verification procedure, and step-up authentication on bulk data access are the controls that matter for ePHI.
How should emergency break-glass access work under HIPAA?: HIPAA requires an emergency access procedure, and it has to be usable by a clinician in a real emergency. Make the break-glass path controlled and fast, log every use, and review each use afterwards. Break-glass access that is neither logged nor reviewed is a common pitfall, because it leaves a path to ePHI with no attribution.
What is the most commonly missed HIPAA audit control in integrations?: Application service accounts that read patient records on a user's behalf without carrying that user's identity through. The audit controls safeguard means you must be able to answer who viewed this record and why years later, so every access to ePHI needs attribution to a unique human at the moment of access, retained and searchable.