The two most operationally disruptive parts of the proposed HIPAA Security Rule are the mandatory encryption and multi-factor authentication requirements. Both exist in some form today, but the NPRM sharply narrows the room organizations have used to avoid full deployment.

For IT, security, compliance, and engineering teams, these are not minor policy changes. They affect infrastructure choices, access models, endpoint management, key management, and workforce training. This is where many organizations will feel the NPRM first.

---

Encryption Moves from Flexible to Expected

Under the current Security Rule, encryption appears as an addressable implementation specification in both access controls and transmission security. That means it is not truly optional, but it has allowed organizations to argue that other controls made full encryption unnecessary in their environment.

In practice, that flexibility has been used to justify unencrypted databases, unencrypted internal traffic, weak email protections, and unmanaged endpoint storage. OCR has challenged that posture in enforcement, but the current structure has still left room for organizations to document around the control.

The NPRM largely closes that door. Encryption of ePHI at rest and in transit becomes a required implementation expectation, with only narrow exception pathways tied to the risk analysis.

---

What Systems This Actually Reaches

For most organizations, the scope is broad. It includes ePHI in primary databases and data stores, traffic moving between services, email and file transfer workflows, endpoint devices such as laptops and mobile devices, backups and archives, and any other electronic media containing ePHI.

The NPRM does not prescribe one exact technical standard, but the practical baseline is clear: strong modern encryption at rest and strong TLS for data in transit, aligned with current NIST guidance and current industry practice.

---

What to Audit for Encryption Right Now

Start with a system-by-system encryption audit. For each environment that stores, processes, or transmits ePHI, document whether encryption is enabled at rest, what algorithm and key length are in use, whether transit encryption is enforced, how keys are stored and rotated, and where unencrypted gaps still exist.

Common failures include databases without transparent data encryption, internal service traffic still using unencrypted connections, email systems that do not enforce TLS, backup media storing ePHI without encryption, employee devices without full-disk encryption, and vendor or partner file transfers still using insecure protocols.

---

Encryption Priorities by Environment

• Cloud-hosted ePHI: verify encryption is actually enabled across storage, databases, and file systems, not just available by default.
• Databases: enable transparent data encryption where supported or plan for application-layer controls or migration where it is not.
• Transit encryption: enforce TLS 1.2 or later externally and internally for any ePHI-related communication path.
• Endpoints: require full-disk encryption through managed device policies for every device that can access ePHI.
• Email and file exchange: enforce secure transmission and remove unencrypted legacy processes.
• Key management: tighten storage, access controls, rotation, and recovery procedures around encryption keys.

---

MFA Stops Being Implied and Starts Becoming Explicit

The current rule requires organizations to verify that a person or entity seeking access to ePHI is the one claimed. That requirement is broad enough to include MFA, but broad enough that many organizations still rely on username-and-password authentication alone.

The NPRM changes that by explicitly requiring multi-factor authentication for access to ePHI and relevant electronic information systems. That is a major shift because it removes the argument that single-factor authentication can still be justified through documentation alone.

---

Where MFA Needs to Be Applied

The impact goes beyond the application that directly stores ePHI. Under the NPRM's broader view of relevant systems, MFA should extend to identity providers, cloud management consoles, admin panels, VPNs, remote access tools, and any system whose compromise could affect ePHI confidentiality, integrity, or availability.

That means security teams need an access inventory, not just an application inventory.

---

What to Audit for MFA Right Now

For each relevant system, determine whether MFA is enabled, what method is used, whether it is required for all users or only privileged accounts, whether it can be bypassed through exceptions or weak fallback processes, and whether the chosen method is resistant to phishing and social engineering attacks.

This is where many organizations discover partial deployment. MFA might be enforced on the SSO platform but not on cloud consoles, or on admins but not workforce users, or on web apps but not VPN access. Partial coverage is not the target state the NPRM is pointing toward.

---

MFA Implementation Priorities

• Identity provider and SSO: highest leverage point for broad MFA enforcement.
• Cloud consoles: require MFA for all users, with hardware tokens for root and privileged accounts.
• Application-level access: enforce MFA on systems that directly expose ePHI.
• VPN and remote access: remove single-factor exceptions.
• Service accounts and APIs: apply equivalent authentication protections such as short-lived tokens, mutual TLS, IP restrictions, and strong secret management.

Method selection matters. SMS is better than nothing, but authenticator apps and hardware keys are stronger. For privileged access, phishing-resistant hardware keys are the better standard.

---

Encryption and MFA Are Meant to Work Together

These controls solve different problems. Encryption protects ePHI at the data layer when it is stored or transmitted. MFA protects the identities and sessions that access the systems holding that data.

A system with strong encryption but weak authentication can still be compromised through stolen credentials. A system with strong MFA but weak or missing encryption still leaves data exposed if devices, backups, or traffic are compromised. The NPRM's posture is layered defense, not pick-one compliance.

---

The Training Requirement Still Matters

Neither control succeeds as a purely technical deployment. The workforce needs to understand how encryption works in the actual environment, which approved channels must be used for ePHI, how MFA enrollment and recovery work, and how to recognize attacks such as MFA fatigue and push-notification abuse.

Generic awareness is not enough. Teams need organization-specific training: which applications are federated through your identity provider, how endpoint encryption is enforced on your managed devices, how secure file transfer works in your environment, and what to do if authentication or encryption controls appear to fail.

---

Why the Timeline Matters Now

There is no reason to wait for a final rule to start. Encryption and MFA are already defensible security expectations under the current risk-management framework, and both should surface in any serious risk analysis.

The organizations that move now get time to test, train, and stabilize. The organizations that wait for the final deadline will be trying to implement core controls under pressure, alongside everyone else competing for the same engineering attention and vendor support.

---

Iron Fort helps teams connect technical safeguards such as encryption and MFA to organization-specific training, policies, and evidence. That turns control deployment into an operational compliance program instead of a last-minute scramble.

This article is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for guidance specific to your organization.