Proposed HIPAA Security Rule Changes: What Dental Practices Should Prepare for in 2026

HHS OCR issued the proposed modernization on December 27, 2024. The proposal was formally published as 90 Federal Register 898 on January 6, 2025, with comments due by March 7, 2025. Calling it the January 2026 proposed rule would be inaccurate; the practical 2026 issue is that health care organizations continue evaluating a proposal published in January 2025.

As of July 28, 2026, HHS’s Security Rule history still labels the modernization as a proposed rule. The same history identifies the 2013 Omnibus HIPAA Final Rule as the most recent final rule affecting the Security Rule. HHS’s proposal fact sheet also states that the current Security Rule remains in effect while rulemaking continues.

That distinction matters. Dental practices should not tell patients, employees, insurers, or business partners that every proposed control is already legally mandatory. They also should not assume that a final rule will reproduce every provision exactly. HHS can revise, remove, delay, or reorganize requirements before publishing a final rule.

Practices must continue complying with the current Security Rule, including risk analysis, risk management, access control, security incident procedures, contingency planning, workforce security, audit controls, authentication, transmission security, and appropriate administrative, physical, and technical safeguards.

The existing Security Rule was intentionally designed to accommodate organizations of different sizes and technical capabilities. It includes required and addressable implementation specifications and gives regulated entities flexibility to select reasonable and appropriate safeguards based on risk.

HHS stated that cyberattacks, ransomware, interconnected systems, cloud services, business associate relationships, and repeated deficiencies identified during investigations support a more specific regulatory approach. The proposal would reduce ambiguity by assigning written requirements, deadlines, review intervals, and minimum control expectations to many security activities.

One major proposal would remove the distinction between required and addressable implementation specifications. Implementation specifications would generally become required, subject to specific and limited exceptions. That is different from the current addressable framework, under which an organization evaluates whether a specification is reasonable and appropriate and documents an equivalent alternative when applicable.

The proposed rule would also require written documentation for policies, procedures, plans, and analyses. For a small dental office, this could turn informal security habits into auditable records that show what systems exist, what risks were identified, what safeguards were selected, who approved them, and when their effectiveness was tested.

The current Security Rule already requires an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information. OCR enforcement actions repeatedly emphasize that conducting and updating a meaningful risk analysis is a present obligation, not something created for the first time by the proposal.

The proposal would make the contents and maintenance of the analysis more specific. The written assessment would review the technology inventory and network map, identify reasonably anticipated threats, identify vulnerabilities and predisposing conditions, evaluate potential impacts, and assign risk levels based on likelihood and impact.

The proposed text would require the written risk assessment to be reviewed, verified, and updated on an ongoing basis, at least once every twelve months, and after environmental or operational changes that may affect ePHI. Examples include new technology, upgrades, patches, new threats, mergers, security incidents, new locations, and legal changes.

For a dental practice, an annual review would be the minimum rather than the only trigger. A server migration, new imaging system, cloud practice management platform, remote billing team, acquisition, office buildout, new patient communication tool, or security incident could require the analysis to be updated sooner.

The proposal would require a written inventory of technology assets and a network map showing how ePHI moves through relevant systems. The inventory would identify items such as servers, workstations, laptops, mobile devices, firewalls, switches, wireless equipment, cloud platforms, applications, databases, backup systems, and connected technology that may affect ePHI.

A dental inventory should include practice management software, imaging platforms, sensors, scanners, document repositories, claims tools, electronic prescribing, patient communication systems, payment products, email, file sharing, remote access, cloud storage, backup consoles, and vendor support tools. Unsupported or forgotten systems cannot be managed effectively if they are absent from the inventory.

The network map should show more than lines between computers. It should identify where ePHI enters, where it is stored, which systems transmit it, how remote users connect, which vendors can access the environment, and where trust boundaries exist between clinical, administrative, guest, voice, device, and server networks.

HHS proposed that the inventory and map be maintained continuously, reviewed at least every twelve months, and updated after relevant changes. Practices can begin this work now because an accurate inventory and map support the existing risk-analysis requirement even before any new rule becomes final.

Under the current Security Rule, encryption appears as an addressable implementation specification in relevant access-control and transmission-security provisions. Addressable does not mean optional or unimportant. It means the regulated entity must assess whether encryption is reasonable and appropriate and document its decision or equivalent safeguards.

The proposed rule would establish a standard requiring technical controls to encrypt and decrypt ePHI using prevailing cryptographic standards. It would require encryption of ePHI at rest and in transit, subject to limited, documented exceptions.

For dental practices, data at rest may include server drives, workstation drives, laptops, database storage, image repositories, backups, exported reports, removable media, and cloud storage. Data in transit may include remote sessions, email, file transfers, claims, vendor connections, cloud synchronization, application programming interfaces, and communication between offices.

An exception would not mean ignoring the risk. For example, when a technology asset cannot support compliant encryption, the proposed rule describes a written migration plan and compensating safeguards. Practices should identify legacy dental devices and applications now because they may be the systems most difficult to encrypt, replace, or isolate.

The proposal would require multi-factor authentication across relevant electronic information systems, with limited exceptions. It would also require MFA for actions that change user privileges in ways that could affect the confidentiality, integrity, or availability of ePHI.

Many dental practices already use MFA for email, remote access, cloud applications, backup consoles, firewalls, and administrator portals. Coverage is often inconsistent. One vendor account may use MFA while another relies only on a shared password. A remote support tool may be protected, while a legacy VPN or local administrator account is not.

Preparing for broader MFA begins with identity inventory. List every user, administrator, service account, vendor account, cloud tenant, remote-access method, application, and device. Determine which systems support modern MFA, which require configuration, which need licensing, and which legacy systems may need replacement or compensating controls.

MFA does not eliminate phishing, session theft, malware, or abusive administrators. It should be combined with separate administrative identities, least privilege, protected password storage, device security, conditional access where available, account monitoring, rapid offboarding, and restrictions on third-party access.

The proposal would require automated vulnerability scanning at least every six months or more frequently when the risk analysis calls for it. It would also require penetration testing by a qualified person at least every twelve months or more frequently when risk warrants.

A vulnerability scan identifies known weaknesses, missing patches, insecure services, exposed ports, unsupported software, and configuration issues. A penetration test goes further by attempting to validate whether weaknesses can be combined or exploited. They are related but not interchangeable activities.

Dental practices should define scope carefully. A scan limited to one server may miss workstations, firewalls, wireless systems, cloud services, external exposure, remote-access tools, imaging networks, or vendor-connected devices. Testing should be planned so it does not interrupt patient care or damage sensitive equipment.

The proposal also emphasizes ongoing vulnerability monitoring and timely patching. Dental environments need a controlled patch process because untested changes can affect imaging drivers, databases, bridges, or clinical devices. A mature program inventories exceptions, verifies vendor compatibility, tests changes, deploys updates, documents failures, and uses compensating controls until a safe correction is available.

The proposed rule would require reasonable and appropriate network segmentation. Segmentation limits which systems can communicate and can reduce how far an attacker or malicious program moves after compromising one device.

A dental practice may separate guest wireless access, business systems, clinical workstations, imaging devices, voice systems, servers, building equipment, and vendor-managed technology. The design must preserve necessary communication between practice management software, imaging systems, printers, scanners, sensors, and cloud services.

Segmentation is not accomplished only by creating different wireless names. Firewall policies, virtual networks, access-control lists, identity controls, routing, monitoring, and documentation determine whether separation is effective. The practice should also know which vendor accounts and remote tools can cross those boundaries.

The proposal addresses standardized configuration, anti-malware protection, removal of unnecessary software, and disabling unneeded network ports. These system-hardening activities are also consistent with OCR’s January 2026 cybersecurity newsletter, which discusses patching, removing unnecessary services, enabling security features, and configuring systems to reduce attack surface.

The proposed rule would create more specific contingency and incident-response obligations. HHS proposed written restoration procedures for certain critical relevant systems and data within seventy-two hours after a loss, supported by a criticality analysis that determines restoration priorities.

This does not mean every dental practice can buy a backup product and assume it can restore all operations within seventy-two hours. The practice would need to identify critical systems, establish recovery objectives, protect backup copies, test restorations, maintain necessary credentials, document dependencies, and assign responsibility for declaring and managing an incident.

A dental recovery plan should distinguish the practice management database, imaging data, scanned documents, email, shared files, phone systems, internet access, authentication, cloud applications, and connected clinical workflows. Restoring one server may not restore appointment operations if users, images, integrations, or network services remain unavailable.

The proposal would also require written incident-response plans, reporting procedures, testing, revision, and documentation of investigations and remediation. Practices can improve these capabilities now through tabletop exercises involving the owner, office manager, IT provider, compliance advisor, cyber insurer, legal counsel, and important vendors.

Dental practices rely on IT providers, cloud platforms, backup companies, software vendors, billing partners, communications platforms, and other business associates. A signed business associate agreement is important, but it is not evidence that the vendor has implemented effective safeguards.

The proposal would require business associates to provide covered entities with annual written verification that required technical safeguards have been deployed, supported by a subject matter expert’s analysis. It would also require business associates to notify covered entities when contingency plans are activated without unreasonable delay and no later than twenty-four hours after activation.

Whether those exact provisions become final remains uncertain. The practical direction is clear: covered entities need better visibility into vendor safeguards, incidents, subcontractors, recovery dependencies, privileged access, and evidence of security performance.

Dental practices can strengthen vendor management now by maintaining a business associate inventory, confirming agreements, documenting services and data access, reviewing security questionnaires, defining incident-notification expectations, requiring protected administrative access, and planning how data and credentials will be returned at termination.

Begin with controls that support existing Security Rule obligations and remain useful even if the final rule changes. Build a complete technology and vendor inventory, diagram important data flows, conduct a written risk analysis, create a prioritized risk-management plan, and retain evidence showing that identified risks are being addressed.

Expand MFA across email, remote access, administrator portals, cloud applications, backup platforms, security consoles, and vendor tools. Encrypt supported laptops, workstations, servers, backups, and network communications. Document legacy systems that cannot support modern controls and establish migration or isolation plans.

Review backups, test restorations, define critical systems, document incident roles, and conduct a tabletop exercise. Establish a patch process, identify unsupported technology, scan the environment, review administrator access, remove former users, and segment systems where the design supports it.

Label every proposal-based roadmap item accurately. Use language such as proposed requirement, readiness measure, or anticipated control rather than claiming that it is already a new HIPAA mandate. Legal and compliance advisors should review final obligations after HHS publishes any final rule and compliance dates.

Ignoring the proposal until a final rule appears may leave a practice with too much work and too little time. Overstating the proposal can create a different problem by confusing recommendations with current law. A sound approach separates present obligations, proposed changes, and voluntary risk-reduction measures.

Practices should continue satisfying the current Security Rule today. Risk analysis, risk management, access control, contingency planning, incident procedures, authentication, audit controls, workforce security, and appropriate protection of ePHI are not waiting for a new rule.

At the same time, the proposal provides a useful view of the direction federal cybersecurity expectations may take: more written evidence, clearer deadlines, stronger identity controls, encryption, testing, vendor verification, segmentation, and measurable recovery readiness.

Dental practices that build those capabilities carefully will be better positioned for a future final rule, cyber-insurance reviews, vendor assessments, patient trust, and ordinary business continuity. Preparation should be risk-based and practical rather than driven by claims that proposed regulations are already final.