HIPAA Security Rule: Requirements and Legacy System Remediation
The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic protected health information — access control, audit controls, integrity, authentication, and transmission security. It is deliberately technology-neutral and gives covered entities flexibility of approach, so encryption is currently "addressable" — you implement it or document an equivalent. A December 2024 proposed update would make many specifications required, including encryption and MFA, but it remains proposed, not law. The Rule does not require modernization — but legacy systems make these safeguards hard to satisfy, which is what we remediate.
The HIPAA Security Rule requires covered entities and their business associates to protect the confidentiality, integrity, and availability of electronic protected health information through administrative, physical, and technical safeguards. It is deliberately technology-neutral: it names no stack, does not require modernization, and explicitly gives covered entities flexibility of approach — measures reasonable and appropriate to their size, complexity, capabilities, and cost. The intent was to keep the sector from being chained to systems that become obsolete. What it asks for is safeguard outcomes.
Those outcomes are what an aging system struggles to produce. Healthcare runs on systems that have been trusted for decades — a clinical application no one dares touch, a records database older than half the staff, an integration engine that quietly moves protected health information between everything. None of it is the villain; it encodes real clinical and operational reality. But when an OCR audit or a risk analysis asks how that system protects ePHI, the honest answer is increasingly “with difficulty.”
What the HIPAA Security Rule actually requires of your systems
The Security Rule (45 CFR Part 164, Subpart C) protects the confidentiality, integrity, and availability of all ePHI through three categories of safeguards:
- Administrative safeguards (164.308) — risk analysis and risk management, workforce access management, training, incident procedures, contingency planning, and periodic evaluation.
- Physical safeguards (164.310) — facility access controls, workstation security, and device and media controls.
- Technical safeguards (164.312) — access control, audit controls, integrity, person-or-entity authentication, and transmission security.
The technical safeguards are where legacy systems get caught, so it is worth seeing them at the level the rule actually specifies them: each standard, its implementation specifications, and whether the rule marks that specification “required” or “addressable” (45 CFR 164.312).
| Standard (164.312) | Implementation specification | Status |
|---|---|---|
| Access control | Unique user identification | Required |
| Access control | Emergency access procedure | Required |
| Access control | Automatic logoff | Addressable |
| Access control | Encryption and decryption | Addressable |
| Audit controls | Record and examine activity in systems with ePHI | Required (standard) |
| Integrity | Mechanism to authenticate ePHI | Addressable |
| Person or entity authentication | Verify identity before access | Required (standard) |
| Transmission security | Integrity controls | Addressable |
| Transmission security | Encryption | Addressable |
“Addressable” is the word that trips people up, so be precise about it. Addressable does not mean optional. Under 164.306(d) you must assess each addressable specification and then either implement it, or document why it is not reasonable and appropriate for your environment and implement an equivalent measure that is. What you cannot do is silently skip it. That is why encryption sits in an awkward middle: the rule does not flatly mandate it today, but a system that cannot support it forces you into the “document an equivalent and defend it” path, and the equivalent has to actually hold up.
That nuance is about to matter more. A December 2024 proposed update, published in the Federal Register in January 2025, would remove the addressable distinction almost entirely and make nearly every specification required, with only narrow exceptions. As of mid-2026 that update is still proposed, not finalized. The changes most relevant to a legacy estate:
- Remove the addressable/required split, so specifications that are optional-with-documentation today become mandatory.
- Require encryption of ePHI both at rest and in transit.
- Require multi-factor authentication for access to systems handling ePHI.
- Require network segmentation to contain the blast radius of a breach.
- Require a written, current inventory of technology assets and a network map.
- Require regular vulnerability scanning and penetration testing.
Do not remediate against the proposed rule as if it were binding, because it is not law yet and its final form can change. But treat it as a clear signal of direction: the flexibility that currently lets an older system document its way around encryption is exactly what the update would narrow. A system that already cannot encrypt, cannot do MFA, or cannot be segmented is a system that is on the wrong side of where the rule is heading. Until the update is final, the accurate statement is that HIPAA expects you to evaluate encryption and document your decision, not that it mandates it.
Where legacy systems fail the requirement
A legacy healthcare system rarely fails because it is old. It fails for specific reasons that map directly to the safeguards:
- It can’t authenticate or log the way the rule expects. Audit controls and person-or-entity authentication are hard to retrofit onto an application that predates the expectation.
- It can’t encrypt cleanly. Where encryption is the reasonable and appropriate measure, a system that can’t support it leaves you documenting an alternative you then have to defend.
- It can’t be patched. An unsupported OS or database holding ePHI undercuts the integrity and confidentiality the rule expects, and a risk analysis will flag it.
- It makes the risk analysis harder to pass. “Reasonable and appropriate” is judged against your capabilities — and a system that limits your capabilities limits the defense.
How we remediate it
We treat a HIPAA gap the same way we treat any legacy system: a sequence of small, reversible steps, not a single risky cutover that puts clinical operations at risk.
A strangler facade sits in front of the system so the legacy path and the modernized path run side by side. The part of the system that handles ePHI moves in bounded slices rather than all at once, and before any slice carries live data, we prove it behaves identically to the legacy — same results, same state, reconciled record by record. The modernized slice runs on a supported platform that does access control, audit logging, authentication, and transmission security natively, so the technical safeguards become properties of the system rather than retrofits an auditor will question. AI-accelerated discovery reads the application, the data, and the integration surface end to end and captures what the system actually does — including the undocumented clinical logic the original authors never wrote down — under senior-engineer review. Traffic shifts only on green, rollback stays a flag away, and the legacy system handles ePHI only until nothing depends on it. We separate the deadline from the durable fix, so a risk-analysis finding can be covered by an interim measure while the modernization retires it for good.
The Rule’s flexibility is real
Not every HIPAA finding warrants modernization, and we’ll say so. The Security Rule’s flexibility is real — a stable, well-isolated system with appropriate compensating measures is sometimes exactly where a finding should rest, especially given the rule’s regard for your size and resources. Rebuilding a system to satisfy an auditor, when a documented and defensible alternative is reasonable, is rarely the best use of the budget. The slice-by-slice approach earns its place when the system handling ePHI is unpatchable, when it can’t take downtime that clinical care depends on, or when its limits keep narrowing what you can credibly call reasonable and appropriate. And we won’t tell you HIPAA requires modernization — it doesn’t, and it may not even after the proposed update finalizes. What it does is make some legacy systems progressively harder to defend.
Where to start
The first step is small and bounded: understand which systems actually handle ePHI, which safeguards they strain to meet, and whether the right move is a compensating measure or remediation. A discovery call scopes the systems in your ePHI path, accounts for the proposed Security Rule update without overstating it, and tells you where each path is warranted — on evidence, not a sales pitch. Reach the team at sales@modernlift.ai.
Frequently asked questions
- Does HIPAA require modernizing legacy healthcare systems?
- No. The Security Rule is technology-neutral by design — 45 CFR 164.306(b) lets a covered entity use any measures that are reasonable and appropriate for its size, complexity, and capabilities, so the sector is not bound to systems that may become obsolete. It does not mandate specific technology or modernization. It does require safeguard outcomes for ePHI that legacy systems often cannot produce cleanly, which is where the pressure comes from.
- Is encryption required under HIPAA?
- Today, encryption is "addressable," not "required" — under 45 CFR 164.312 you must assess it and either implement it or document why it is not reasonable and appropriate and implement an equivalent alternative. A proposed update published in the Federal Register in January 2025 would remove the addressable distinction and make encryption and MFA required, but as of mid-2026 that remains proposed, not finalized. Until it is final, do not treat encryption as a flat HIPAA mandate.
- What is the difference between "required" and "addressable" under the HIPAA Security Rule?
- Both are mandatory to reckon with. A "required" implementation specification must be implemented as written. An "addressable" one, under 45 CFR 164.306(d), must be assessed, and you then either implement it or document why it is not reasonable and appropriate for your environment and implement an equivalent measure instead. Addressable never means optional or skippable. Encryption of ePHI is addressable today, which is why a system that cannot encrypt forces you onto the "document a defensible equivalent" path rather than off the hook.
- Who must comply with the HIPAA Security Rule?
- Covered entities — health plans, health care clearinghouses, and health care providers who transmit health information electronically for covered transactions — and their business associates, who have been directly liable since the 2013 Omnibus Rule. If a system creates, receives, maintains, or transmits electronic protected health information on their behalf, it is in scope.
- Who provides HIPAA remediation and compliance-modernization services?
- We do, within a defined scope. ModernLift modernizes the legacy systems handling electronic protected health information that make the Security Rule's safeguards hard to satisfy — the applications that can't authenticate or log the way the rule expects, the data stores that can't encrypt cleanly, the unpatchable runtimes a risk analysis keeps flagging. We are not a law firm, an OCR auditor, or a compliance-attestation provider. We remediate the systems so access control, audit controls, authentication, and transmission security become native rather than retrofits.
- Is ModernLift a HIPAA compliance consultant?
- Not in the advisory or audit sense. A HIPAA compliance consultant helps with risk analysis, policies, and documentation; we work on the systems underneath, rebuilding the legacy applications that limit what you can credibly call reasonable and appropriate. We coordinate with your privacy and security officers so a modernized slice handles ePHI on a supported platform — but the risk analysis and the legal interpretation stay with your team and advisors.
- How much does HIPAA-driven modernization cost?
- It depends on the systems in your ePHI path, not on the rule itself. Cost drivers include how much of your estate runs on unsupported platforms, how entangled the in-scope clinical application is with everything around it, whether downtime is constrained by patient care, and how many documented alternatives you maintain in place of encryption. We scope the work slice by slice. The [Legacy Cost Calculator](/legacy-cost-calculator) estimates what an aging ePHI system already costs you each year before any remediation.