By Vitalii Chetak
Last Updated: July 21, 2026
Quick Answer
HHS has proposed the largest overhaul of the HIPAA Security Rule since 2013. The NPRM, published in the Federal Register on January 6, 2025, would remove the "addressable" designation that let organizations treat safeguards as flexible, making encryption of ePHI at rest and in transit mandatory, requiring multi-factor authentication for systems that access ePHI, and adding operational requirements including annual penetration testing, twice-yearly vulnerability scans, a 72-hour restoration standard, and written annual verification of safeguards from business associates. As of July 2026 the rule remains proposed: the comment period closed March 7, 2025 with more than 4,700 comments, the spring 2026 finalization window passed, and OMB's Unified Agenda now targets July 2027 for final action. Once a final rule publishes, most organizations would have roughly 240 days to comply, which is why healthcare IT teams are aligning to the proposed requirements now.
For twenty years, healthcare organizations have been able to look at encryption and answer "we assessed it and chose an alternative." The proposed Security Rule update ends that conversation. This article covers what the NPRM actually changes, where the rulemaking stands today, why the compliance clock will be short once it starts, and what the new requirements mean specifically at the file access layer, where ePHI moves between file servers, clinicians, billing staff, and business associates every day.
Where the rule stands right now
Precision matters here, because much of the coverage blurs the line between proposed and final. The Office for Civil Rights at HHS published the Notice of Proposed Rulemaking, titled HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, in the Federal Register on January 6, 2025. The public comment period closed on March 7, 2025, and OCR received more than 4,700 comments. That is where the formal record stops. No final rule has been issued.
The timeline has also moved. OCR's regulatory agenda originally pointed to finalization in spring 2026. That window passed, and the current OMB Unified Agenda entry for the rulemaking (RIN 0945-AA22) targets July 2027 for final action. A broad coalition of hospitals, health systems, and provider associations has asked HHS to withdraw or substantially revise the proposal, arguing that the cost and prescriptiveness are unworkable for small and rural providers. HHS itself estimated first-year compliance costs across regulated entities at roughly $9 billion. Some requirements may change in the final rule, and the date may move again.
None of that is a reason to file this under "later," for three reasons. First, the compliance runway will be short: as proposed, the rule takes effect 60 days after publication and most provisions require compliance 180 days after that, roughly 240 days end to end, with business associate agreements updated within one year. Organizations that start their asset inventory the day the final rule publishes will spend that runway discovering problems. Second, OCR enforcement already treats unencrypted ePHI harshly under the current rule; breach settlements involving lost laptops and unencrypted file transfers predate this NPRM by a decade. Third, the direction is unambiguous. Encryption and MFA are the floor of every other modern security framework, and the comment record contains almost no opposition to the substance of those two controls, only to their cost and timeline.
The end of "addressable"
Since 2003, Security Rule implementation specifications have come in two types. Required meant implement it. Addressable meant assess whether it is reasonable and appropriate for your environment, and if you decide it is not, implement an equivalent alternative or document why neither is necessary. In practice, addressable drifted into meaning optional, with organizations documenting that encryption at rest was too expensive or that MFA was too disruptive for clinical workflows, and assessors accepting the paperwork in place of the control.
The NPRM removes the distinction almost entirely. With limited exceptions, implementation specifications become mandatory, and the documentation that used to satisfy an addressable safeguard would no longer substitute for the control itself.
| Safeguard | Current Security Rule | As proposed in the NPRM |
|---|---|---|
| Encryption of ePHI at rest | Addressable; alternatives permitted with documentation | Required, with limited exceptions |
| Encryption of ePHI in transit | Addressable; alternatives permitted with documentation | Required, with limited exceptions |
| Multi-factor authentication | Not explicitly required; password-only access can be compliant | Required for systems accessing ePHI, with limited exceptions and documented compensating controls where technically infeasible |
| Asset inventory and network map | Implied by risk analysis; no explicit interval | Required, updated at least every 12 months |
| Vulnerability scanning | Not explicitly required | Required at least every 6 months |
| Penetration testing | Not explicitly required | Required at least annually |
| Network segmentation | Not explicitly required | Required |
| Restoration of systems and data | Contingency plan required; no defined timeframe | Restoration of critical systems and data within 72 hours |
| Business associate safeguard verification | Contractual assurances via the BAA | Annual written verification that technical safeguards are deployed, supported by expert attestation |
What mandatory encryption means at the file access layer
The encryption requirement is the change with the widest blast radius, because ePHI at rest lives in more places than most inventories admit: EHR databases, file servers holding scanned records and imaging exports, billing spreadsheets on department shares, backups, and the laptops of remote coders and billing staff.
The proposed requirement covers both states. At rest means the storage itself: file server volumes, databases, backups, and endpoints. In transit means every path ePHI travels: email, APIs, system-to-system interfaces, and remote file access sessions. Under the current rule, OCR's breach history already shows where the exposure concentrates, and it is rarely the EHR. It is the unencrypted laptop, the file transfer over an unsecured channel, and the department file share reached over a remote access method nobody has reviewed since it was set up.
For file access specifically, that translates into two concrete obligations. Every remote session that opens, previews, or transfers a file containing ePHI must run over encrypted transport, TLS 1.2 or higher in practice. And the storage where those files live must be encrypted at rest, which for Windows file server environments typically means BitLocker or storage-level encryption applied to the volumes you already own. Organizations that have sprawled ePHI across consumer-grade sync tools, legacy FTP, and ad hoc sharing links face a mapping exercise before they face an encryption exercise, because you cannot encrypt what you have not located. This is one place where reducing the number of systems that touch ePHI pays off directly: every additional platform holding patient files is another entry in the asset inventory, another encryption boundary to verify, and another business associate to manage.
What mandatory MFA means for clinical and administrative access
The NPRM requires multi-factor authentication for access to systems containing ePHI, with limited exceptions and documented compensating controls where MFA is technically infeasible. The scope language matters: this reaches beyond the EHR login to every system where ePHI is accessed, which includes remote file access for billing teams, transcription vendors, and administrative staff working from home.
Password-only remote access to a file server holding patient records is exactly the pattern this provision targets. The workable implementation for most healthcare organizations is to enforce MFA at the identity provider, through Entra ID Conditional Access, Duo, Okta, or an equivalent, so that one MFA policy covers every application that authenticates through it. Bolting separate MFA onto each system individually multiplies both cost and the audit surface a verifier has to walk through.
The operational requirements arriving with it
Encryption and MFA get the headlines, but the operational provisions will consume more calendar time for many organizations. The annual asset inventory and network map requirement forces a documented answer to "where is our ePHI" every 12 months. The 72-hour restoration standard turns disaster recovery from a binder on a shelf into a tested capability with a deadline, and organizations that cannot demonstrate restoration of critical systems within that window today need to redesign backup architecture, which has procurement lead times measured in months. The business associate verification requirement runs in both directions: covered entities must collect annual written verification that their BAs have deployed the required technical safeguards, and business associates should expect their healthcare customers to start demanding that attestation ahead of the rule, because contract cycles move slower than regulations.
Where a self-hosted file access layer fits
A disclosure before the product discussion: MyWorkDrive is a self-hosted file access product, and this section explains how its architecture maps to the proposed requirements. The honest framing is the same one we apply to CMMC: no product makes an organization HIPAA compliant. Compliance belongs to the covered entity or business associate, and every vendor claim should be read against a shared responsibility model that says who owns which safeguard.
With that stated, the architecture decisions that matter under the proposed rule are about where ePHI lives and how many parties touch it. In a self-hosted MyWorkDrive deployment, patient files stay on your existing Windows file servers or Microsoft 365 tenant, and no file content is stored at rest on MyWorkDrive servers. Encryption at rest is applied by you, on storage you control, using BitLocker or your storage platform's encryption, which keeps the at-rest obligation inside infrastructure you already manage. Remote sessions run over TLS 1.2 or higher on port 443, covering the in-transit requirement for file access without VPN infrastructure, and our earlier analysis of why VPNs create HIPAA compliance problems covers the audit and segmentation weaknesses of the VPN pattern in detail. MFA arrives through your identity provider, with support for Entra ID, Duo, Okta, and other SAML and OIDC providers, so the MFA policy your EHR uses can govern file access too. Every file action is logged with SIEM export over Syslog, which feeds the audit and verification evidence the rule expects. MyWorkDrive is SOC 2 Type II certified and executes Business Associate Agreements on request.
The consolidation effect is the underrated part. Each sync tool, FTP server, and sharing platform in your environment is a separate line in the asset inventory, a separate encryption verification, and in many cases a separate BAA with its own annual attestation under the proposed rule. Collapsing remote file access to a single audited entry point with DLP controls shrinks the surface that every one of those requirements applies to.
What to do before the final rule
Build the ePHI asset inventory first
Every other requirement depends on it. Inventory the systems that store or access ePHI, including file shares, backups, endpoints, and every remote access path. The proposed rule would require this map to be refreshed every 12 months, so build it as a maintained artifact with an owner, and treat any system that cannot be encrypted or put behind MFA as a candidate for retirement.
Close the encryption gaps you already know about
Volume encryption on file servers and full-disk encryption on endpoints are the highest-yield moves, and both are enforceable today with tooling most organizations already license. Verify TLS versions on every remote access path, and retire transfer methods that cannot meet TLS 1.2, including legacy FTP.
Put MFA in front of every ePHI access path
Enforce it at the identity provider so one policy covers the EHR, email, and file access together. Document the exceptions honestly: a medical device that cannot support MFA needs a written compensating control, and the proposed rule expects that documentation to exist.
Start the business associate conversation early
Inventory your BAs, identify which ones hold or access ePHI, and draft the annual verification workflow now. If you are a business associate yourself, prepare the attestation package before customers ask, because they will ask ahead of the rule.
Test restoration against a 72-hour clock
Run a timed restoration exercise for your critical systems and file storage. If the result is over 72 hours, the remediation is architectural and needs lead time, which is the strongest argument against waiting for the final rule.
Frequently asked questions
Is the HIPAA Security Rule update final?
No. As of July 2026 it remains a proposed rule. HHS published the NPRM in the Federal Register on January 6, 2025, the comment period closed March 7, 2025 with more than 4,700 comments, and no final rule has been issued. The spring 2026 finalization target passed, and OMB's Unified Agenda currently lists July 2027 for final action. Requirements described in the proposal may change before finalization.
How long will organizations have to comply once the rule is final?
As proposed, roughly 240 days for most provisions. The rule would take effect 60 days after publication in the Federal Register, with compliance required 180 days after the effective date. Business associate agreements would need updating within one year of the effective date. Given that timeline, most compliance teams are treating the proposed requirements as the planning baseline now.
Does the update make encryption mandatory?
As proposed, yes. The NPRM removes the addressable designation and requires encryption of ePHI both at rest and in transit, with limited exceptions. The documentation-based alternatives that organizations used under the addressable framework would no longer substitute for implementing encryption itself.
Does the update require multi-factor authentication?
As proposed, yes. MFA would be required for access to systems containing ePHI, with limited exceptions and documented compensating controls where MFA is technically infeasible. The requirement reaches beyond EHR logins to other systems where ePHI is accessed, including remote file access for administrative and billing staff.
What new obligations do business associates have under the proposed rule?
Business associates would need to provide annual written verification to covered entities that the required technical safeguards are deployed, supported by expert attestation. Covered entities would be responsible for collecting those verifications. Both sides need a documented workflow, and many covered entities are expected to begin requesting attestations before the rule is final.
Does MyWorkDrive sign a BAA and support the proposed requirements?
Yes, MyWorkDrive executes Business Associate Agreements on request and is SOC 2 Type II certified. Architecturally, ePHI stays on customer-controlled storage with no file content stored at rest on MyWorkDrive servers, remote access runs over TLS 1.2 or higher, MFA is enforced through your identity provider, and all file activity is logged with SIEM export. Encryption at rest is applied by the customer on their own storage, consistent with the shared responsibility model, and no product alone makes an organization HIPAA compliant.
Reduce the surface the new rule applies to
MyWorkDrive gives healthcare organizations remote access to existing Windows file servers over TLS on port 443, with ePHI kept on your own storage, MFA through your identity provider, complete audit logging, and a BAA available on request. See how it maps to the safeguards the proposed Security Rule would make mandatory: explore secure file sharing for healthcare.