If your organization runs clinical software on Java EE, .NET Framework, Struts, or VB6, the proposed updates to the HIPAA Security Rule are aimed directly at your infrastructure. The controls being proposed, mandatory MFA, mandatory encryption, and documented asset inventories, are architectural requirements, not configuration changes.
Most legacy clinical stacks cannot meet them natively. This article explains exactly what is changing, which systems are affected, and what your options are before the compliance clock starts.
What the New HIPAA Security Rule Changes and Why Legacy Systems Are at Risk
The HIPAA Security Rule has been the governing standard for electronic protected health information since 2003. Its last substantive update was the 2013 Omnibus Rule, which extended direct liability to business associates but left the underlying control framework largely unchanged.
That framework was designed for an era of on-premises servers, desktop workstations, and cyber threats that bore little resemblance to the ransomware operations that define the current healthcare threat environment.
On December 27, 2024, the Office for Civil Rights at HHS issued a Notice of Proposed Rulemaking to update the Security Rule for the first time in over a decade. The NPRM was published in the Federal Register on January 6, 2025; the public comment period closed March 7, 2025, with approximately 4,700 to 5,000 submissions received.
As of June 2026, no final rule has been published. OCR’s regulatory agenda had targeted May 2026 for finalization; that window has passed. The current Security Rule remains in effect.
OCR launched its Risk Analysis Initiative in fall 2024, a targeted enforcement campaign focused on organizations without adequate documented security risk analyses. The pattern across the resulting enforcement actions is consistent: a ransomware attack triggers an OCR investigation, the investigation identifies gaps in risk analysis and technical controls, and a settlement follows with a corrective action plan running two to three years. The controls the NPRM would mandate are where OCR is already auditing under the rule that exists today.
In February 2024, a ransomware affiliate gained access to Change Healthcare’s network through a legacy Citrix remote access portal with no multi-factor authentication enabled [1]. The resulting breach affected approximately 192.7 million individuals, roughly two-thirds of the US population, and produced operational and financial damage that touched every hospital in the country.
Two months later, Ascension Health was compromised through a single phishing event that allowed lateral movement across thousands of endpoints. Each proposed NPRM control maps to a named breach pattern from those events.
What the NPRM Proposes: Controls, Timeline, and the Uncertainty That Remains
What Is the 240-Day HIPAA Compliance Window?
If a final rule is published, it becomes effective 60 days after publication in the Federal Register. Compliance is required 180 days after the effective date, 240 days total from publication. As of June 2026, the clock has not started because no final rule has been published [2].
240 days, approximately eight months, is not sufficient to execute a system replacement or a large-scale infrastructure overhaul from a standing start. Organizations that begin gap assessment now are working ahead of a deadline whose start date is uncertain but whose duration, once triggered, is fixed.
The Structural Change: Elimination of “Addressable”
Under 45 CFR 164.306(d), the current Security Rule classifies implementation specifications as “required” or “addressable.” The “addressable” pathway became the mechanism by which hospitals deferred encryption, MFA, and network segmentation for over a decade, with documented rationale standing in for operational implementation.
The NPRM eliminates this distinction entirely. Everything becomes required, with only narrowly enumerated exceptions. The only remaining flexibility is in how organizations implement controls that are reasonable and appropriate for their environment, not whether they implement them.
| Current Security Rule | NPRM Proposed | |
| Classification | Required or Addressable | All required; narrow exceptions only |
| Flexibility | Implement, implement equivalent, or document why not | Implement; exceptions must meet specific criteria |
| Documentation as substitute | Accepted as compliance evidence | No longer sufficient |
The Proposed Mandatory Controls
The table below maps each proposed control to its current status and what it means operationally for organizations running legacy clinical systems [2][3].
| Control | Current Security Rule | NPRM Proposed | Legacy System Impact |
| Encryption at rest and in transit | Addressable | Required standard; AES-256 / TLS 1.2 minimum | Systems without native encryption require retrofit, structural modification, or replacement |
| Multi-factor authentication | Addressable | Required; narrow exceptions for legacy with documented migration plan | Applications without SAML/OIDC support cannot meet this natively |
| Network segmentation | Not explicit | Required at 45 CFR 164.312; prevents lateral movement | Undocumented connectivity makes segmentation scope undefined |
| Technology asset inventory and ePHI network map | Not mandated | New administrative safeguard; annual update required | Undocumented legacy systems cannot produce this without a comprehension effort |
| Vulnerability scanning | No defined cadence | Every six months minimum | EOL frameworks and unsupported OSes create structural patch exposure |
| Patch cadence | General requirement | 15-day critical / 30-day high-severity | Incompatible with many legacy application stacks |
| System restoration | General contingency plan | 72-hour restoration capability, written and tested | Systems without documented architecture cannot scope restoration reliably |
| Annual compliance audit | No defined frequency | Annual, documented | Requires an operational compliance program, not a periodic assessment |
| Business associate verification | BAA required | Annual written verification that BAs have deployed required safeguards | Covered entities accountable for vendor posture, not only BAA signature |
The Uncertainty That Remains
A coalition of more than 100 organizations led by the College of Healthcare Information Management Executives formally requested withdrawal of the NPRM on December 8, 2025, citing projected year-one compliance costs approaching $9 billion across the industry [4]. HHS has not confirmed a revised timeline. The rule could be finalized as proposed, materially narrowed after comment review, delayed further, or withdrawn.
Mandatory encryption, mandatory MFA, mandatory asset inventories, and enforceable transition plans for legacy exceptions: that is the direction the NPRM points. It is also where OCR enforcement is already heading under the rule that exists today, regardless of whether this specific rulemaking proceeds.
Why Legacy Clinical Systems Cannot Meet These Requirements With Configuration Alone
For organizations running modern cloud-hosted platforms, the proposed controls are largely a deployment and configuration exercise. For organizations running legacy clinical applications on Java EE, Struts, JSP/Servlets, .NET Framework, or VB6, these are not gaps you close by enabling a setting. They are architectural limitations of the stack.
| Legacy Stack | Why It Fails the Proposed Controls | Modern Target Stack |
| Java EE / Struts | No SAML/OIDC support, EOL since 2013, patch cadence impossible | Spring Boot 3.x |
| JSP / Servlets | Undocumented data flows, no native encryption | Spring Boot + React |
| .NET Framework | Patch cadence tied to Windows EOL, no modern identity support | .NET 8 |
| VB6 | No path to MFA, encryption, or supported patch cycle | .NET 8 + React |
If your clinical system runs on any of these stacks, the gaps below apply directly to your environment.
The MFA Gap
Legacy applications built before modern identity federation do not support MFA natively. Here is why that matters and what the rule says about it.
Applications built before modern identity federation became standard do not support SAML or OIDC natively. They authenticate users through application-managed credential stores with no federation layer. Enforcing MFA requires either adding an authentication proxy in front of the application or modifying the application to support a modern identity protocol.
The NPRM’s legacy exception acknowledges this constraint: MFA may be deferred for systems that cannot support it, but only when the entity has a documented transition plan to migrate ePHI to MFA-supported technology [3].
That exception is a conditional accommodation with an enforceable obligation attached. OCR has signaled that migration plans submitted under legacy exceptions will be scrutinized for credibility and execution in enforcement proceedings, not accepted as permanent documentation.
The Change Healthcare entry point is the clearest illustration. Access was gained through a legacy remote access portal with no MFA. The gap was documentable, and no enforceable migration timeline existed [1].
The Encryption Gap
Many legacy clinical systems transmit data over cleartext channels that were standard when they were built. The proposed rule makes this an explicit violation.
The encryption gap compounds the same underlying problem. Most legacy clinical systems that cannot support MFA also transmit data over cleartext channels, a standard from the era when these systems were built.
A substantial number of legacy clinical systems in production today lack native database-level encryption or transmit data over unencrypted channels, including cleartext HL7 feeds that were standard when these systems were built.
An application without native encryption support requires one of three interventions: add encryption at the storage or infrastructure layer without touching application code, modify the application to support encryption natively, or replace it.
Healthcare data breach costs averaged $7.42 million per incident in 2025, the highest of any industry for fourteen consecutive years [5]. Legacy systems that remain unencrypted after a final rule is published become explicit violations rather than documented exceptions.
Organizations running .NET Framework or older Java EE stacks should review how aging infrastructure compounds this exposure. For the full cost picture of deferring these decisions, see our breakdown of the true cost of maintaining legacy systems.
The Technology Asset Inventory Gap
The rule requires a written inventory of every system touching patient data. For undocumented legacy applications, that inventory has to be extracted from the code.
The NPRM proposes a new administrative safeguard requiring a written inventory of every technology asset that creates, receives, maintains, or transmits ePHI, plus a network map illustrating how ePHI moves through the organization’s systems, updated at a minimum annually [2].
For organizations whose legacy clinical systems were never formally documented, this is an engineering problem before it is a compliance problem. The scope of ePHI exposure within a system cannot be asserted through policy without first understanding what the system contains, how data flows between modules, and which integration points touch protected information.
The Patch Cadence Gap
15-day critical patch cycles are structurally impossible on end-of-life frameworks. This is not a process problem, it is an infrastructure one.
Proposed 15-day critical and 30-day high-severity patch cycles are structurally incompatible with applications running on end-of-life frameworks.
An application on Java EE with a Struts dependency end-of-life since 2013, or on .NET Framework 4.8 tied to a Windows runtime on a constrained support timeline, cannot be patched on that cadence without a supported infrastructure beneath it.
The Segmentation Gap
You cannot segment a system whose network connections have never been mapped. Segmentation and the asset inventory are the same prerequisite problem.
Network segmentation of systems with undocumented connectivity is a scope problem before it is an implementation problem. A legacy clinical application whose integration points and network dependencies have never been mapped cannot be segmented without first producing that map.
The segmentation boundary cannot be defined without knowing what the system touches, and that prerequisite work is the same work a technology asset inventory requires.
Understanding which gaps apply to your system is the first step. The more important question is what you can realistically do about them within the compliance window. There are three structurally distinct options, and they produce very different outcomes.
Three Options for Organizations Running Legacy Clinical Systems
Organizations running legacy clinical applications that cannot natively meet the proposed controls have three structurally distinct options. The right choice depends on the system’s compliance exposure, technical modernization feasibility, operational constraints, and timeline.
Each path produces a different profile of compliance artifacts: the evidence an organization can place in front of OCR in an audit or enforcement proceeding.
Path 1: Retrofit
Retrofit means adding compensating controls at the infrastructure layer without modifying the application: deploy an access proxy or authentication gateway to enforce MFA without requiring SAML/OIDC support in the application itself; apply storage-layer encryption to protect ePHI at rest without touching application code; use network controls to approximate segmentation of the application’s traffic.
This path has real utility. It can bring a legacy system into conditional compliance on specific controls within a timeframe that replacement cannot match, and it creates documentable compensating controls that satisfy near-term audit requirements.
What retrofit does not resolve: the underlying framework exposure that creates patch cadence gaps, the undocumented connectivity that makes segmentation scope speculative, the technology asset inventory the NPRM mandates as an administrative safeguard, or the transition plan the MFA exception actually requires.
Applying a proxy in front of a legacy application produces a compensating control. OCR will expect the migration plan to exist alongside it.
Retrofit is a bridge posture, not a destination. It works when three conditions are true: the system has a defined replacement timeline, ePHI data flows are documented well enough to scope the compensating controls, and the organization has the capacity to evidence those controls continuously.
Path 2: Rip-and-Replace
A full replacement eliminates the legacy compliance exposure structurally. A modern commercial platform with native MFA, encryption, and current framework support solves the architectural problem permanently and positions the organization for FHIR R4 interoperability compliance simultaneously.
The constraint is timeline. Full clinical system replacements have consistently run 18 to 36 months. A 240-day compliance window does not accommodate a clean rip-and-replace from a standing start. The projects that fail at highest cost are those that begin transformation before knowing what the legacy system actually contains. Scope discovery failures are the documented primary cause of healthcare IT replacement budget overruns.
The decision criteria for rip-and-replace: the legacy system is at end-of-life with no viable modernization path in the existing codebase, a vendor replacement has already been scoped and selected, clinical workflow redesign is resourced and staffed, and the organization has the capital and timeline to execute without a compliance deadline forcing the pace.
Path 3: Modernize the Application
Application modernization transforms the technology layer of the legacy clinical system, the framework, the runtime, and the authentication architecture to a modern stack that natively supports MFA, encryption, and current patch cycles. The clinical logic is preserved. The compliance-blocking architecture is replaced.
Legacyleap’s five-agent system, Assessment, Documentation, Recommendation, Modernization, and QA, executes each phase in sequence.
- The Assessment Agent scans the codebase.
- The Documentation Agent reconstructs what was never written down.
- The Recommendation Agent produces the ordered migration plan OCR will examine as your transition plan.
- The Modernization Agent executes the code changes as reviewable pull requests.
- The QA Agent validates parity before cutover.
Each agent produces a compliance artifact as a direct output, not as a separate documentation effort running alongside the program.
This path uniquely produces the compliance artifacts the rule demands as direct outputs of the modernization program. The system comprehension phase generates the technology asset inventory and the ePHI data-flow map that the NPRM requires. The planning phase produces the ordered migration plan that OCR will examine as the transition plan the legacy exception requires.
Because the transformation is executed by Gen AI agents rather than manual rewriting, the timeline compresses from the 18 to 36 months a traditional replacement requires to a phased program that runs alongside clinical operations.
The transformation phase executes governed, diff-based code changes with human review at each step. The validation phase confirms behavioral parity before cutover, a patient safety requirement as much as a compliance one.
The decision criteria for modernization is that the application carries clinical or business logic that a commercial vendor platform cannot replicate, the organization wants to eliminate the compliance liability structurally rather than through ongoing compensating controls, and a phased execution model is viable alongside continuous clinical operations.
For organizations that need a structured modernization partner with a defined compliance artifact output, this path is where Legacyleap operates as a purpose-built platform.
For a deeper look at the specific execution risks in tightly coupled clinical systems, see our guide to tightly coupled application modernization.
Comparing the Three Paths
| Retrofit | Replace | Modernize | |
| MFA and encryption covered | Conditionally, via proxy/gateway | Yes, on the new platform | Yes, natively in the target stack |
| OCR-ready transition plan produced | No | Only if separately scoped and documented | Yes, from the recommendation phase |
| Technology asset inventory produced | No | Requires a separate effort | Yes, from the assessment phase |
| Underlying framework risk resolved | No | Yes | Yes |
| Feasible within 240 days | Partially | Rarely | First compliance artifacts in 2 to 5 days; full modernization phased |
| FHIR R4 readiness addressed | No | Depends on the replacement platform | Yes |
If your legacy clinical application has been flagged in a security audit and you need to know exactly what it takes to close those findings, the Security Posture Assessment maps every EOL framework, vulnerable dependency, and weak cryptography finding to its exact code location, then delivers an exact scope, cost, and timeline to remediate. Your code never leaves your infrastructure.
How Legacyleap’s Gen AI Agents Modernize Legacy Clinical Systems for HIPAA Compliance
Legacyleap is a Texas-based Gen AI-powered modernization platform built specifically for legacy clinical and healthtech applications.
With 150+ production-grade assessments completed, the platform modernizes Java EE, Struts, JSP/Servlets, .NET Framework, and VB6 systems to Spring Boot, .NET 8, and React, the target stacks that natively support MFA, modern encryption, and the patch cadence the proposed rule requires.
Building the Compliance Baseline: Assessment and Documentation
The Assessment Agent scans the legacy codebase and produces a technical debt report, dependency map, security vulnerability indicators, and migration effort estimate.
The Documentation Agent then reconstructs system documentation from code behavior: module boundaries, data-flow diagrams, integration maps, architecture diagrams, API inventories, and a complete system inventory, without relying on tribal knowledge or outdated design documents.
Together, these two agents produce the outputs that form the foundation of the technology asset inventory and ePHI network map the NPRM requires as an administrative safeguard. This work is completed in 2 to 5 days. For organizations that have deferred documentation, it is also a prerequisite for any migration plan that OCR will assess as credible.
The Transition Plan and Governed Transformation
The Recommendation Agent produces the ordered migration plan: target framework selection, module-level refactor/replace/retain decisions, effort and risk scoring, and phased migration sequencing. This output is grounded in what the Assessment and Documentation Agents surfaced from the actual codebase. It is the transition plan the legacy exception requires, and its credibility as an OCR artifact derives from the comprehension work that precedes it.
The Modernization Agent then executes code transformations aligned with the plan. All changes are delivered as pull requests: diff-based, human-reviewed, reversible. No code is merged or deployed autonomously. Approximately 70% of the transformation effort is automated; engineering teams retain approval authority over every change.
The target stacks relevant to healthcare compliance, Spring Boot, .NET 6+/8, and React, natively support MFA through SAML/OIDC, modern encryption standards, and the patch cadence the NPRM proposes.
Parity Validation and Deployment Posture
The QA Agent auto-generates parity validation across unit, integration, regression, API, and functional test cases, running differential checks between legacy and modernized system behavior. For a clinical system, a missed parity gap is a potential patient safety event.
The QA Agent’s validation, not a deployment assumption, confirms the modernized system performs as the original before any cutover. Test creation runs at approximately 2 times the speed of manual approaches.
All Legacyleap processing runs within the client’s own infrastructure, on-premises or VPC-hosted. No source code leaves the client’s environment. No outbound API calls to external LLM providers are required.
For HIPAA-covered entities and healthcare ISVs carrying Business Associate Agreement obligations, this deployment posture is the precondition for using any AI-assisted tooling on a clinical codebase. Configurable access policies, PII filters applied before inference, and full audit logs of every agent action provide the documentation trail an annual compliance audit will require.
For a detailed breakdown of the HIPAA Security Rule compliance requirements and FHIR R4 mandate implications for legacy clinical systems, see our healthcare application modernization guide.
Program Readiness Before the 240-Day Clock Starts
The NPRM’s final status is unresolved. The compliance direction it represents is not. Encryption, MFA, documented technology asset inventories, and enforceable transition plans for legacy systems that cannot meet mandatory controls are where OCR investigations are landing under the rule that already exists.
The preparation window is open now. Organizations that begin the system comprehension work before finalization will have the compliance artifacts, technology asset inventory, ePHI data-flow map, ordered migration plan, and security vulnerability baseline, before the clock starts rather than under it.
Get your free Security Posture Assessment. Legacyleap ingests your security audit findings and your codebase, maps every EOL framework, vulnerable dependency, and weak cryptography finding to its exact code location, and delivers an exact scope, cost, and timeline to remediate, with a proof-of-approach demonstration showing how each finding gets closed. Your code stays in your infrastructure throughout.
Book a Technical Demo. For organizations that want to see the five-agent system work against a real codebase before sharing code, or that are evaluating Legacyleap against other modernization approaches, a live session covers real-time architecture visualization, agent workflows, and how the platform operates within your infrastructure constraints.
FAQs
Deploy a reverse proxy or identity-aware gateway (Cloudflare Access, Zscaler, Azure AD Application Proxy) in front of the application. The proxy enforces MFA at the network layer without touching the application’s authentication logic.
A written, dated transition plan that identifies the specific system, documents why MFA cannot be implemented natively, names the compensating controls in place, specifies the target MFA-supported technology, and includes a defined migration timeline.
Yes, the same mandatory technical safeguards apply directly to BAs, and BAs carry downstream liability for their subcontractors. A covered entity that engages a BA running EOL software faces its own exposure if the annual verification requirement surfaces unresolved gaps.
A named target architecture, module-level milestones with assigned owners, a committed completion date, and a current-state risk assessment showing compensating controls. Plans without milestones, owners, or a completion date read as deferral documents, not transition commitments.
Annual written verification replaces reliance on a signed BAA. In practice, this means requesting a system inventory, vulnerability scan results, or third-party attestation. Failing to act on a verified gap creates shared liability in an OCR investigation.
On an EOL framework, no vendor patch exists, so the cycle cannot be executed as defined. Document it as a formal exception: EOL date confirmed, no patch path available, compensating controls enumerated, transition timeline attached.
