HIPAA Encryption Requirements: Key Requirements & Templates (2026)

Today, enterprise buyers and regulators expect proof of real security. In healthcare, every procurement questionnaire, business associate agreement, and due‑diligence request includes explicit questions about encryption. Without credible evidence that electronic protected health information (ePHI) is encrypted at rest and in transit, deals stall and regulators turn up the heat. This article, written from the perspective of a practitioner with more than 25 years of combined experience and a team that has supported over 6,000 audits, examines HIPAA encryption requirements and how they fit into a broader security programme. We will explain what the law currently demands, the difference between “addressable” and mandatory controls, current proposals to make encryption compulsory, and practical guidance for implementing and operating encryption. Readers will learn how to protect stored and transmitted data, manage keys, integrate encryption into a risk‑based compliance programme, and prepare evidence for audits. We will reference authoritative materials like the Code of Federal Regulations, NIST publications, and HHS guidance, and we will answer frequently asked questions about the 2025 changes and what they mean for covered entities and business associates.

Why Encryption Matters for Healthcare Data

Healthcare organisations handle some of the most sensitive personal information. Attackers know this and have increasingly targeted hospitals, clinics, and service providers. According to IBM’s 2025 Cost of a Data Breach Report, the average cost of a U.S. data breach rose to $10.22 million, and healthcare data breaches remain the costliest at $7.42 million. Breach disclosure obligations, reputational harm, and fines amplify those costs. From an operational perspective, unencrypted ePHI can end up in backup tapes, misplaced laptops, or intercepted transmissions, exposing patients and triggering mandatory reporting. Meeting HIPAA Encryption Requirements is a fundamental step in reducing these risks.

Encryption is a technical safeguard that converts readable data into ciphertext, rendering it unusable without a secret key. Properly implemented encryption protects confidentiality even when other controls fail. It is also a core requirement in most modern frameworks. The HIPAA Security Rule lists encryption and decryption as an “addressable” implementation specification for access control and transmission security. NIST’s guidance on risk analysis instructs organisations to “decide whether and how to use encryption” after evaluating risks.

HIPAA Encryption Requirements (second mention) should not be viewed as a box‑check; they are a defence against real threats. Encryption is also widely recognised across other frameworks such as SOC 2, ISO 27001, and GDPR. When organisations adopt strong encryption, they not only protect patients but also accelerate sales cycles. Buyers often ask for proof that data is encrypted at rest and in transit; failure to provide evidence can delay contracts by weeks or months. By investing in encryption and key management early, healthcare teams reduce risk and support compliance across multiple frameworks.

What HIPAA Says About Encryption

The HIPAA Security Rule (45 C.F.R. § 164.312) sets national standards to protect ePHI. Under the “Access control” standard, regulated entities must implement policies and procedures for electronic information systems. One of the implementation specifications is “Encryption and decryption,” which, according to the Code of Federal Regulations, requires covered entities and business associates to implement a mechanism to encrypt and decrypt ePHI. The rule treats encryption as “addressable” rather than strictly required; organisations must assess whether encryption is reasonable and appropriate in their environment.

Similarly, the “Transmission security” standard requires technical measures to guard against unauthorised access to ePHI being transmitted over an electronic network. The implementation specification states that regulated entities must “implement a mechanism to encrypt ePHI whenever deemed appropriate”. In practice, this means that if unencrypted transmissions could result in a breach, encryption becomes necessary.

HIPAA uses the term “addressable” to provide flexibility. An addressable specification must either be implemented or an alternative measure must achieve the equivalent protection. The intention is not to give a free pass but to allow small clinics and larger hospitals to adapt controls based on risk and resource constraints. Nevertheless, encryption is widely recognised as the most effective way to protect confidential data.

“Addressable” vs. Mandatory Requirements

Many professionals misunderstand the difference between addressable and mandatory controls. Mandatory (or required) specifications must always be implemented. Addressable controls require risk analysis and allow for documented justification if a different measure can achieve the same outcome. The HHS guidance on risk analysis instructs organisations to consider whether and how to use encryption when designing safeguards.

Over the past two decades, regulators have signalled that encryption is not optional for most circumstances. In December 2024, the Office for Civil Rights (OCR) issued a Notice of Proposed Rulemaking (NPRM) to strengthen the HIPAA Security Rule. Among other changes, the proposal would remove the distinction between “required” and “addressable” implementation specifications and make all implementation specifications mandatory with limited exceptions. The fact sheet summarising the proposed rule states that it would “require encryption of ePHI at rest and in transit, with limited exceptions”. This shift reflects the evolving threat environment and aligns HIPAA with other frameworks that already mandate encryption.

If finalised, the NPRM will compel healthcare organisations to ensure that all stored ePHI, whether on servers, laptops, or portable devices, is encrypted, and that all data in transit uses approved encryption protocols. The comment period closed in early 2025, and final regulations are expected in 2026. Healthcare leaders should begin planning for mandatory encryption now.

Encryption for ePHI at Rest

What “Data at Rest” Means

Data at rest refers to ePHI stored on any medium when it is not actively being transmitted. Examples include information residing on servers, desktops, laptops, mobile devices, backup tapes, and cloud storage. The HIPAA rule applies to all forms of electronic media, from on‑premises databases to portable USB drives. Organisations must identify where ePHI lives to apply appropriate controls. In our experience managing more than 6,000 compliance engagements, mapping data flows is one of the first tasks we perform for clients. Without a clear inventory, encryption might protect one repository while leaving another exposed.

Encryption Standards and Protocols

Not all encryption is equal. Healthcare providers should rely on standards sanctioned by NIST and the federal government. The Advanced Encryption Standard (AES) is a FIPS‑approved symmetric block cipher that can encrypt and decrypt data using keys of 128, 192, or 256 bits. AES‑256 provides the strongest protection and is widely adopted across government and industry. To ensure that encryption modules are trustworthy, FIPS 140‑2 specifies security requirements for cryptographic modules and provides four levels of validation. The standard emphasises the need for secure design, key management, and self‑tests; modules validated through the Cryptographic Module Validation Program (CMVP) are accepted by U.S. federal agencies for protecting sensitive information. When purchasing encryption software or hardware, healthcare organisations should verify that the product has been FIPS 140‑2 or FIPS 140‑3 validated.

Hardware security modules (HSMs) can further strengthen encryption for data at rest by isolating keys in tamper‑resistant devices. For cloud environments, many providers offer dedicated secret management services with hardware roots of trust. Organisations should use AES‑256 encryption for database fields containing ePHI, full‑disk encryption for laptops and desktops, and file‑level encryption for shared directories. On servers, Transparent Data Encryption (TDE) can encrypt storage volumes without changing application code.

Best Practices for Protecting Stored Data

From our fieldwork, we see several practices that differentiate secure programmes:

• Full‑disk encryption: NIST’s guide to storage encryption explains that full‑disk encryption (FDE) encrypts all data on a hard drive and requires pre‑boot authentication before loading the operating system. FDE mitigates theft of laptops and desktops, which remains a frequent source of breaches.
  
  
• Database and application encryption: Use industry‑standard libraries to encrypt sensitive columns and configuration files.
  
  
• Backup encryption: Ensure that backup software encrypts data at rest. Many breaches occur when unencrypted backup tapes are lost or stolen.
  
  
• key management: Use centralised key management to separate encryption keys from the data. Never hard‑code keys in application code.
  
  
• Logging and monitoring: Record encryption status and check that encryption remains enabled after software updates.

Implementing these measures across servers, endpoints, and cloud services may appear daunting. With Konfirmity’s managed service, we embed encryption controls into your stack and track them year‑round. Because encryption is validated daily, teams avoid the last‑minute scramble before audits.

Encryption for Data in Transit

Why Protect Data While Moving

As soon as ePHI leaves a secure environment—whether through API calls, email, or file transfers—it is at risk of interception. Attackers use man‑in‑the‑middle attacks, spoofed Wi‑Fi access points, and compromised routers to capture data on the wire. Intercepted transmissions can lead to breaches even if the endpoints are secure. Regulators recognise this risk; HIPAA requires transmission security measures to guard against unauthorised access.

Encryption Protocols for Transmission

The most widely used protocol to secure data in transit is Transport Layer Security (TLS). NIST Special Publication 800‑52 Revision 2 requires that government TLS servers and clients support TLS 1.2 configured with FIPS‑approved cipher suites and further mandates support for TLS 1.3 by January 1, 2024. TLS 1.3 reduces the number of handshake messages and removes older ciphers, improving both security and performance. Organisations should disable SSL versions and TLS 1.0/1.1 except when interoperability with legacy systems is unavoidable. When using TLS 1.2, use cipher suites that offer authenticated encryption with associated data (AEAD), such as AES‑GCM.

Other secure transmission approaches include IPsec VPNs, which operate at the network layer, and secure shell (SSH) protocols like SFTP for file transfers. NIST provides guidance on these protocols; for example, its guide to IPsec VPNs outlines how to configure tunnels and manage keys. Virtual private networks can segment traffic between clinics and cloud environments, protecting ePHI from internet threats.

Is TLS Alone Enough for HIPAA?

Using TLS or other encryption protocols is necessary but not sufficient. HIPAA Encryption Requirements (third mention) sit within a framework that also demands authentication, audit controls, and integrity protections. TLS ensures confidentiality and integrity in transit, but a compromise of either endpoint can still expose data. Therefore, combine encryption with:

• Strong authentication: Multi‑factor authentication (MFA) for user sessions and mutual TLS for service‑to‑service communication.
  
  
• Certificate management: Rotate certificates before expiration and monitor for weak ciphers.
  
  
• Logging: Capture connection logs and send them to a central SIEM.
  
  
• Network segmentation: Limit network exposure by placing sensitive systems behind firewalls and VPNs.

When we integrate encryption into client environments, we build layered controls: TLS with mutual authentication between microservices, VPN tunnels between sites, and API gateways enforcing rate limiting. These measures not only protect data but also produce evidence that stands up to audit scrutiny.

Encryption key management

Encryption is only as strong as its keys. Management of cryptographic secrets covers the generation, storage, rotation, and retirement of cryptographic keys. FIPS 140‑2 emphasises the importance of key management in secure cryptographic modules. In practice, poor key management is one of the most common deficiencies we observe. Common pitfalls include storing keys in configuration files, failing to rotate keys, and lacking procedures to retire old keys.

• Generation and storage: Use dedicated hardware security modules or cloud secret management services that offer hardware‑backed storage. Keys should never be stored on the same server as the data they protect.
• Rotation: Establish a schedule for rotating keys. For example, rotate database encryption keys yearly or when an administrator leaves. Rotation helps limit the damage if a secret is compromised.
• Separation of duties: Define roles for key custodians who can generate and rotate keys but cannot read data. Access to key material must be logged and monitored.
• Destruction: When retiring a key, ensure it cannot be reconstructed. Use secure deletion procedures and document the destruction.
• Policy: Document the key management process. A well‑defined policy will describe the key hierarchy, the cryptographic modules used, rotation intervals, and the approval process for key changes.

Our team has built managed key services for clients where keys reside in FIPS‑validated modules, rotation is automated, and access requires dual control. This level of rigour reduces the risk of key leakage and produces clean evidence for auditors.

Integrating Encryption into Your HIPAA Compliance Programme

Performing a Risk Assessment

Encryption decisions must be grounded in a documented risk analysis. The HIPAA Security Rule requires organisations to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to ePHI”. During risk analysis, identify where ePHI is stored, transmitted, and processed; evaluate potential threats; and assess the likelihood and impact of compromise. The HHS guidance recommends that organisations determine whether and how to use encryption based on this analysis. Without documentation, auditors will treat a lack of encryption as a deficiency.

From our experience, a risk assessment typically takes two to four weeks when done diligently. We start by interviewing stakeholders, mapping data flows, reviewing existing controls, and rating threats using industry‑accepted methods like CVSS. For example, unencrypted laptops may score high because theft is common and the impact is severe. The output of the risk assessment justifies the encryption controls we implement.

Risk Management and Monitoring

Risk management is a continuous process. After implementing encryption, monitor its effectiveness and adapt to new threats. The proposed 2024 HIPAA amendments would require regulated entities to review the effectiveness of certain security measures at least once every 12 months. We advise clients to track the following metrics:

• Percentage of production servers with encryption enabled.
  
  
• Number of applications using deprecated TLS versions.
  
  
• Time since last key rotation for each key.
  
  
• Number of failed encryption or decryption attempts.

Monitoring these metrics helps ensure your programme meets HIPAA Encryption Requirements and remains ready for audits.

Continuous monitoring should trigger alerts if encryption is disabled or if keys are about to expire. Periodic vulnerability scans and penetration tests will uncover misconfigured encryption settings. Our managed service integrates these tasks and provides dashboards so that security leaders and auditors can see evidence in real time.

Access Controls and Privacy Compliance

Encryption works in tandem with authentication and access controls. HIPAA requires unique user identification, emergency access procedures, automatic logoff, and person or entity authentication. Without proper access controls, an attacker could bypass encryption by authenticating as a legitimate user. Employ role‑based access to restrict who can read decrypted ePHI. Multi‑factor authentication and password policies strengthen user verification.

Integrating privacy compliance means ensuring that encryption does not interfere with individuals’ rights under other regulations such as the HIPAA Privacy Rule or GDPR. Encryption should support data minimisation and deletion requests. When data is encrypted at rest, key destruction can effectively render it unreadable without physically wiping the storage.

Templates for Implementation

Documenting your encryption strategy makes it easier to manage and to demonstrate compliance. Below are four template outlines we use when building programmes for clients. They are starting points; modify them based on your organisation’s size and risk profile.

Risk Assessment Template – Encryption Focus

1. Inventory: List all systems storing or transmitting ePHI. Include servers, workstations, mobile devices, cloud services, databases, and backups.
   
   
2. Data sensitivity: Classify data based on sensitivity, regulatory requirements, and business impact.
   
   
3. Threat identification: Identify threats such as theft, ransomware, insider abuse, and network interception.
   
   
4. Vulnerabilities: Document technical and procedural weaknesses.
   
   
5. Likelihood and impact scoring: Use a standard scoring system (for example, CVSS or FAIR) to evaluate each threat/vulnerability pair.
   
   
6. Control recommendations: Determine where encryption is needed. The HIPAA guidance instructs organisations to decide whether and how to use encryption.
   
   
7. Documentation: Record reasons for control decisions, including any compensating controls.

Encryption Policy Template

• Purpose and scope: State that the policy applies to all systems containing ePHI.
  
  
• Roles and responsibilities: Define the roles of system owners, key custodians, security officers, and end users.
  
  
• Encryption requirements: Specify that all ePHI at rest must be encrypted using AES‑256 and that all data in transit must use TLS 1.2 or higher, per NIST guidance.
  
  
• Exceptions: Describe the limited exceptions where encryption is not technically feasible, along with compensating controls.
  
  
• Compliance and enforcement: Outline consequences for non‑compliance and mechanisms for policy enforcement.
  
  
• Review cycle: Set an annual review to align with HIPAA’s proposed 12‑month review period.

Secret Management Policy Template

• Secret hierarchy: Describe master keys, data encryption keys, and session keys.
  
  
• Generation: Keys must be generated using FIPS‑validated modules.
  
  
• Storage: Keys are stored in HSMs or cloud KMS; backups are encrypted.
  
  
• Rotation: Define rotation intervals (e.g., annually for data encryption keys, quarterly for session keys).
  
  
• Destruction: Describe secure deletion procedures.
  
  
• Access control: Only designated key custodians may manage keys; all actions are logged.
  
  
• Monitoring: Regularly review key usage logs for anomalies.

Audit and Reporting Template

• Log content: Document what events are logged (e.g., encryption status changes, key rotations, decryption attempts).
  
  
• Frequency: Define how often logs are reviewed (weekly, monthly).
  
  
• Metrics: Track compliance metrics like encryption coverage and time to remediate encryption alerts.
  
  
• Incident response: Link encryption controls to incident response plans. For example, if keys are compromised, rotate them immediately and assess whether data was exposed.
  
  
• Evidence retention: Maintain audit logs for at least six years, consistent with HIPAA requirements.

Compliance Checkpoints

To demonstrate compliance, organisations need evidence that encryption is implemented and monitored. Auditors will ask for:

• Policies and procedures: Written encryption and key management policies.
  
  
• Risk analysis documentation: Records showing why encryption was applied or compensating controls were used.
  
  
• System configurations: Proof that servers and databases have encryption enabled.
  
  
• Validation records: FIPS validation certificates for encryption modules.
  
  
• Monitoring logs: Evidence of continuous monitoring, including alerts and their resolution.
  
  
• Training records: Proof that staff are trained on handling encrypted data.

During audits, we guide clients through control mapping across frameworks. For instance, the SOC 2 Trust Services Criteria for confidentiality and privacy require encryption at rest and in transit, as do ISO 27001 controls under Annex A. By aligning controls, we reduce duplicate effort and allow one set of evidence to satisfy multiple frameworks. Our managed service tracks each control’s status and prepares audit packages. This approach has cut audit preparation time by up to 75 percent for some clients, who now spend around 75 hours per year on compliance tasks instead of 550–600 hours when self‑managed.

Case Examples

A Small Clinic

A small clinic with 15 employees uses a cloud‑based electronic health record (EHR) system. During risk analysis, the clinic identified unencrypted laptops used by physicians for offline access. The clinic implemented full‑disk encryption and required pre‑boot authentication; it also enabled encryption in the EHR vendor’s platform and configured TLS 1.3 for all web sessions. Management of encryption secrets was outsourced to a cloud KMS. The clinic documented these controls and saved configuration screens as evidence. As a result, when a laptop was stolen from a car, the clinic avoided a reportable breach because the data was encrypted. The time to implement these controls was about six weeks; the clinic reported minimal performance impact and regained trust from its patients and partners.

A Hospital Network

A regional hospital network with multiple sites processes millions of records per year. Its risk assessment uncovered several legacy applications using outdated TLS 1.0 and storing ePHI in plain text in development databases. The hospital engaged a managed service to modernise encryption. Over four months, the team migrated applications to TLS 1.3, deployed database encryption using AES‑256, and implemented a central HSM for key management. They also enforced role‑based access and logging. The hospital had 170 systems to bring into scope; the project involved 20 internal stakeholders. During the next audit, there were no encryption findings, and the hospital closed a major partnership after providing evidence that all data transfers were encrypted.

Common Pitfalls

• Lack of key rotation: Some organisations implement encryption but never rotate keys, exposing them to prolonged risk if a key is compromised.
  
  
• Weak protocols: Using outdated protocols like SSL 3.0 or TLS 1.0 fails to meet current standards.
  
  
• Inconsistent implementation: Encrypting databases but leaving logs or exports unencrypted creates gaps.
  
  
• Poor documentation: Auditors see many encryption controls that are working technically but not documented. Without written policies, evidence may not satisfy auditors.
  
  
• Human factors: Employees sometimes copy data into spreadsheets or send ePHI via unencrypted email. Regular training and monitoring are essential.

Recognising these pitfalls early allows organisations to allocate resources efficiently. At Konfirmity, we combine technical implementation with process design to prevent such gaps.

Conclusion

Encryption is not just a regulatory requirement; it is a core defence for safeguarding patient trust. The HIPAA Security Rule has long treated encryption as an addressable implementation specification, but the proposed amendments will make it mandatory for all ePHI at rest and in transit. Modern encryption standards like AES‑256 and protocols like TLS 1.3 provide strong protection, but they must be implemented with care. Effective key management, risk assessment, continuous monitoring, and integration with access controls are all essential.

As practitioners who have built and operated programmes for hundreds of healthcare organisations, we emphasise that “starting with security and arriving at compliance” is the most sustainable path. Encryption controls should live inside your stack, not in checklists. With a human‑led managed service, you can design and operate these controls day‑to‑day, freeing your team from the heavy lifting and letting them focus on patient care. Meeting HIPAA Encryption Requirements means integrating encryption naturally into operations so that security evidence is always available.

Frequently Asked Questions

1) What are the encryption requirements for HIPAA 2025?

The 2024 NPRM proposes to require encryption of all ePHI at rest and in transit, removing the “addressable” classification and making encryption mandatory. Until final rules are issued, organisations must implement encryption when appropriate after risk analysis. Using AES‑256 for stored data and TLS 1.2 or 1.3 for transmitted data aligns with NIST guidance.

2) Is AES‑256 encryption HIPAA compliant?

Yes. AES is a FIPS‑approved algorithm capable of using 128‑, 192‑, and 256‑bit keys. When implemented correctly with FIPS‑validated modules, AES‑256 meets HIPAA’s requirements and is widely used in government and industry.

3) Is TLS encryption sufficient for HIPAA?

TLS is essential for protecting data in transit. NIST requires support for TLS 1.2 with FIPS‑approved cipher suites and mandates support for TLS 1.3. However, HIPAA compliance also includes access controls, audit logging, authentication, and risk management. TLS alone does not satisfy these additional requirements.

4) What provision about encryption does the HIPAA Security Rule contain?

Under 45 C.F.R. § 164.312, regulated entities must implement mechanisms to encrypt and decrypt ePHI as part of access control and to encrypt ePHI in transmission when appropriate. These were historically addressable but are moving toward mandatory enforcement.

5) How can smaller practices meet HIPAA Encryption Requirements? 

Small practices can start by conducting a focused risk assessment, identifying where ePHI resides, and implementing full‑disk encryption on laptops and mobile devices. They should ensure that their EHR systems use AES‑256 encryption at rest and TLS 1.2 or 1.3 in transit. Managed services can help by providing expertise in selecting FIPS‑validated solutions and maintaining encryption controls over time.

6) What is the role of managing encryption secrets in HIPAA compliance? 

Managing encryption secrets is central to encryption. FIPS 140‑2 emphasises secure key generation, storage, rotation, and destruction. Without proper secret management, encrypted data may be vulnerable. A secret management policy should define roles, rotation schedules, access controls, and monitoring. Using HSMs or cloud secret management services helps maintain security and produce evidence for audits.

7) Do I need to encrypt backups and archives? 

Yes. Backup media often contain complete copies of databases and are attractive targets for attackers. HIPAA Encryption Requirements (fourth mention) apply to all ePHI, including backups stored offsite or in the cloud. Encrypting backups ensures that lost tapes or compromised cloud storage will not lead to reportable breaches.

8) How often do encryption controls need to be reviewed?

The proposed HIPAA amendments would require regulated entities to review certain security measures annually. In practice, review encryption status more often—monthly for secret management metrics and at least quarterly for configuration checks. Continuous monitoring tools can provide real‑time visibility.

9) Can encryption replace other safeguards? 

No. Encryption is a vital safeguard but must operate alongside administrative and physical controls. Risk assessment, user authentication, logging, incident response, and training are all required under the HIPAA Security Rule. Neglecting other controls can leave encrypted systems exposed through compromised accounts or misconfigured permissions.

10) How does Konfirmity support encryption and compliance? 

Konfirmity offers a human‑led, managed security and compliance service. We build controls inside your systems, including implementing AES‑256 at rest, TLS 1.3 in transit, and FIPS‑validated key management. Our team performs risk assessments, manages encryption keys, monitors compliance, and prepares evidence for audits. Typical SOC 2 readiness with Konfirmity takes 4–5 months compared to 9–12 months for self‑managed efforts. Clients spend about 75 hours per year on compliance tasks, down from 550–600 hours. We provide dedicated experts who execute security operations year‑round, ensuring that security is embedded and that HIPAA encryption requirements (fifth mention) are met by default.