Multi-Factor Authentication

The multi-factor authentication requirement in HICP Practice 3.2 means you must enforce MFA for (1) all remote access, (2) all privileged accounts, and (3) any access to systems that contain PHI, so passwords alone cannot grant entry. Operationalize it by defining MFA scope, selecting approved authentication methods, enforcing through your IdP/VPN/EHR gateways, and retaining proof that MFA is technically enforced and monitored. ¹

Key takeaways:

• MFA is mandatory for remote access, privileged accounts, and any system containing PHI under HICP Practice 3.2. ¹
• Auditors care less about policy language and more about technical enforcement evidence (IdP settings, conditional access rules, and access logs).
• Treat “PHI systems” broadly: EHR, billing, imaging, data warehouses, backups, and any hosted app where PHI is stored or accessible.

HICP Practice 3.2 is a straightforward control with tricky edges: scope and enforcement. The text is short, but you still need crisp operational definitions to avoid gaps (for example, MFA is enabled for VPN but not for remote EHR access, or “privileged” is interpreted as only domain admins). The fastest path is to translate the requirement into three scoped enforcement domains: remote access entry points, privileged identities, and PHI system access paths.

As a Compliance Officer, CCO, or GRC lead, your job is to make sure “MFA required” becomes demonstrably true in production. That means you need (1) an inventory of in-scope systems and identities, (2) a technical control that forces MFA and cannot be bypassed through legacy protocols or service accounts, (3) exceptions that are rare, time-bound, and approved, and (4) evidence that stands up in an assessment.

This page gives requirement-level implementation guidance you can hand to IAM, IT, and Security Operations, plus an evidence checklist you can use to validate readiness. All guidance is anchored to HICP Practice 3.2. ¹

Regulatory text

HICP Practice 3.2: “Require multi-factor authentication (MFA) for all remote access, privileged accounts, and access to systems containing PHI.” ¹

Operator interpretation (what you must make true):

1. Remote access cannot complete with only a password. Any off-network access path (VPN, VDI, remote desktop gateways, remote admin tools, SaaS admin portals used remotely) must require a second factor.
2. Privileged accounts must always use MFA. Administrative roles (system, database, cloud, security tooling, EHR admin, network devices) must be MFA-protected even on internal networks.
3. Systems containing PHI must enforce MFA for access. If a system stores or exposes PHI, access to that system must require MFA, not just “SSO is enabled.”

This is an enforcement requirement. A policy that “recommends MFA” or a partial rollout does not meet the text. ¹

Plain-English requirement interpretation

You need to stop single-factor logins (password-only) for the most breach-prone access patterns:

• People logging in from outside your controlled network.
• Accounts that can change configurations, create users, disable logging, or access large datasets.
• Any system where PHI exists or can be reached.

In practice, MFA should be enforced at the identity layer (IdP/SSO/conditional access) wherever possible, and at the system layer where direct logins still occur (local admin, break-glass workflows, device consoles, legacy apps).

Who it applies to (entity and operational context)

Entity types in scope: Healthcare organizations and health IT vendors. ¹

Operational contexts you should assume are in scope:

• Workforce access (employees, clinicians, call centers, billing teams).
• Third-party access (MSPs, revenue cycle partners, EHR support, device vendors, consultants) where they remote in or hold privileged roles.
• Cloud and SaaS administration (cloud consoles, tenant admin roles).
• On-prem administration (AD/domain admin, virtualization, storage, network devices).
• Clinical applications and data platforms (EHR/EMR, PACS/imaging, lab systems, claims/billing, analytics warehouses) that contain or can retrieve PHI.

What you actually need to do (step-by-step)

1) Define the MFA scope in operational terms

Create three lists and get them approved by Security + Compliance:

• Remote access entry points: VPN, ZTNA, VDI, SSH/RDP gateways, remote support tools, externally reachable admin panels.
• Privileged identities: roles/groups in AD, cloud IAM, EHR admin, database admins, firewall admins, CI/CD admins, security admins.
• PHI systems: applications, databases, file shares, data lakes, backups, and managed services that store PHI or provide query access to PHI.

Deliverable: a one-page scoping memo that maps each list to “MFA enforcement point” (IdP rule, system config, PAM, VPN setting).

2) Choose approved MFA methods and ban weak fallbacks

Write an “Accepted MFA Methods Standard” that engineering can implement without interpretation disputes:

• Prefer phishing-resistant methods where your environment supports them (for example, platform authenticators or hardware-backed approaches).
• Prohibit shared factors (one token used by multiple people), and prohibit “MFA” that is just knowledge-based questions.

You do not need to name every technology in the policy, but you must be explicit about what is allowed and what is not.

3) Enforce MFA centrally using your IdP/SSO conditional access

For modern apps, the cleanest evidence comes from IdP enforcement:

• Require MFA for all remote access (condition: off-network, unknown device, or any internet-based login).
• Require MFA for privileged roles (condition: role membership, admin portal access, step-up auth).
• Require MFA for PHI apps (condition: app assignment, SSO app, network location).

Hardening checks that often surface in audits:

• Disable legacy authentication protocols that bypass MFA (where feasible).
• Require re-authentication for sensitive actions (admin console changes, exporting PHI reports).
• Confirm device enrollment or compliant device posture if your risk model supports it.

4) Cover the “non-SSO” edge cases explicitly

Most MFA failures happen where SSO does not exist:

• Local accounts on servers, network devices, appliances.
• Service accounts and API tokens.
• EHR or clinical systems with embedded admin accounts.
• Break-glass accounts.

Controls that work in practice:

• Put privileged interactive access behind a PAM or jump host that enforces MFA.
• Convert standalone apps to SSO where possible, or enforce MFA at the application layer.
• Replace shared admin accounts with named accounts and enforce MFA on each identity.
• For break-glass, use tightly controlled storage, monitoring, and documented emergency procedures.

5) Operationalize exceptions (rare, time-bound, and provable)

You will encounter systems that cannot support MFA immediately. Handle this with an exceptions process that does not become permanent scope erosion:

• Require documented compensating controls (network isolation, jump host, PAM, restricted source IPs, enhanced logging).
• Require a remediation plan and an owner.
• Require approval by Security and Compliance, plus periodic review.

6) Monitor and test the control

Minimum operational checks:

• Alert on MFA disabled for privileged users.
• Alert on privileged logins without MFA (where your logging supports it).
• Review logs for anomalous remote access patterns.
• Periodically test: a controlled attempt to access in-scope systems without completing MFA should fail.

7) Extend requirements to third parties

If third parties access your environment or PHI systems:

• Contractually require MFA for remote access and privileged access.
• Enforce it technically through federated identity, your ZTNA/VPN, or a controlled jump host.
• Do not rely on a third party’s attestation alone when you can enforce in your control plane.

Practical tool note: teams using Daydream typically centralize third-party access evidence (access methods, MFA enforcement proofs, and exceptions) alongside due diligence artifacts, which reduces scramble during assessments.

Required evidence and artifacts to retain

Keep evidence that proves technical enforcement, scope, and operations:

Governance

• MFA policy and MFA methods standard.
• Scope inventory: remote entry points, privileged roles/groups, PHI systems list.
• Exceptions register with approvals and compensating controls.

Technical configuration evidence

• Screenshots/exports of IdP conditional access rules requiring MFA for targeted apps/roles.
• VPN/ZTNA configuration showing MFA requirement.
• PAM/jump host configuration showing MFA requirement for admin access.
• System configuration evidence for non-SSO PHI systems (application settings, admin console configs).

Operational evidence

• Authentication logs demonstrating MFA challenges and successful completions for in-scope access paths.
• Sample access reviews showing privileged accounts are identified and governed.
• Incident/ticket records showing response to MFA bypass attempts or misconfigurations.

Common exam/audit questions and hangups

Expect these questions, and prepare “show me” answers:

• “List all systems containing PHI and show how MFA is enforced for each.”
• “Show that all privileged accounts require MFA, including cloud admins and EHR admins.”
• “How do you prevent bypass via legacy authentication or shared accounts?”
• “How do third parties connect, and where is MFA enforced?”
• “Provide the exception list and demonstrate time-bound remediation.”

Hangup pattern: auditors often reject “MFA is available” or “MFA is enabled for most users.” They look for enforced and complete for the defined scope aligned to remote, privileged, and PHI systems. ¹

Frequent implementation mistakes and how to avoid them

1. Mistake: MFA only on VPN, not on SaaS/EHR direct access.
   Fix: enforce at IdP and require SSO for PHI apps where possible; otherwise enforce app-level MFA.

2. Mistake: Privileged accounts excluded because they are “internal.”
   Fix: privileged always means MFA, regardless of network location. ¹

3. Mistake: Shared admin accounts or generic logins.
   Fix: require named admin identities; put emergency access behind a break-glass process.

4. Mistake: Service accounts treated as “privileged users” and forced into MFA, breaking automation.
   Fix: separate interactive privileged access from non-interactive service authentication; control service accounts with secrets management, scoping, and monitoring.

5. Mistake: Exceptions with no exit plan.
   Fix: require compensating controls plus a dated remediation plan and periodic review.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not cite specific actions. Operationally, MFA gaps increase the likelihood that stolen credentials (phished passwords, credential stuffing, reused passwords) lead directly to remote access, privileged access, or PHI access, which are the exact three categories HICP Practice 3.2 targets. ¹

Practical execution plan (30/60/90-day)

You can run MFA rollout in phased milestones without pretending every system can be fixed at once.

First 30 days (stabilize scope + quick wins)

• Publish MFA policy, MFA methods standard, and exception template.
• Inventory remote entry points, privileged roles, and PHI systems.
• Enforce MFA on your primary remote access path (VPN/ZTNA/VDI) and IdP for common remote logins.
• Enforce MFA for top-tier privileged roles (directory admins, cloud admins, security admins).
• Stand up logging and a basic alert for MFA being disabled on privileged accounts.

By 60 days (close bypass routes + PHI app coverage)

• Expand MFA enforcement to all privileged roles, including app-specific admins (EHR, billing, data platform).
• Move PHI applications to SSO where feasible; enforce MFA at the IdP for those apps.
• Implement a jump host or PAM pattern for systems that cannot do MFA natively.
• Formalize third-party remote access: require MFA and remove unmanaged direct connections where possible.
• Start a standing exceptions review with owners and compensating controls.

By 90 days (prove repeatability)

• Validate that every PHI system has an identified enforcement point and retained configuration evidence.
• Run an access-path test: confirm password-only access fails for remote, privileged, and PHI system scenarios.
• Tighten monitoring: reporting for privileged logins, anomalous remote access, and changes to MFA policies.
• Package an “audit-ready MFA binder”: scope lists, configs, exception register, sample logs, and change records.

Frequently Asked Questions

Does “remote access” mean only VPN?

No. Treat remote access as any access path from outside your controlled network or security boundary, including SaaS admin portals, remote support tools, and remote desktop gateways. Your evidence should show MFA is enforced at each entry point in your environment. ¹

What counts as a “privileged account” for MFA enforcement?

Any account with administrative control or elevated permissions over systems, security settings, identity, or data access should be treated as privileged. Document the roles/groups you consider privileged and enforce MFA for those identities. ¹

If we have SSO, do we still need MFA on the application itself?

If the application always authenticates through the IdP and the IdP rule enforces MFA, that usually becomes your primary enforcement point and evidence source. If the app allows local logins or legacy auth, you must control those paths or they will bypass MFA.

How do we handle systems containing PHI that cannot support MFA?

Use a documented exception with compensating controls such as access through a jump host/PAM that enforces MFA, strict network restrictions, and enhanced monitoring. Track an owner and a remediation plan so the exception does not become permanent. ¹

Do third parties have to follow this MFA requirement?

If third parties access your environment remotely, hold privileged accounts, or access systems containing PHI, they fall into the same risk categories. Build MFA requirements into contracts and, where possible, enforce MFA through your access gateways or federated identity rather than relying only on attestations. ¹

What evidence is strongest in an audit?

Configuration exports or screenshots showing enforced MFA rules (IdP conditional access, VPN/ZTNA settings, PAM policies) plus authentication logs proving MFA challenges occur for in-scope access. Pair that with a scoped inventory and an exceptions register that has approvals and compensating controls.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices