Covered entities and their business associates should prepare for changes to the HIPAA Security Rule. HHS published proposed changes to electronic PHI (ePHI) safeguards in January 2025, with final action expected in July 2027.
Fax is subject to the same scrutiny as any other conduit and repository of ePHI. Most proposed requirements—like broadly mandatory encryption and multi-factor authentication—are best practices which any well-architected fax solution should already have. An experienced healthcare fax partner can help identify these requirements and compare them against your existing RightFax environment.
Regardless, it’s worth reviewing and documenting how your current fax platform meets the proposed changes. Technical safeguards are foundational, but compliance is just as much a documentation and procedural responsibility as a technical one.
Disclaimer: This article is our preliminary interpretation of a subset of the proposed HIPAA Security Rule changes. It is not legal or compliance advice and is not intended to address any specific organization’s IT environment. The proposal’s requirements, timing, and implications may change.
HHS has proposed dozens of more specific requirements for covered entities and business associates. If implemented, five of them will be especially relevant to electronic fax systems. Proposal text below is excerpted from the official HHS summary.
Proposal:
“Require encryption of ePHI at rest and in transit, with limited exceptions.”
Our notes: Encrypting the connection to your fax server is necessary, but it’s only the beginning. Fax data also lives downstream in image repositories, databases, file shares, email attachments, and transfers into EHRs or document management platforms. Likewise, encryption of one medium—like IP-based transmission or electronic storage—does not imply encryption of the rest.
Proposal:
“Require the use of multi-factor authentication, with limited exceptions.”
Our notes: Check how fax users, administrators, remote support personnel, and web-portal users sign in. Include service accounts and integrations in the access review, even where interactive MFA is not applicable. MFA at the primary identity provider does not prove that every other administrative access path is protected.
Proposal:
“Establish written procedures to restore the loss of certain relevant electronic information systems and data within 72 hours.”
Our notes: This is broadly phrased. Depending on your architecture, recovery planning may need to account for document queues, routing rules, image stores, directory services, telephony, and EHR interfaces. Test all the above rather than relying on backup status reports. Keep in mind that this is a recovery standard, not a universal 72-hour fax-delivery obligation.
Proposal:
“Require the development and revision of a technology asset inventory and a network map that illustrates the movement of ePHI throughout the regulated entity’s electronic information system(s) on an ongoing basis, but at least once every 12 months and in response to a change in the regulated entity’s environment or operations that may affect ePHI.”
Our notes: This may be much broader than the fax documentation you already maintain. It needs to cover everything from physical and virtual assets (gateways, servers, storage, backup locations), to integrations and connectors, to third-party services. Above all, note where every asset interacts with ePHI in any way.
Proposal:
“Require regulated entities to conduct a compliance audit at least once every 12 months[…]”
“Require vulnerability scanning at least every six months and penetration testing at least once every 12 months.
Our notes: Audits are a compliance “snapshot,” scans are a routine assessment of potential weaknesses, and penetration tests are an aggressive effort to find exploitable gaps (before bad actors do). These are not redundant measures, but complementary pieces of a sound compliance strategy. Integrations and hosted services must be accounted for, although their vendors may handle penetration testing to some extent.
One patient record may arrive through a fax gateway, land in an image repository, trigger an email notification, pass through OCR software, and get copied into an EHR. Tracing this whole route end to end is critical because each hand-off might create a new copy of ePHI or create a point of potential exposure.
For every hand-off, consider recording:
The goal is to build a usable map of data flow, not merely a list of assets and features.
On-premises RightFax, hosted fax servers, and managed fax services have different divisions of responsibility.
On-prem customers typically manage operating systems, storage, network security, identity, backups, and monitoring.
Hosting and managed-service providers typically assume some of those tasks, while customers ultimately own their users, routing policies, integrations, and operating practices.
Whatever the division of duties looks like, it must be documented. Specify who configures encryption, manages privileged accounts, tracks and updates inventories, conducts security tests, restores services, manages BAAs and subcontractor agreements, and maintains audit records. Provider reports are useful, but aren’t sufficient to establish end-to-end compliance.
Platforms like OpenText Fax (formerly RightFax) include an abundance of security and compliance features. Its features can support compliance with HIPAA and preparation for the proposed Security Rule changes, but merely installing RightFax does not automatically satisfy HIPAA requirements. Deployment details make all the difference, both in terms of available safeguards (which are version- and license-dependent) and if/how they’re configured and managed.
As a starting point, below are some questions we’d review with IT, security, clinical operations, and third-party solution providers:
All the above are good ePHI handling practices regardless of whether the proposed Security Rule changes are implemented.
To review your current fax security readiness or start preparing for the expected rule change, reach out today to speak with a senior solutions engineer.