The HIPAA Security Rule NPRM Demands Cryptographic Safeguards the Current Rule Only Implies

The Department of Health and Human Services Office for Civil Rights issued a Notice of Proposed Rulemaking on December 27, 2024 to update the HIPAA Security Rule for the first time since 2003. The proposed rule was published in the Federal Register on January 6, 2025 with a 60-day comment period. OCR received approximately 4,700 comments. The OCR regulatory agenda lists May 2026 as the target publication date for the final rule, though OCR Director Paula Stannard has noted publicly that the comment review is ongoing and the timeline is not confirmed. Whether the final rule lands in May 2026 or later in the year, the substantive direction is clear, and the architectural implications for covered entities and business associates do not depend on the exact publication date.

The current Security Rule, codified at 45 CFR Part 164 Subpart C, divides safeguards into administrative, physical, and technical categories. The technical safeguards section, 164.312, lists encryption and decryption, access control, audit controls, integrity, and person or entity authentication. Each safeguard is currently characterized as either required or addressable. The addressable designation has produced two decades of risk analyses that conclude encryption is not reasonable and appropriate for the entity's circumstances, with the documented conclusion treated as compliance. The proposed rule closes this gap.

What the NPRM actually changes

The NPRM proposes to remove the addressable designation entirely. Every implementation specification becomes required. Encryption of ePHI at rest and in transit becomes a hard requirement, not a risk-based optional control. Multi-factor authentication becomes a hard requirement for access to systems handling ePHI. A technical asset inventory becomes a hard requirement, updated at defined intervals. Vulnerability scanning at defined intervals becomes a hard requirement. Audit and event logging requirements expand and tighten.

The proposed rule also introduces requirements that the current rule does not address at all. A network segmentation requirement separates systems handling ePHI from systems that do not. A patching cadence requirement mandates that critical vulnerabilities be remediated within defined windows. An anti-malware requirement extends to all systems handling ePHI. A compliance audit requirement obligates covered entities to conduct internal audits at least annually and obligates business associates to verify implementation of safeguards by their subcontractors.

The proposed standard compliance window is 180 days following the final rule's effective date. The NPRM's preamble acknowledges that the window may be insufficient for some safeguards and notes that OCR is considering extensions for specific requirements. Public comments have argued for substantially longer windows. The healthcare industry's response has consistently emphasized that the architectural changes the proposed rule requires cannot be implemented in 180 days from a current-state starting posture.

Why the architecture window is shorter than the regulatory window

The regulatory window is the time between final rule publication and compliance deadline. Under the proposed 180 days, that window is six months. The architectural window is the time required to actually build the controls the rule demands. For most covered entities, the architectural window is twelve to twenty-four months.

The gap is acute on three of the proposed safeguards.

The first is encryption at rest across the ePHI footprint. Most covered entities encrypt ePHI in their core electronic health record systems. Fewer encrypt ePHI in clinical data warehouses, in claims processing systems, in operational analytics, in research environments, and in backups. The proposed rule does not distinguish between these locations. The expectation is that every system holding ePHI applies validated encryption. The architectural work to inventory those systems, apply encryption at the storage layer, and verify the encryption survives operational workflows runs longer than 180 days for organizations starting from the current state.

The second is multi-factor authentication on every access path to ePHI. Most covered entities deploy MFA on remote access and on administrative consoles. Fewer deploy MFA on the clinical user paths where physicians, nurses, and clinical staff interact with the EHR. The clinical workflow constraints around MFA at the point of care are real and have driven the historical exception that the proposed rule eliminates. Closing the gap requires either a clinical workflow redesign or an authentication architecture that meets MFA standards without disrupting the workflow.

The third is the technical asset inventory and the network map. Most covered entities maintain inventories at the application or system level. The proposed rule requires an asset inventory at the technical asset level with the data flows between assets documented. The inventory has to be current and queryable, which means an automation pipeline, not a spreadsheet. The architecture work to instrument the environment and produce a defensible inventory runs longer than 180 days from a manual baseline.

Where data-centric architecture changes the math

The proposed safeguards converge on a single architectural property: ePHI has to be protected by controls bound to the data rather than to the perimeter around the data. Encryption at rest under validated modules. Access control evaluated against the principal at every read. Audit logs tied to the data object and the release event. Integrity protection that detects tampering against the object itself.

Data-centric zero trust architecture produces these properties natively. Each ePHI object carries its own encryption key and policy. Access requires attribute evaluation at the policy decision point. Every release writes an audit record to tamper-evident storage. The integrity of the object is verifiable through the cryptographic anchor.

Lattix Technologies binds policy to ePHI objects through attribute-based access control (ABAC) at the policy enforcement point, FIPS 140-3 validated cryptographic modules using ML-KEM-768 and ML-KEM-1024, and Merkle-tree lineage in tamper-evident audit storage. The architecture satisfies the proposed encryption-at-rest requirement at the object layer. It satisfies the proposed access control requirement through attribute-based evaluation at every release. It satisfies the proposed audit logging requirement through the lineage chain. It satisfies the proposed integrity requirement through the cryptographic anchor on each object.

The architectural posture also addresses one of the NPRM's underlying motivations. OCR's enforcement record through 2024 and 2025 documented repeated findings against covered entities whose encryption was in place but whose access controls did not prevent unauthorized internal access, whose audit logs did not capture the access events at the granularity that investigations required, or whose security architecture did not survive a ransomware event. The OCR enforcement language in the Anthem, Premera, Excellus, and 2024 Lehigh Valley Health Network settlements consistently cited the gap between an attested control and the actual data exposure. Data-centric controls close the gap by producing the evidence the proposed rule will require at every access.

What covered entities and business associates should do now

The final rule may publish in May 2026, in late 2026, or later. The substantive direction is settled regardless. The covered entities and business associates that begin architectural work in Q2 2026 will face the final rule's compliance window with the work underway. Those that wait for the final rule to publish before starting work will face the 180-day window with the work ahead of them.

Three priorities matter inside the window.

The first is the ePHI inventory. The organization needs to identify every system, environment, and data store that holds ePHI. The inventory has to be at the asset level the proposed rule will require, not at the system level the current rule has tolerated. The inventory is the foundation for every subsequent control decision.

The second is the encryption posture against the inventory. The organization needs to determine whether ePHI in each identified location is protected by validated encryption traceable to the data object, or by perimeter encryption that depends on the surrounding system to enforce confidentiality. Perimeter encryption is the architecture the proposed rule moves away from. Object-level encryption is the architecture the proposed rule converges on.

The third is the audit and access control instrumentation. The organization needs to determine whether existing audit logs capture access events at the granularity the proposed rule expects, and whether existing access controls evaluate attributes at read time rather than enforcing identity-only authorization. Where current controls fall short, the architecture work is the work the proposed rule will require regardless of which exact compliance window the final rule sets.

The final rule will publish on a schedule OCR controls. The architecture has to be built on a schedule the covered entity controls. The work to build it does not depend on which month the final rule lands.

References

• HHS OCR Notice of Proposed Rulemaking, HIPAA Security Rule Update (Federal Register Vol. 90, No. 4)
• 45 CFR Part 164, Subpart C, Security Standards for the Protection of Electronic Protected Health Information (eCFR)
• HHS OCR Regulatory Initiatives Page
• HHS OCR Enforcement Highlights and Resolution Agreements
• NIST SP 800-66 Revision 2, Implementing the HIPAA Security Rule
• NIST SP 800-207, Zero Trust Architecture
• NIST CMVP, Cryptographic Module Validation Program