Does HIPAA require multi-factor authentication today?
No, the current Security Rule does not name multi-factor authentication. The standard in 45 CFR 164.312(d) requires procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. It does not mention MFA, password rules or any specific method. The proposed rule published on January 6, 2025 (90 FR 898) would change that by requiring MFA on all technology assets in relevant electronic information systems, with limited exceptions, and by renaming the authentication standard. That proposal was not final as of October 2026, so covered entities and business associates should treat it as a direction of travel, not an obligation they can cite today. Confirm the current status in the Federal Register and the Unified Agenda before relying on either reading in a contract or policy.
Whether MFA is the right answer for a given organization depends on its own risk analysis. An entity that documents exposure to credential attacks, such as remote access to a hosted EHR, web portals that accept patient logins, or shared administrative accounts, will have a stronger case for MFA on those paths than one whose ePHI sits behind a closed network with few external logins. The decisions to record include which systems and roles are in scope, which factors are used to verify identity, what happens when a factor is unavailable, and why any weaker method was judged reasonable and appropriate. Where a verification method is treated as addressable, the entity must document its reasoning and any equivalent measure. For the wider policy context, see the password and risk analysis sections on this page.
The organization owns this decision and the documentation behind it. A implementation partner can configure identity providers, collect logs and assemble the evidence that each authentication path works as written, but it cannot make the risk call for the covered entity. Only an independent auditor or assessor can test the result and issue an opinion on it. HIPAA has no certificate: HHS states that no Security Rule standard requires certification and that it does not recognize private certifications, so any vendor offering a HIPAA-certified MFA stamp is offering something HHS does not issue. Ask any provider for the specific Security Rule provisions their work addresses and for the evidence that would be presented to an assessor.
How OCR and HHS frame authentication today
OCR does not publish a standalone MFA rule for HIPAA today. Its guidance, enforcement record and audit program instead show how authentication failures are treated: as gaps in risk analysis, access control and activity review. The four cards below cover the sources to read before deciding how your organization will verify who is accessing ePHI.
OCR newsletter on authentication
OCR's June 2023 cybersecurity newsletter addressed authentication as a Security Rule topic. Read it to see how OCR frames verifying that a user is who they claim to be under the access and authentication requirements. Check whether your current log-in process, including MFA on remote and privileged access, matches the approach the newsletter describes. Confirm the newsletter is still the latest OCR material on authentication before citing it in a policy.
Risk analysis tied to authentication
OCR's enforcement record repeatedly cites failures in risk analysis and risk management. In the Warby Parker penalty, credential stuffing against customer accounts was paired with findings on those two areas. For authentication, this means your risk analysis should name each path that grants access to ePHI, including web portals, APIs and remote admin tools, and record how each one verifies identity. Document the residual risk where a password alone is still accepted.
Audit focus on hacking and ransomware
OCR's 2024 to 2025 HIPAA audit program reviews 50 covered entities' and business associates' compliance with the Security Rule provisions most relevant to hacking and ransomware. Account takeover is a common route into these incidents, so auditors may ask how access is verified and how that verification is evidenced. Prepare your access control, authentication configuration and access review records so they can be shown quickly. Confirm the audit scope and protocols on the OCR audit page before preparing.
Confirm current HHS guidance
HHS publishes Security Rule guidance material, including newsletters and reference documents, on a page that is updated over time. Authentication recommendations may change as new issues are published, and the proposed rule would add an MFA requirement that is not yet final. Before relying on any statement about authentication, review the guidance index, note the newsletter dates and check whether a final rule has been published. Record the date you checked so your policy reflects the version you relied on.
What the Warby Parker penalty shows about credential attacks
The Warby Parker case shows that credential attacks become a HIPAA enforcement matter when the surrounding controls fail to notice and contain them. Between September and November 2018, attackers used credential stuffing, replaying usernames and passwords taken from other breaches, and gained access to the accounts of 197,986 individuals. On February 20, 2025, HHS announced a $1,500,000 civil money penalty after OCR investigated. OCR's findings, as HHS described them, centered on failures in risk analysis, risk management and information system activity review. The published summary does not report that OCR cited a missing multi-factor authentication control, so do not read the penalty as a finding about MFA alone.
The practical lesson is that credential reuse has to be detected and limited at several points. Before an incident, your risk analysis should name where account logins are exposed, including customer portals, patient-facing apps and remote access, and rate the likelihood of reused passwords against them. Your risk management plan should then assign controls to those findings, such as login throttling, lockout thresholds, blocking of known-breached passwords and alerts on unusual login patterns. MFA is one of those controls, and it does not replace the others. A login that succeeds with a stolen password and a second factor you never reviewed is still a login your monitoring must catch.
Ask two questions of your own environment before deciding what to implement. First, can your team show the login events, failed attempts and account-lockout records for the 2018-style window, and does someone review them on a schedule? Second, does your risk analysis document how each authentication path was evaluated, including any path without MFA and the reason it remains? Confirm these answers with your security officer and your outside assessor, and keep the records. OCR's own enforcement record shows that gaps in those reviews, rather than the absence of one named technology, drove the outcome in this case.
Which MFA method fits which environment
CISA's position is that phishing-resistant MFA is the standard all industry leaders should strive for. Phishing-resistant methods bind the authentication to the legitimate site, so a captured one-time code or push approval cannot be replayed on a lookalike login page. CISA describes FIDO/WebAuthn as the only widely available phishing-resistant option, which makes it the default target for most modern deployments.
- Hardware security keys: FIDO2 keys used with WebAuthn give the strongest binding and suit administrators, clinicians with shared workstations and anyone with privileged access.
- Platform authenticators: Built-in device biometrics or device-bound credentials can meet the same goal on managed devices, provided the device is itself protected.
- Enrollment controls: Require identity proofing before a key is issued and a documented recovery path that does not fall back to weaker methods.
- Coverage gaps: Confirm that every application, VPN and remote access path accepts the chosen method, because a single password-only entry point undermines the rest.
- Evidence: Keep the enrollment list, policy settings and sign-in logs that show which users authenticate with which method.
Before you commit, confirm with each identity provider and application vendor that the method is supported in your own tenant and version.
Where phishing-resistant MFA is not yet feasible, CISA suggests number matching as a stronger alternative to simple push approval. The user sees a code on the sign-in screen and must enter it in the authenticator app, which makes it harder for an attacker to trick someone into approving a prompt they did not start. This is a transitional control, not an end state, and it should be recorded as such in your risk analysis.
- Push fatigue: Simple approve or deny prompts can be abused by repeated requests, so number matching is the minimum for push-based apps.
- Time limits: Set a plan to move these users to phishing-resistant methods, with a named owner and review date.
- Risk acceptance: Document why the phishing-resistant option is not yet feasible and what compensating measures apply, such as session limits and monitoring.
- Monitoring: Review denied and unexpected prompts in your sign-in logs, since they can signal an active attack.
- Evidence: Retain the policy configuration, the risk decision and the migration plan.
Confirm with your identity vendor that number matching is enabled and cannot be bypassed by a user-selected setting.
CISA states that any MFA is better than none. For systems where stronger methods are not yet practical, a second factor such as a one-time code still raises the cost of credential theft and makes simple password reuse less useful to an attacker. This tab covers the baseline you should not fall below, regardless of your long-term target.
- Minimum coverage: Apply some second factor to remote access, email, administrative consoles and any system holding ePHI that users reach from outside the network.
- Known weak points: One-time codes can be phished in real time, so treat them as a floor rather than a destination.
- Password dependence: Keep the first factor in place, because MFA does not replace the need for strong password management and unique user IDs.
- Exceptions register: Track every account that cannot meet the baseline, with its owner and expiry.
- Evidence: Show the coverage report mapping each application to its second factor.
Ask your identity provider which factor types are available for each application before you set the policy.
Many clinical devices, imaging systems, older electronic health record modules and medical equipment were not built for modern authentication. The vendor may support only local passwords, shared accounts or a fixed set of identity integrations. The Security Rule still applies to these systems because they hold or access ePHI, so the question becomes how to add authentication safely around the constraint and document the decision.
- Vendor support: Ask the vendor in writing which authentication methods the specific model and software version supports, and whether a patch or upgrade enables more.
- Compensating controls: Use network segmentation, jump hosts or a brokered access gateway in front of the device so that users authenticate with MFA before reaching it.
- Shared accounts: Avoid shared credentials where the device allows individual logins, since unique user identification is a separate Security Rule requirement.
- Clinical workflow: Test that any added step does not delay patient care or push staff toward workarounds such as sharing sessions.
- Evidence: Record the vendor's written statement, the compensating control design and the risk acceptance signed by the accountable owner.
Confirm vendor support in your own environment, because the answer depends on the exact product, version and configuration you run.
What the proposed rule would change for MFA
The January 6, 2025 proposed Security Rule revision (90 FR 898, RIN 0945-AA22) would turn today's general authentication requirement into a specific mandate for multi-factor authentication. The proposal renames the authentication standard to proposed 164.312(f)(1) and requires MFA on all technology assets in relevant electronic information systems, subject to limited exceptions. HHS accepted public comments until March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda entry for RIN 0945-AA22 lists final action as projected for July 2027. The proposal is not current law, and the timing could change.
Plan for the requirement without treating it as settled. The practical first step is an inventory of every system that touches ePHI, including servers, network devices, cloud consoles, remote access gateways, backup platforms and administrative tools, because the proposal reaches all technology assets in scope, not only user-facing applications. For each asset, record whether MFA is already enforced, which factor types are used, and who can bypass it. Where an exception might apply, document the reasoning now so it can be defended later. Confirm the final text, exceptions and effective dates against the Federal Register and the Unified Agenda before you commit budget, since the wording may change between proposal and final rule.
Treat the current rule and the proposal as two separate questions. Today, the Security Rule requires procedures to verify identity but does not name MFA, so your obligation rests on the risk analysis and on the addressable or required decisions you document. If your organization is planning MFA rollouts now, you can align them with the proposal's direction while keeping your written justification tied to the current text. Ask your legal or compliance counsel to confirm how the proposal would apply to your entity type and whether any business associate agreements you hold would need updating once a final rule issues.
How to prepare authentication evidence before an assessment
This sequence turns an authentication requirement into records an assessor can test, starting from the systems that hold ePHI and ending with a independent review of the proof. It works whether or not the proposed MFA requirement is finalized, because the current rule already requires procedures that verify who is seeking access.
Inventory ePHI systems and login paths
The security official, with system owners from IT and clinical operations, lists every system that creates, receives, maintains or transmits ePHI. For each system, record every way a person or service signs in, including administrative consoles, remote access, VPNs, email, mobile apps, service accounts and vendor-managed access. The output is an authentication inventory that names the system, the login path, the account types and the owner. The step is complete when system owners have confirmed the list and no login path is recorded as unknown.
Document the authentication decision in the risk analysis
Record how each login path verifies identity and why that method was chosen, and tie it to the threats identified in the risk analysis. Note the current verification procedure required under 45 CFR 164.312(d) and any gaps the risk analysis found. The output is a dated risk analysis entry per system, with an assigned risk rating and a named risk management action. The step is complete when each path in the inventory has a corresponding decision and the security official has signed off.
Enable and test MFA on priority systems
Starting with systems that have remote access, administrative privileges or the largest ePHI populations, the IT team turns on multi-factor authentication and tests it with real user scenarios, including enrollment, sign-in, lockout and recovery. Where phishing-resistant options are not yet feasible, CISA's guidance points to number matching as a reasonable interim step, and FIDO/WebAuthn is the phishing-resistant option it describes as widely available. The output is a configuration record and a test log showing each system's result. The step is complete when test results are saved and any failures have a tracked fix.
Record exceptions and compensating controls
Where MFA cannot be enabled on a system, such as legacy applications or certain medical devices, document the reason, the risk accepted, the compensating controls in place and the person who approved the exception. Compensating controls might include network segmentation, restricted access paths or additional monitoring, but each must be described and tested, not assumed. The output is an exception register with an owner and review date for each item. The step is complete when every system without MFA appears in the register with a documented decision.
Retain logs that show enforcement
Configure identity providers and key systems to keep sign-in records, MFA challenge results, failed attempts and account lockouts, and set retention long enough to cover the period an assessor will review. Confirm with counsel or your compliance lead how long records must be kept under your own policies and the documentation rules in 45 CFR 164.316. The output is a sample of logs that show MFA was challenged and enforced for real accounts. The step is complete when someone outside the team can pull the sample without help from the administrator who configured it.
Have a reviewer test the evidence
An internal reviewer who did not configure the controls, or an outside assessor if you engage one, selects a sample of users and systems and tries to trace each one from the inventory to the risk analysis, the configuration, the test results and the logs. The reviewer records any gap, such as an account that bypasses MFA without an exception. The output is a short findings list with owners and corrective actions. The step is complete when the findings are closed or accepted in writing. Remember that an assessor or auditor issues any formal report, and an implementation partner or internal team only prepares the evidence.
Who owns the MFA decision, the build and the proof
Multi-factor authentication under HIPAA touches four parties with different jobs. The covered entity or business associate keeps the control and the risk decision, while staff run the rollout, a partner configures systems within scope, and an independent assessor tests the result. Keeping these roles separate prevents the common mistake of treating a vendor's configuration as proof of compliance.
The organization owns the control
The covered entity or business associate is legally responsible for its Security Rule safeguards, including how it verifies that a person or entity seeking access to ePHI is the one claimed. Leadership decides whether MFA applies to remote access, email, EHR logins and administrator accounts, and whether any addressable alternative is reasonable and appropriate. Document that decision in writing, with the reasoning, because an addressable specification that is not implemented requires a documented rationale and an equivalent measure. Confirm who signs off on that record before any build starts.
Internal staff run the rollout
Internal IT and security staff own daily operation: enrolling users, managing lost devices, handling help desk resets, and reviewing authentication failures in logs. They also decide which factor types are acceptable for each user group and who approves exceptions. Ask who will perform these tasks after handover, because an MFA deployment that nobody maintains tends to drift back to passwords alone during staff turnover. Check that help desk procedures verify identity before resetting a second factor.
A partner configures and documents
An implementation partner such as DeployOpen can configure identity systems, integrate MFA with self-hosted platforms, test the configuration and prepare the evidence package within an agreed written scope. It does not decide whether the organization's risk is acceptable, and it does not attest to compliance. Ask for a deliverables list that names the configuration baselines, screenshots or exports, test records and runbooks, and confirm who keeps the system after the engagement ends.
An independent assessor tests and reports
Only an independent auditor, assessor or certification body can test the controls and issue any report. HHS states that it does not endorse or recognize private certifications, and that no Security Rule standard requires certification, so a HIPAA certificate from any firm carries no federal weight. Expect an assessor to sample user accounts, check MFA enforcement on remote and administrative access, and review the documented decision. Ask any assessor exactly which evidence it will examine before engagement.
Questions buyers ask about HIPAA MFA
Is multi-factor authentication legally required under HIPAA today?
Not by name. The current Security Rule does not use the words multi-factor authentication, but it requires procedures to verify that a person or entity seeking access to ePHI is the one claimed (45 CFR 164.312(d)). The rule defines authentication as corroborating that a person is who they claim to be (45 CFR 164.304). The standard is technology neutral, so you decide how to meet it through a documented risk analysis. Where that analysis shows that passwords alone leave ePHI exposed to remote access, cloud consoles or email, MFA becomes the expected control. The January 2025 proposed rule would require MFA explicitly, but it had not been finalized as of October 2026. Today, MFA is a risk-driven decision that you must document.
Does HIPAA name a specific MFA product or method?
No. The Security Rule does not name a vendor, token type or authentication method. It sets an outcome: verify identity before granting access to ePHI. The method is your decision, and it should follow from your risk analysis. CISA states that phishing-resistant MFA is the standard all industry leaders should strive for, that any MFA is better than none, and that FIDO/WebAuthn is the only widely available phishing-resistant option it describes. Where phishing-resistant MFA is not yet feasible, CISA suggests number matching as a step up. Treat these as reference points that inform your risk analysis. Record why you chose each method, including its limits for remote and shared-workstation access, and confirm current vendor capabilities with each supplier before you commit.
What does an OCR investigation look for on authentication?
OCR looks for evidence that you identified the risk to ePHI access, chose controls to address it, and monitored whether those controls work. In its February 20, 2025 resolution with Warby Parker, OCR cited credential stuffing between September and November 2018 that gave attackers access to the accounts of 197,986 individuals, and imposed a $1,500,000 civil money penalty. OCR found failures in risk analysis, risk management and information system activity review. Expect requests for your risk analysis, access policies, login monitoring records and incident documentation. Investigators will ask how you detected unusual logins, whether you limited repeated failed attempts, and who reviewed the logs. Documented review of sign-in activity matters as much as the control itself.
Can our own staff implement MFA for ePHI systems?
Often yes, if your team can administer your identity provider, VPN, EHR access and cloud consoles. Implementation involves enrolling users, setting policies for every system that holds or reaches ePHI, handling lost devices and account recovery, and testing that emergency access accounts still work. The harder work is documentation: a risk analysis entry, written access procedures, enrollment records and staff training. Costs are mainly staff time and any MFA service licensing, and licensing and support recur. Ask whether your team can cover all access paths, including legacy applications that may not support MFA natively. A fixed-scope engagement sets scope, deliverables and timelines in writing before work starts. Either way, the security official should own the decision and sign off on the risk acceptance.
What does a partner deliver, and what does the auditor issue?
A partner prepares systems and evidence, and the independent auditor issues any report. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure. Within a written scope, it can prepare authentication configuration, access records and supporting evidence for a compliance assessment. Your organization owns its controls and makes the MFA method and risk decisions. DeployOpen does not issue audit reports, attestations or certifications. An independent assessor performs the testing and reports on it. Ask any partner to state in writing which deliverables are configuration, documentation and test support, and which belong to the assessor. Cost depends on the scope agreed in writing, including the number of systems, identity sources and documentation volume.
Does a third-party assessment or certificate prove HIPAA compliance?
No. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private organizations' certifications, and that such certifications do not prevent HHS from later finding a violation (HHS FAQ 2003). A third-party assessment can show that controls were tested at a point in time and which gaps were found. It does not shield you from an OCR complaint or audit. OCR's 2024 to 2025 HIPAA audits review 50 covered entities' and business associates' compliance with provisions most relevant to hacking and ransomware. Penalties are assessed per violation, and for penalties assessed on or after January 28, 2026, the inflation-adjusted range runs from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3).
How DeployOpen prepares MFA and authentication evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the authentication layer that controls access to systems holding ePHI. We prepare the configuration and evidence an independent assessor would review, while your organization keeps ownership of its safeguards and the final compliance decision.
How we scope
- We map which systems hold or reach ePHI and where each user signs in today.
- The written scope names the identity components, MFA methods and user groups covered before work starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any build begins.
How we build
- We configure MFA enforcement, unique user IDs and login monitoring on the self-hosted platforms in scope.
- We run authentication tests against the configured systems to confirm MFA cannot be bypassed by ordinary users.
- We document each setting and its reason so your team can explain the design to an auditor or OCR.
How we hand over
- You receive configuration records, test results and a written description of how each authentication control works.
- Evidence is organized against the Security Rule provisions in the agreed scope, with gaps listed plainly.
- Your staff are walked through the runbooks so they can operate and review the controls without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover MFA changes when platforms are upgraded or when the final HIPAA rule changes requirements.
- Confirm with your assessor which evidence they expect, since DeployOpen prepares evidence but does not issue reports or attestations.
Sources and further reading
- 45 CFR 164.312(d), person or entity authentication ↗
- 45 CFR 164.308(a)(5)(ii)(D), password management ↗
- HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule ↗
- NIST SP 800-66 Rev. 2, Implementing the HIPAA Security Rule ↗
- CISA: More than a password (multifactor authentication) ↗
- HHS press release: OCR penalty against Warby Parker ↗
