164.312(e)(2)(ii) Encryption: requirements and evidence

Does 164.312(e)(2)(ii) require encryption of ePHI in transit?

No, not automatically, but the entity must still make a decision. Under 45 CFR 164.312(e)(2)(ii), encryption of ePHI in transit is an addressable implementation specification. That means the covered entity or business associate must assess whether encryption is reasonable and appropriate for each transmission path. If it is, the entity implements it. If it is not, the entity must document why and put in place an equivalent alternative measure that is reasonable and appropriate. Leaving the question unanswered, or never writing down the reasoning, is the gap assessors look for. The decision belongs in the risk analysis, and the current text does not specify which mechanism to choose.

The underlying risk is that ePHI crossing a network can be intercepted, read or altered by anyone with access to that path, including on shared or untrusted networks. The hard part is inventory. Organizations often secure the public website and the patient portal, then miss the other places ePHI moves: outbound email and its relays, file transfers to clearinghouses, APIs between SaaS tools and the EHR, database replication, backup traffic, and service-to-service calls inside a data center or Kubernetes cluster. Each path needs an owner, a data classification and a recorded answer on encryption. Ask your team to produce that list before anyone argues about protocols, because an alternative measure cannot be justified for a path nobody has identified.

The proposed rule published at 90 FR 898 on January 6, 2025 would make encryption of ePHI in transit and at rest required, with limited exceptions, so today's addressable choice could become a mandatory control. That proposal was not final as of October 2026, so the current text still governs. Plan for the stricter outcome anyway: confirm that TLS is enforced on every inventoried path, that certificates are issued and renewed under a managed process, and that the decision record for any unencrypted path is current. HHS's own guidance on risk analysis and its NIST references, including NIST SP 800-52 on TLS selection, are the natural next reads for the technical detail.

Which transmissions and systems does encryption in transit cover?

Encryption in transit under 164.312(e)(2)(ii) applies wherever ePHI moves over a network, but the work differs sharply by path. Each card below is a scoping decision that changes what you encrypt, how you prove it, and how you document any alternative, with the risk analysis as the deciding record.

Patient-facing portals and apps

Web portals and mobile apps carry ePHI across networks you do not control, so these paths are the clearest candidates for encryption. The decision that changes the work is whether the path crosses an untrusted network, which it almost always does for patients. Check the protocol versions and cipher configuration your TLS endpoints accept, and confirm that certificates are issued and renewed by a documented process. Record the configuration baseline in the risk analysis.

Email carrying ePHI

Email is a common leak path because messages often pass through several relay servers before delivery. The scoping question is whether the sending and receiving servers can negotiate encryption in transit, and whether your organization relies on a secure messaging channel for ePHI instead of standard email. Where opportunistic encryption cannot be enforced end to end, the risk analysis should record that limit and the compensating control, such as a secure portal for sending ePHI.

APIs and clearinghouse integrations

Interfaces with business associates, clearinghouses and claims processors move ePHI between organizations, so the transport must be protected end to end. The decision that changes the work is whether the counterparty is a business associate bound by contract, and whether the endpoint is reached over the public internet or a private link. Confirm which party owns each certificate, who rotates it, and how mutual authentication is handled. Contract terms should match what the risk analysis found.

Internal service-to-service traffic

Traffic between application tiers, databases and microservices inside your own data center or cloud account is often treated as trusted, yet it still carries ePHI. The key decision is whether the path stays inside a controlled network segment with restricted access, or whether it crosses shared infrastructure or a zone with weaker controls. Where encryption is judged unnecessary, document the segmentation and access rules that justify that choice, and revisit the decision when network topology changes.

Remote administration and management sessions

Administrators often reach servers, databases and hypervisors over remote shells, consoles or remote desktop tools, and these sessions can expose credentials and ePHI in plain text if misconfigured. The scoping decision is whether administrative sessions originate from managed devices on a private network or from unmanaged locations. Confirm that every remote management protocol in use is encrypted, and that legacy protocols are disabled or limited to isolated segments.

Backup and replication links

Backup jobs and database replication copy full datasets, which makes their transport a high-impact path if it is exposed. The decision that changes the work is whether replication crosses a site boundary, a provider network or a cloud region outside your direct control. Confirm the transport protocol, certificate trust chain and whether the backup provider is bound as a business associate. Test restores as part of the same review, since encrypted transfers that fail silently leave gaps that only surface during recovery.

How the addressable choice gets documented and defended

Addressable does not mean optional. Under 45 CFR 164.306(d), an entity must assess whether encryption of ePHI in transit under 164.312(e)(2)(ii) is reasonable and appropriate for its environment. If it is, the entity implements it. If it is not, the entity must document why and implement an equivalent alternative measure, provided that alternative is itself reasonable and appropriate. Doing nothing and writing no reason is not one of the three outcomes. An assessor will treat an undocumented decision as a gap, even where traffic happens to be encrypted, because the rule asks for the reasoning as well as the result.

The decision belongs inside the risk analysis. OCR's risk analysis guidance names whether and how to use encryption as a question the analysis should inform, so the written decision should point back to the specific risk entries it relies on: which ePHI flows cross networks, which parties receive them, which threats were rated, and what compensating controls reduce the rating. A defensible record for a web portal, a patient messaging service or a partner API usually shows the protocol in use, the certificate and key management process, and the review date. For an internal flow that is not encrypted, it shows why the network segment is isolated, what access controls and monitoring apply, and what would trigger reconsideration. Confirm the current OCR guidance wording against the HHS risk analysis page before quoting it in your own documentation.

When an assessor reviews this topic, expect requests for the risk analysis entries, the transmission security decision record, the inventory of ePHI transmission paths with their protection status, configuration evidence such as TLS settings and certificate records, and the dated approvals from whoever owns the risk. Ask your team to confirm that each decision has an owner, a review cycle, and a link to any compensating control. If the 2025 proposal to make encryption mandatory is finalized, decisions recorded as alternatives today will need to be revisited, so keep them in a form that can be reopened quickly.

How an assessor tests encryption in transit

This table sets out, row by row, what an assessor does to test transmission encryption under 164.312(e)(2)(ii), what evidence they request and where organizations most often fall short. Read it as a checklist to prepare your own evidence before an audit or OCR review, since the assessor will test the documented decision as closely as the live configuration.

Test area	What the assessor does	Evidence requested and common findings
Transmission inventory	Checks that every path carrying ePHI over a network is listed, including web portals, APIs, email, file transfer, remote access and replication between sites.	Current data flow diagrams and system inventory. Common finding: an email gateway, backup link or vendor integration missing from the list.
Documented addressable decision	Reads the written decision for each transmission path, confirming the entity assessed whether encryption is reasonable and appropriate and recorded the reasoning.	Risk analysis entries and signed decision records. Common finding: the entity marked encryption as not applicable without documenting why or what alternative it used.
TLS endpoint configuration	Scans or inspects externally and internally facing endpoints to confirm encrypted sessions are enforced and weak protocol versions and cipher suites are disabled.	Scan output, server configuration files and load balancer settings. Common finding: plaintext HTTP still reachable, or legacy protocol versions still accepted.
Protocol and cipher review	Compares enabled protocols and ciphers against the entity's own stated standard, which assessors often benchmark against NIST SP 800-52, an informational NIST publication that HHS lists in its Security Rule guidance.	Written cipher policy and periodic scan results. Common finding: no defined baseline, so the configuration cannot be shown to be reasonable.
Certificate issuance and renewal	Samples certificates in use, checking issuing authority, validity dates, key length, and whether renewal happened before expiry.	Certificate inventory, issuance logs and renewal alerts. Common finding: expired or unmanaged certificates on internal services, or certificates without a named owner.
Sampling of email and API paths	Selects a sample of email relays, API endpoints and partner connections and tests whether each one negotiates an encrypted session.	Test results per path, with dates and the tool used. Common finding: opportunistic email encryption that falls back to plaintext without any alert.
Exceptions and alternative measures	Reviews every exception, confirming each one has an approved rationale, compensating control, owner and review date.	Exception register and approvals. Common finding: exceptions that never expire or that rely on a network control no one has tested.

Which evidence shows encryption in transit is working

Encryption in transit under 164.312(e)(2)(ii) is an addressable mechanism, so the evidence has two jobs: showing that encryption is configured on every path that carries ePHI, and showing why any path is not encrypted. The artifacts below connect those two jobs and should be refreshed on a schedule and whenever a system changes, not rebuilt the week before an assessment.

Transmission inventory with encryption status

This is a list of every path that carries ePHI between systems, users, partners and business associates, with the protocol used and whether it is encrypted. Start from the risk analysis data flow map, then record each web session, email route, API call, database connection and file transfer. Check that the inventory matches what your network and application monitoring actually shows, since undocumented paths are a common gap. Ask your assessor how often they expect the inventory to be re-verified, and confirm that answer against your own change process.

Written addressable determination

For each transmission path that is not encrypted, or is encrypted only by an equivalent measure, the file should show your reasoning under 164.306(d)(3). It must reference the risk analysis that drove the decision, name the alternative control if one is used, and carry an approval date. Keep it tied to the inventory entry it covers so an assessor can trace one to the other. Review it when the data flow, the risk rating or the threat picture changes.

TLS configuration exports and scan results

Configuration exports show the protocol versions, cipher suites and certificate settings each endpoint accepts, while scan results show what an outside view actually sees. Schedule exports from load balancers, web servers and gateways into version-controlled storage, and compare each export with the previous one to catch drift. Confirm which scanning tool, scan frequency and report retention your environment uses, and keep the reports that show remediation of findings, not only the clean results. NIST SP 800-52 is the informational reference for TLS selection.

Certificate inventory with issuer and renewal dates

A certificate inventory lists each certificate guarding an ePHI path, its issuer, its subject names, its expiration date and the team that owns renewal. Expired or unknown certificates are one of the most common reasons encrypted paths fail in practice. Where certificates are issued by a private CA or automated issuer, record that chain of trust as well. Automated issuance and renewal tools can generate much of this record, but you should confirm how each one logs issuance, renewal and failures in your environment.

Email and API gateway settings

Email gateways and API gateways are where ePHI often leaves a system without anyone reviewing the path. Export the relevant settings: whether opportunistic or enforced TLS is required for each mail domain, which API endpoints reject plaintext requests, and how gateway policies are versioned. Note any partner that accepts only unencrypted delivery, since that becomes an exception record. Re-export these settings after each gateway change, and confirm with your gateway vendor how it logs policy changes.

Exception records with approval and review dates

Every unencrypted or alternatively protected path needs an exception record that names the path, the justification, the compensating control, the approver and the next review date. Exceptions with no review date tend to become permanent without anyone deciding that they should. Store these records with the addressable determinations and link them to the risk management plan. Confirm your own retention period for these records with your counsel and compliance lead, since the Security Rule's documentation requirements in 164.316 set a six-year retention rule for documentation.

How to implement encryption in transit in six steps

This sequence turns the addressable transmission encryption specification into a documented decision, a configured baseline and a monitored set of endpoints, so an assessor can trace each ePHI path from inventory to verified configuration.

Inventory every ePHI transmission path
Map every route ePHI takes between systems, users and outside parties, including web portals, email, API calls, file transfers, backups, replication links, remote administration and vendor connections. Your IT and security team owns the inventory, and system owners confirm their own paths. The output is a transmission inventory listing each path, its endpoints, the data it carries and the network it crosses. You know this step is done when system owners have signed off on their rows and no path is labeled unknown.
Run the addressable assessment and record the decision
For each path, the security official and risk owners assess whether encrypting ePHI in transit is reasonable and appropriate, using the risk analysis as the input. Where encryption is adopted, the record names the mechanism. Where it is not, the record explains why and names an equivalent alternative measure, which must also be reasonable and appropriate. The output is a signed decision record per path, kept with the risk analysis. You know this step is done when every path in the inventory has a dated decision and an accountable approver.
Set a TLS configuration baseline
Write a configuration baseline for every encrypted channel that states the minimum protocol versions, the permitted cipher suites, certificate key requirements and the settings that disable legacy protocols and weak ciphers. Engineering writes it and security approves it. Confirm the protocol versions and cipher choices your baseline allows against current NIST guidance, including NIST SP 800-52, before adoption. The output is a versioned baseline document with an owner and a review date. You know this step is done when the baseline is applied to a test environment and scanning confirms that legacy protocols are refused.
Issue and automate certificates for each endpoint
Assign an issuer to every encrypted endpoint, whether an internal certificate authority, an ACME provider or a self-signed root limited to test use, and record who controls each issuer. Automate issuance and renewal where the platform supports it, so certificates are renewed before they expire. In Kubernetes or OpenShift, cert-manager can create and renew workload certificates from configured issuers. The output is a certificate register listing each endpoint, issuer, key type, expiry date and renewal method. You know this step is done when no endpoint depends on a manually tracked certificate.
Extend encryption to email and API integrations
Work through the paths that often fall outside the web tier, including mail transfer between servers, client connections to mailboxes, service-to-service API calls and integrations with third parties. Enforce transport encryption where the mail server, API gateway or integration engine supports it, and confirm the setting on both sides of each connection. Where a counterparty cannot support it, document the equivalent alternative measure from step two and the compensating controls. The output is a set of verified connection settings and any documented exceptions. You know this step is done when each integration has either a confirmed encrypted connection or an approved exception.
Verify and monitor configuration over time
Test each channel against the baseline with external and internal scans, and check that certificates are valid, chained correctly and matched to the right names. Set alerts for expiring certificates, configuration drift and newly exposed endpoints, and review the results on a schedule the security team sets. Log configuration changes and certificate issuance so the activity can be reviewed later. The output is a verification report and a monitoring record that the security official reviews. You know this step is done when the report shows no failed checks or each failure has a tracked remediation.

Which open-source tools support encryption in transit evidence

Encryption in transit under 164.312(e)(2)(ii) is an addressable mechanism, so your evidence starts with your risk analysis and the decision it records. The tools below cover different parts of that evidence: issuing certificates, running an internal certificate authority, protecting application data and handling file storage. Each one covers a different layer, so none of them proves transmission encryption alone.

cert-manager for Kubernetes workloads

cert-manager (Apache-2.0) creates TLS certificates for workloads running in Kubernetes or OpenShift. It can draw certificates from ACME (Let's Encrypt), a CA key pair, HashiCorp Vault, CyberArk or a self-signed issuer, stores them in Kubernetes Secrets and renews them before they expire. For this specification, the evidence is the issuer configuration, the certificate inventory and renewal records. Confirm which issuer your ePHI workloads use and who controls the private keys. Check the license terms yourself before you deploy.

FreeIPA internal certificate authority

FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag, used to issue and manage certificates for internal systems. It suits services that do not face the public internet, where your organization runs its own trust chain. The evidence to retain includes the CA configuration, issuance records and revocation handling. Confirm that the CA's key protection and access controls match your risk analysis. Review the license terms for your distribution before relying on it.

OpenBao transit encryption

OpenBao (MPL-2.0) has a transit secrets engine that encrypts and decrypts application data without storing that data, signs and verifies data, and supports versioned keys with rotation. It protects data handled by applications, so it does not secure the network channel itself. Its evidence is key rotation history and access policies for encrypt and decrypt operations. Confirm how it fits your transport design before you count it as transmission evidence. Review the license terms before deployment.

Nextcloud server-side encryption

Nextcloud (AGPL-3.0-only) server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, so it is not evidence for transport encryption on its own. Use it as storage evidence only. Confirm its transport settings separately, including HTTPS for clients and sync traffic. Check the license terms for your deployment.

What meeting encryption in transit costs in money and effort

This table breaks the work of meeting 164.312(e)(2)(ii) into its cost components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the right-hand column to build the questions you put to a partner or vendor in a written quote.

Work item	Cost type and whether it recurs	What drives it, and how to keep it down
Transmission inventory	Engineering time, one-time, refreshed when systems change	Number of interfaces, EHR and imaging links, email gateways and partner APIs carrying ePHI. Keep it down by starting from the existing data flow map and asking for a quote scoped to named systems.
Addressable assessment and written decision	Compliance and engineering time, one-time with annual review	Complexity of the risk analysis and how many transmission paths need a documented rationale. Reduce it by reusing the risk analysis outputs and recording one decision per path type.
TLS configuration and hardening	Engineering time, one-time, then recurring as protocols change	Number of endpoints and legacy clients that must be upgraded. Self-hosted open-source web servers and load balancers remove license spend, but the quote should cover testing against the chosen TLS profile guidance in NIST SP 800-52.
Certificate issuance and automation	Tooling (open source or licensed) and engineering time, one-time setup then recurring operation	Whether certificates are issued by hand or automated, and which CA is used. cert-manager is Apache-2.0 licensed and renews Kubernetes workload certificates, so ask whether the quote includes an internal CA such as FreeIPA's Dogtag-based CA or an external issuer.
Email and API integration work	Engineering time, one-time per integration, with recurring vendor-side changes	Number of partner endpoints and whether each counterparty supports the same TLS version. Ask the quote to list each integration separately so the cost of each can be compared.
Evidence upkeep	Compliance and operations time, recurring	Frequency of configuration scans, certificate inventory reports and change records. Reduce it by having monitoring output retained automatically rather than gathered by hand before each review.
External testing or review	External testing fees, recurring or per engagement	Whether the test covers only the public edge or internal transmission paths too, and how many systems are in scope. Ask for a fixed-scope written statement of what is tested and what is not.
Auditor sampling	Auditor fees, recurring with each assessment cycle	Number of transmission paths the assessor samples and how well the documented decision matches observed configuration. Keep it down by keeping one current inventory that maps each path to its decision and evidence.

Who owns, implements and independently tests encryption in transit

Your organization owns the Security Rule obligation, including the decision on whether encryption in transit is reasonable and appropriate. Under the addressable framework, that decision belongs in your risk analysis and must be recorded with your reasoning. If you conclude that a measure is not reasonable and appropriate, you must document why and decide on an equivalent alternative. No vendor can make that call for you, and a partner's recommendation does not transfer the accountability.

Addressable decision: Record whether TLS or another encryption mechanism is reasonable and appropriate for each path that carries ePHI, and sign off on the result.
Risk acceptance: Where you decide not to encrypt a path, document the justification and any equivalent measure, and have the risk owner approve it.
Transmission inventory: Maintain a current list of every channel that carries ePHI, including web portals, email, APIs, file transfers, interfaces to business associates and remote access.
Policy and ownership: Assign a named owner for certificate lifecycle, protocol versions and cipher policy, and keep it in your written procedures.
Review cadence: Revisit the decision when the risk analysis changes, when new channels appear, and when the proposed rule is finalized.

Before engaging anyone, confirm that your inventory and risk decisions are complete, because a partner cannot prepare evidence for decisions you have not made.

Questions buyers ask about encrypting ePHI in transit

Is encryption of ePHI in transit legally required under HIPAA today?

Not as a flat mandate. Under 45 CFR 164.312(e)(2)(ii) the encryption specification is addressable, so your organization must assess whether encrypting ePHI in transit is reasonable and appropriate for each path. If it is, you implement it. If it is not, you must document why and implement an equivalent alternative measure that is reasonable and appropriate. Regulators will look for that reasoning in your risk analysis, so an undocumented decision not to encrypt is the weak point. Most organizations find that encrypting web, email and API traffic that carries ePHI is hard to justify declining. Confirm the position against the eCFR text and HHS guidance with your own counsel or compliance lead.

How long does securing data in transit take, and what drives the duration?

No supplied source gives a duration, so treat any number you hear as a claim to verify. The work scales with the number of data paths that carry ePHI, including web portals, API calls, database connections, file transfers, messaging and backup replication. Legacy integrations drive the most time because older clients may not support current TLS versions, and each one may need an upgrade, a proxy or a documented exception. Ask any provider to break the estimate down by path, and to name which paths are in scope and which are excluded before work starts.

What does the work need from our staff?

Three groups of people are needed. System owners confirm which applications and interfaces handle ePHI and which vendors sit on each path. Network and application administrators provide access to load balancers, certificate stores, mail gateways and integration engines, and they test changes before cutover. A named risk decision owner, usually the security official or a delegate with authority, decides which paths are encrypted, which use an alternative measure and how exceptions are recorded. An implementation partner can prepare configurations and evidence, but it cannot make that decision for you.

Can a small team handle transmission encryption in-house?

A small team can often handle the core work in-house if it has someone who understands TLS configuration, certificate lifecycle and the organization's data flows. The harder parts are inventory and documentation: finding every path that carries ePHI, including the ones nobody remembers, and writing the addressable decision for each. Certificate automation is available in open-source tooling. For example, cert-manager (Apache-2.0) creates and renews TLS certificates for workloads in Kubernetes or OpenShift, and FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag. Your team should confirm each tool's fit with its own environment before adopting it.

What would the 2025 proposed rule change for encryption in transit?

The January 2025 proposed rule (90 FR 898, RIN 0945-AA22) would require encryption of all ePHI in transit and at rest, with limited exceptions, which would convert the current addressable specification into a required one. It is a proposal, not a final rule. As of October 2026 no final rule has been published, and the latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. Plan against the current text, but design new paths so they can meet the stricter requirement without redesign. Watch the Federal Register and the Unified Agenda for changes.

Is email containing ePHI required to be encrypted?

Under the current rule, email carrying ePHI falls under the same addressable transmission security analysis as other network paths. You must decide whether encryption is reasonable and appropriate, implement it if so, and document an equivalent measure if not. In practice, most organizations enforce TLS for server-to-server mail transport and provide an encrypted option or portal for messages sent to recipients who cannot accept TLS. Confirm your mail platform's capabilities and the recipient handling process with your administrator, and record the choice in your risk analysis.

What can an implementation partner not do for us?

A partner cannot issue an attestation, audit report or HIPAA certification. HHS states that no Security Rule standard requires certification and that HHS does not endorse or recognize private certifications. A partner can configure encryption, prepare systems and document evidence, such as configuration baselines, certificate inventories and test results. The organization still owns its controls, its risk decision and its compliance posture. DeployOpen works this way: it prepares systems and evidence in the client's own infrastructure, and it does not issue reports or certifications.

How DeployOpen scopes and prepares encryption in transit evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so transport encryption for ePHI is set up and evidenced where the data actually moves. We prepare the systems and records; your organization owns the risk analysis decision and the control, and an independent assessor reviews the result.

How we scope

Written scope lists every ePHI transmission path in the engagement: web, email, APIs and service-to-service traffic.
Scope records which paths use TLS today, which use plaintext or legacy protocols, and which owners hold each path.
Scope states whether your risk analysis already covers the encryption decision, so gaps are named before work starts.

How we build

We configure TLS on in-scope services and document protocol versions and cipher settings for each endpoint.
Certificates are issued and renewed through a managed issuer, such as cert-manager with a CA you select, and logged.
Where encryption is not applied to a path, we document the reason and the equivalent alternative measure for your review.

How we hand over

Handover includes configuration records, certificate inventory and a per-path transmission encryption register.
Test results show the scans and handshake checks run against each in-scope endpoint, with dates and tool versions.
Documentation notes which decisions remain yours to approve, including the addressable determination and retention of records.

How we support

Ongoing support is available as a retainer for certificate renewal monitoring, upgrades and periodic configuration review.
Retainer scope, response expectations and review frequency are agreed in writing, and should be confirmed in your quote.
Changes to the 2025 proposed rule are tracked, so the register can be updated if the final rule changes the requirement.

164.312(e)(2)(ii) Encryption