What changed in HIPAA's 2024 Security Rule update (and what your file-sharing stack needs to do about it)

In December 2023, the Department of Health and Human Services published an NPRM — a Notice of Proposed Rulemaking — proposing the most significant revisions to the HIPAA Security Rule since the rule was finalized in 2003. If you work in compliance at a covered entity or business associate, you should be planning for these changes now, not when the final rule drops.

This post is a working walkthrough. We’re not going to recite the rule text back at you — the Federal Register has that. What we’re going to do is translate the proposed changes into practical implications for the file-handling controls your team actually manages.

What the NPRM proposes

The 2024 NPRM addresses a foundational problem: the Security Rule was written when the threat environment was dramatically different. “Addressable” implementation specifications — a category that allowed covered entities to assess whether a safeguard was reasonable and appropriate rather than required — made sense in 2003. In 2024, OCR’s enforcement pattern has made clear that many of those addressable items are functionally required in any reasonable risk analysis.

The proposed changes do three things structurally. They convert several previously addressable specifications to required. They add specificity to existing requirements — moving from “implement encryption as appropriate” toward explicit minimum standards. And they add new requirements that didn’t exist in the original rule, reflecting 20 years of evolved threat landscape.

Specific proposals of note:

• Required technology asset inventories. Covered entities would be required to maintain a current, documented inventory of all technology assets that handle ePHI — not just systems but integrations, data flows, and third-party connectors.
• Documented network map. A written, up-to-date map of how ePHI moves through and between systems.
• Vulnerability scanning requirements. Semi-annual vulnerability scans of network-accessible systems and annual penetration testing are proposed as required rather than addressable.
• Response plan specificity. The NPRM proposes more granular requirements for incident response plans, including documented recovery time objectives.
• Business associate oversight tightening. Covered entities would be required to verify BA compliance with specific controls, not just obtain attestations.

The technical safeguards section, line by line

Section §164.312 covers technical safeguards, and this is where file-sharing vendors and the teams that manage them need to pay closest attention.

Access controls (§164.312(a)). The NPRM reinforces multi-factor authentication for access to systems handling ePHI. If your file-transfer platform handles PHI and doesn’t require MFA, that gap is increasingly untenable under any reasonable risk analysis — and will likely be explicitly required in the final rule.

Audit controls (§164.312(b)). The proposal strengthens the logging requirements with specificity about what must be captured. Log records should identify the individual, the action taken, the specific data element affected, and the timestamp. “File accessed” with a username is no longer sufficient; you need “this specific file containing these record types was accessed by this authenticated identity via this mechanism at this time.”

Integrity (§164.312(c)). The proposed rule would add an explicit requirement for mechanisms to authenticate ePHI at rest — not just in transit. This means cryptographic verification that stored data hasn’t been altered, which maps to hash verification, digital signatures, or equivalent controls on stored PHI.

Transmission security (§164.312(e)). The NPRM would make encryption of ePHI in transit required, removing the “addressable” classification. The proposed language references industry-standard encryption without mandating specific cipher suites, but OCR’s enforcement history suggests TLS 1.2 minimum, TLS 1.3 preferred, with documented rationale for any legacy protocol use.

Encryption at rest: the big shift

The most significant practical change in the NPRM for file-sharing stacks is the movement of encryption at rest from an addressable specification toward an expected baseline. The proposed language doesn’t create an absolute encryption-at-rest mandate in all circumstances, but it narrows the conditions under which a covered entity can credibly document that encryption at rest is not reasonable and appropriate.

In practice, this means: if your file-transfer vendor stores ePHI at rest without encryption, your risk analysis needs to justify that explicitly. OCR’s recent enforcement settlements have consistently cited inadequate encryption as a contributing factor. The NPRM essentially codifies what OCR has been signaling through enforcement.

Encryption at rest, in the context of file transfer, means two things: the file content is encrypted in storage, and the key management controls are documented and auditable. Vendor-managed encryption keys satisfy the first requirement but create a key-custody dependency. Customer-managed keys, as we’ve described in other posts, provide the stronger posture: you control the keys, so vendor-side compromise doesn’t automatically decrypt your data.

What teams should do this quarter

The NPRM is in proposed form, and the final rule will take time to publish and take effect. But the direction is clear enough to act on now, and the controls proposed are things you should have regardless of where the rulemaking lands.

Inventory your ePHI data flows. Start with the asset inventory and network map the NPRM describes. You probably have a version of this somewhere; the question is whether it’s current and complete enough to defend in an OCR investigation. If your file-transfer vendor is in the data flow, it needs to be in the map.

Audit your BA agreements against the proposed BA oversight requirements. The NPRM signals that attestation alone won’t be sufficient — covered entities will need to verify. Pull your BAA with your file-transfer vendor and check whether it includes the specific technical controls the NPRM references.

Confirm MFA status across all ePHI-handling systems. If any path to PHI doesn’t require MFA, document the risk decision explicitly and add it to your remediation backlog. Don’t wait for the final rule.

Review audit log coverage. Map your current log coverage against §164.312(b) as proposed. Can you produce, for any file transfer over the last 12 months, a record that identifies the individual, the specific file, and the access mechanism? If not, that’s a gap to close.

Check your encryption-at-rest documentation. For every system in your ePHI inventory, document the encryption-at-rest posture and the key management model. If a vendor holds your keys, decide whether that’s the posture you want to defend.

The 2024 NPRM is the clearest signal in two decades that HHS views the current Security Rule as underspecified for the threat environment. Planning now costs less than remediating after the final rule takes effect.