Is Your Remote Access Software Actually HIPAA Compliant?

TL;DR:

• No remote access software is HIPAA compliant out of the box since the U.S. Department of Health & Human Services (HHS) doesn't certify software in that way.
• The HIPAA Security Rule names five technical safeguards that map to specific settings, and auditors request sessions records that prove those settings were on during the session.
• Most compliance exposure in remote support comes from configurations left to their default settings. The fastest path to compliance is a permissions and controls review.

Many vendors market their solutions as HIPAA-compliant remote access software, creating the illusion that purchasing a license automatically checks the regulatory box. However, the U.S. Department of Health and Human Services (HHS) does not certify any software or solution as compliant.

True HIPAA compliance is not a feature you turn on out of the box. Rather, it depends on how your team configures administrative controls, how technicians handle electronic protected health information (ePHI) during live sessions, and whether your software vendor signs a business associate agreement (BAA).

Remote access is HIPAA compliant when the connection is encrypted, every user is uniquely identified, sessions are logged, access is restricted to the minimum necessary, and the vendor has signed a business associate agreement (BAA).

Compliance is a deployment property and not a feature built into software. While vendors frequently advertise their products as compliant, HIPAA applies to how organizations handle and protect ePHI across their operations.

Remote access software equipped with robust security settings can easily be rendered non-compliant. For example, if it's installed without password protection or used without session logging, this poses a compliance issue. Software provides the necessary safeguards, but your configuration and operational policies dictate actual compliance. Staying HIPAA compliant is in your control.

Does a remote access vendor have to sign a BAA?

Any vendor whose platform creates, receives, maintains, or transmits ePHI qualifies as a business associate under HIPAA and is legally required to have a signed BAA in place. This applies even if a business is temporarily accessing ePHI during a live remote session.

Some remote access vendors refuse to sign a BAA or wrongly claim conduit exception status to avoid liability. As HHS notes:

"The conduit exception is limited to entities that only provide transmission services for PHI [such as the US Postal Service]… Entities that access PHI on a regular or frequent basis to perform a service on behalf of a covered entity are not conduits."

Remote IT solutions and most other software don't fit this narrow definition, so you should always verify BAA availability with the vendor before evaluating technical features.

The HIPAA Security Rule defines five specific technical safeguards, primarily focused on permissions and controls, to protect ePHI during remote interactions. In practice, each regulatory requirement maps directly to a specific feature or toggle that your administrator must explicitly enable within your chosen platform.

Technical Safeguard	What the Rule Asks For	Setting to Check
Access control	Unique user identification and emergency access controls	Enable unique user IDs and automatic session timeout limits
Audit controls	Hardware, software, and procedural mechanisms to record activity	Turn on audit logs and log retention
Integrity controls	Policies and procedures to protect ePHI from improper alteration/destruction	Enable file integrity monitoring or checksum/hash verifications
Person or entity authentication	Procedures to verify that a person seeking access is who they claim	Require multi-factor authentication (MFA) or single sign-on (SSO) for all logins
Transmission security	Guard against unauthorized access to ePHI in transit	Ensure TLS version 1.2 or higher is enforced for every session

When an auditor evaluates a remote support workflow, software features are irrelevant. The auditor requires concrete, verifiable records.

The HIPAA Security Rule's audit controls standard (45 CFR § 164.312(b)) explicitly mandates that organizations "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

Following a session, an auditor expects a clear audit trail showing:

• Who connected and when
• Which device was reached and which records were visible
• What the technician was permitted to do in that session
• Whether the end user approved the connection
• How long the session ran and where the recording is stored

Automated session summaries generate these consistent, audit-ready records directly from the session log without creating administrative burden.

How long do you have to keep remote session records?

Under the HIPAA Security Rule, organizations must retain required compliance documentation, including remote session logs and audit trails, for at least six years from the date of creation or the date when it was last in effect, whichever is later.

From a practical perspective, however, archiving six years of raw log files is only useful if those records remain easily searchable. During a regulatory audit or incident investigation, an auditor will ask for precise documentation detailing a specific session on a specific date, making searchable, centralized log management just as critical as adhering to the retention period itself.

Most compliance exposure stems from default software configurations rather than flawed encryption. For example, a technician might initiate a session on a workstation displaying patient records using a shared administrative account, with file transfer privileges enabled and automatic session recording switched off.

Similarly, these common technical situations silently bypass administrative intent and present compliance issues:

• Shared technician logins, which break unique user identification
• File transfer or clipboard functionality left enabled on clinical endpoints
• Unattended access configured without an end-user approval step
• Session recording switched off to conserve local storage space
• Offboarded technicians left sitting in active permission groups

Evaluating potential remote access software requires asking direct questions to confirm whether a solution can support a HIPAA-compliant architecture. Bring these six yes-or-no questions to your vendor discussions to quickly establish operational readiness:

1. Will you sign a formal BAA?
2. Is every remote session encrypted end-to-end, and to what standard?
3. Can permissions be assigned based on technician role rather per account?
4. Are sessions logged and recorded by default or only when enabled?
5. How long are records retained, and can we export them for an audit?
6. Can you share a recent independent HIPAA assessment of the product?

The HIPAA Security Rule's proposed update, published in January 2025, would remove the "addressable" designation, making safeguards like encryption and MFA strictly required rather than optional based on risk assessment.

The update remains a proposal that's under review. In the meantime, the Office for Civil Rights (OCR) is enforcing the current Security Rule, while federal regulatory plans point toward July 2027 for final action.

Teams that already enforce end-to-end encryption and mandatory MFA across remote access workflows will face no operational disruption if these updates are finalized. This stands as the strongest reasoning for turning those controls on today.

LogMeIn provides the technical capabilities required to support HIPAA compliant remote access software across healthcare environments. Through granular role-based permissions, automated session recording with audit-ready logs, and mandatory end-user approval before initiating remote control, administrative teams maintain total visibility over technical interactions. LogMeIn Rescue's controls are also independently tested. In its 2026 HIPAA assessment, compliance and cybersecurity auditing platform Thoropass rated Rescue "Satisfactory" against the HIPAA Security and Breach Notification Rules, with no findings across every applicable standard. Additionally, LogMeIn's parent company, GoTo, makes its standard BAA available to covered entities.

Explore how our IT support, built for healthcare compliance, helps secure your remote workflows and protect patient data.

Is LogMeIn HIPAA compliant?

While no software product is inherently HIPAA compliant out of the box, LogMeIn does provides the technical, physical, and administrative safeguards required under the HIPAA Security Rule and publishes a business associate addendum. An independent HIPAA assessment of LogMeIn Rescue found no findings against the Security Rule or Breach of Notification Rule. Remember that compliance is achieved only when the covered entity signs the BAA and configures the software's security controls to protect patient data.

Does HIPAA require encryption?

Under the HIPAA Security Rule, encryption is defined as an "addressable" implementation specification rather than a mandate. However, covered entities must implement encryption for electronic protected health information (ePHI) in transit and at rest unless they document a compelling reason why it is unreasonable and deploy an equivalent alternative safeguard.

What makes software HIPAA compliant?

Software itself cannot bear a standard official HIPAA certification. Instead, it can provide the functional architecture to support compliance. Software enables compliance when the vendor offers essential technical safeguards that map to settings, such as access controls, audit logging, and strong transmission encryption. Additionally, a vendor must agree to execute a business associate agreement to further strengthen a compliance posture. The covered entity must then configure and operationalize those capabilities in alignment with HIPAA rules.