ePHI Encryption for AI Systems: AES-256, TLS 1.3, Key Management, and the Data-at-Rest vs. In-Transit Divide

In April 2016, Catholic Health Care Services of the Archdiocese of Philadelphia paid $650,000 to OCR after an unencrypted iPhone containing the ePHI of 412 individuals — including Social Security numbers, financial information, and medical diagnoses from its foster care and group home programs — was stolen. The organization was responsible for the ePHI of some of society's most vulnerable individuals, and unencrypted mobile devices created the exposure that triggered enforcement. AI healthcare systems in 2026 create analogous encryption gaps — but at far greater scale and across many more data pathways.

️ HHS OCR Resolution Agreement — Catholic Health Care Services of the Archdiocese of Philadelphia

Announced:	April 18, 2016
Settlement:	$650,000 plus corrective action plan
Covered Entity:	Catholic Health Care Services, Archdiocese of Philadelphia
Incident:	Unencrypted iPhone with ePHI stolen from employee
Individuals Affected:	412 (group home and foster care clients)
ePHI Type:	SSNs, financial data, medical diagnoses, medications, living arrangements
Violations:	45 CFR §164.312(a)(2)(iv) (encryption/decryption), §164.312(e)(2)(ii) (encryption in transit)

View HHS OCR Resolution Agreement →

The Catholic Health Care Services case is one of many OCR enforcement actions triggered by unencrypted mobile devices — a pattern OCR has enforced consistently since 2012. But for AI healthcare deployments, the encryption challenge is far more complex than device-level full-disk encryption. AI systems create multiple ePHI encryption requirements simultaneously: data at rest in databases and log files, data in transit between system components, data in memory during processing, and cryptographic key management that determines whether encryption is effective or merely performative.

The HIPAA Encryption Framework: Addressable vs. Required

45 CFR §164.312(a)(2)(iv)

Encryption and Decryption — Addressable

Implement a mechanism to encrypt and decrypt ePHI. "Addressable" means organizations must implement if reasonable and appropriate, or document why it's not. In practice, OCR treats encryption as required for portable devices and cloud-transmitted data — no enforcement action has accepted an "encryption not appropriate" justification for these contexts.

45 CFR §164.312(e)(2)(ii)

Encryption in Transit — Addressable

Implement a mechanism to encrypt ePHI in transit when deemed appropriate. For internet-transmitted ePHI (API calls, cloud services, AI inference endpoints), OCR's guidance and enforcement record makes TLS the de facto required standard. Unencrypted ePHI transmission over any network is indefensible.

NIST SP 800-111 / FIPS 140-2

NIST Encryption Standards

HHS guidance directs covered entities to NIST Special Publication 800-111 for storage encryption and NIST SP 800-52 for transit encryption. FIPS 140-2 validated cryptographic modules provide the strongest compliance foundation. AES-256 satisfies storage requirements; TLS 1.3 satisfies transit requirements.

The "addressable" designation for HIPAA encryption creates a widely misunderstood flexibility. The Security Rule's addressable implementation specifications require organizations to either implement the specification, implement an alternative that achieves the same purpose, or document why neither is reasonable and appropriate given the organization's environment. For cloud-transmitted ePHI and portable devices, OCR's enforcement record makes clear that "not appropriate" is not an acceptable finding — the documentation requirement exists for edge cases in isolated legacy environments, not as a general encryption opt-out.

Data at Rest: AES-256 and Key Management

AES-256 (Advanced Encryption Standard with 256-bit keys) is the current NIST-recommended symmetric encryption algorithm for data at rest. NIST SP 800-111 Section 4.1 specifies AES as the recommended algorithm for protecting stored data, with 256-bit keys providing security well beyond current and projected computational capabilities. For HIPAA purposes, AES-256 in CBC or GCM mode with properly managed keys satisfies the §164.312(a)(2)(iv) encryption requirement.

AI systems create several categories of ePHI data-at-rest that each require AES-256 encryption:

Category 1: Database-Stored Patient Records

This is the most commonly addressed encryption requirement. EHR databases, patient demographic records, clinical notes, and appointment history should use transparent data encryption (TDE) at the database engine level — not just filesystem encryption. TDE encrypts data files as written to storage and decrypts on read, providing protection against stolen storage media without application changes. PostgreSQL (pgcrypto), MySQL (InnoDB TDE), and SQL Server (Transparent Data Encryption) all support this natively.

Category 2: AI System Logs

As established in the PHI in AI Systems article, application logs from AI healthcare systems can contain PHI — conversation transcripts, EHR query parameters, patient identifiers used in session management. These logs must be encrypted at rest with the same AES-256 standard as primary databases. Log files written to plaintext on local filesystems and then forwarded to a SIEM create an unencrypted intermediate copy that violates the encryption requirement.

Category 3: Backup and Archive Storage

Backup files are the most commonly overlooked encryption gap. Organizations that encrypt production databases often back up data in plaintext compressed archives that are stored in unencrypted S3 buckets or tape libraries. The Catholic Health Care Services violation — unencrypted device containing ePHI — maps directly to unencrypted backup media: both are ePHI in a form that can be physically removed from the organization's control without cryptographic protection.

Category 4: Vector Embedding Stores

As discussed in our PHI AI risks analysis, vector databases containing patient-derived embeddings are ePHI systems requiring encryption. Pinecone, Weaviate, and pgvector deployments storing healthcare embeddings must have encryption at rest configured explicitly — managed service defaults vary and should be verified against the vendor's encryption documentation.

The key management gap that makes encryption worthless: AES-256 encryption is only as strong as the security of the encryption keys. The most common implementation failure in healthcare AI is encrypting ePHI with keys stored in the same environment as the encrypted data — often in environment variables on the same server, or in plaintext configuration files accessible to any process that can read the filesystem. An attacker who compromises the application server gets both the encrypted data and the keys. This is encryption theater, not encryption security.

Encryption Key Management for Healthcare AI

Effective key management requires separating key custody from data storage. An attacker who compromises the system storing encrypted ePHI must not also be able to obtain the encryption keys from the same compromise. Industry-standard approaches include:

Hardware Security Modules (HSMs)

HSMs are dedicated hardware devices that store and manage cryptographic keys in tamper-resistant hardware. FIPS 140-2 Level 3 validated HSMs are the gold standard for healthcare key management. AWS CloudHSM, Azure Dedicated HSM, and Google Cloud HSM all provide FIPS 140-2 Level 3 validated hardware as managed services. Keys stored in HSMs cannot be exported in plaintext — all cryptographic operations occur within the HSM hardware boundary.

Cloud Key Management Services (KMS)

Cloud KMS services (AWS KMS, Azure Key Vault, Google Cloud KMS) provide FIPS 140-2 validated key storage without dedicated hardware cost. The critical requirement for healthcare use: Customer-Managed Keys (CMK), not Provider-Managed Keys. With CMK, the covered entity controls the encryption key — including the ability to revoke access by deleting the key, which renders encrypted data unreadable. Provider-managed keys mean the cloud provider controls key access, which has implications for law enforcement access and vendor relationship continuity.

Key Rotation Requirements

NIST SP 800-57 (Recommendation for Key Management) specifies cryptoperiods — the time period during which a key is authorized for use. For AES-256 data encryption keys (DEKs), NIST recommends a maximum cryptoperiod of two years for originator-usage periods. Healthcare organizations should configure annual automatic key rotation for ePHI encryption keys. In a Key Encryption Key (KEK) architecture, rotating the KEK re-encrypts all DEKs without requiring re-encryption of data — enabling frequent rotation without performance impact.

# ePHI Encryption Architecture — Bad vs. Compliant

# DANGEROUS: Encryption key stored in environment variable on same server
import os
from cryptography.fernet import Fernet

# Key stored in .env file on the application server — same system as data!
ENCRYPTION_KEY = os.environ['EPHI_ENCRYPTION_KEY']
cipher = Fernet(ENCRYPTION_KEY)

def store_patient_data(patient_id: str, phi_data: dict):
    encrypted = cipher.encrypt(str(phi_data).encode())
    db.execute("INSERT INTO patients VALUES (?, ?)", [patient_id, encrypted])
    # If server is compromised: attacker gets both encrypted data AND key
    # Backup of .env file = backup of key = encrypted data is accessible

# COMPLIANT: AWS KMS with Customer-Managed Key
import boto3
import json

kms_client = boto3.client('kms', region_name='us-east-1')
CMK_ARN = os.environ['KMS_CMK_ARN']  # ARN only — key material never in app server

def store_patient_data(patient_id: str, phi_data: dict):
    # Step 1: Request data key from KMS (key material generated in KMS HSM)
    response = kms_client.generate_data_key(
        KeyId=CMK_ARN,
        KeySpec='AES_256',
        EncryptionContext={'patient_id_hash': hash_patient_id(patient_id)}
        # EncryptionContext cryptographically binds key to patient — prevents
        # using one patient's key to decrypt another patient's data
    )
    plaintext_key = response['Plaintext']     # Used for encryption, then DELETED
    encrypted_key = response['CiphertextBlob'] # Stored with the encrypted data
    
    # Step 2: Encrypt data with plaintext key in memory
    cipher = AES256GCM(plaintext_key)
    encrypted_data = cipher.encrypt(json.dumps(phi_data).encode())
    
    # Step 3: Store encrypted data + encrypted key; DELETE plaintext key
    del plaintext_key  # Key material leaves memory immediately
    db.execute("INSERT INTO patients VALUES (?, ?, ?)",
               [patient_id, encrypted_data, encrypted_key])
    # Server compromise: attacker gets encrypted_data + encrypted_key
    # Decryption requires KMS access — key never existed in server storage

Data in Transit: TLS 1.3 Configuration for AI Systems

TLS 1.3, standardized in RFC 8446 (August 2018), is the current required standard for ePHI in transit. TLS 1.3 eliminates several vulnerabilities present in TLS 1.2: it removes RSA key exchange (replacing with ephemeral Diffie-Hellman providing forward secrecy), removes CBC cipher suites that were vulnerable to padding oracle attacks (POODLE, BEAST), and reduces the handshake from 2 round trips to 1, improving performance as well as security.

For AI healthcare systems, "in transit" covers multiple data pathways that each require TLS 1.3:

Client-to-AI system communication — Patient phone calls transcribed via VoIP (SRTP for voice, TLS for signaling), web interfaces, and mobile apps
AI system to EHR FHIR API calls — Every FHIR API call must use TLS 1.3 with certificate validation. Self-signed certificates on EHR endpoints must not be accepted by AI client code
AI system to LLM inference API — Calls to Azure OpenAI, AWS Bedrock, or similar endpoints transmit prompt content (potentially containing PHI) and must use TLS 1.3
Internal service-to-service communication — Microservice architectures connecting AI orchestration, EHR proxy, STT service, and logging layers must not transmit ePHI over unencrypted internal network paths
Database connections — Application-to-database connections must use TLS, not rely solely on network isolation. An attacker with network access between application and database servers can capture unencrypted ePHI queries without any database credentials

TLS 1.2 deprecation timeline: NIST SP 800-52 Rev 2 (2019) specifies TLS 1.3 as the recommended standard and identifies TLS 1.0 and 1.1 as deprecated. The PCI Security Standards Council required TLS 1.2 minimum by June 2018. For HIPAA, OCR has not published a specific TLS version requirement — but a risk analysis that accepts TLS 1.0 or 1.1 for ePHI in transit would be indefensible against NIST guidance. Configure TLS 1.3 with TLS 1.2 fallback only for legacy system compatibility; disable TLS 1.0 and 1.1 entirely.

# TLS Configuration for AI Healthcare System Components

# DANGEROUS: Default TLS configuration accepting old versions
import ssl
import urllib.request

# Default ssl context accepts TLS 1.0+ — allows deprecated versions
context = ssl.create_default_context()
# No certificate pinning — vulnerable to MITM with rogue CA
# TLS 1.0/1.1 still accepted by default in many Python versions

def call_ehr_fhir_api(endpoint: str, headers: dict):
    req = urllib.request.Request(endpoint, headers=headers)
    response = urllib.request.urlopen(req)  # Uses default (insecure) TLS context
    return response.read()

# COMPLIANT: Hardened TLS 1.3 configuration
import ssl
import httpx

def create_hipaa_tls_context():
    ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
    ctx.minimum_version = ssl.TLSVersion.TLSv1_3   # TLS 1.3 minimum
    ctx.maximum_version = ssl.TLSVersion.TLSv1_3   # TLS 1.3 only (disable 1.2 fallback)
    ctx.verify_mode = ssl.CERT_REQUIRED              # Certificate validation mandatory
    ctx.check_hostname = True                        # Hostname verification
    ctx.load_verify_locations('/etc/ssl/healthcare-ca-bundle.crt')  # Trusted CA bundle
    # Configure approved cipher suites (TLS 1.3 suites only):
    # TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256
    return ctx

async def call_ehr_fhir_api(patient_id: str, resource_type: str):
    async with httpx.AsyncClient(
        verify=create_hipaa_tls_context(),
        timeout=30.0
    ) as client:
        response = await client.get(
            f"{EHR_BASE_URL}/fhir/R4/{resource_type}/{patient_id}",
            headers={'Authorization': f'Bearer {get_session_token()}',
                     'Accept': 'application/fhir+json'}
        )
        response.raise_for_status()
        return response.json()

ePHI Encryption Technical Audit Checklist: 12 Controls

Verify database-level encryption at rest using AES-256 TDE for all ePHI-containing databases. Filesystem-level encryption (BitLocker, LUKS) does not protect against application-level access after the filesystem is mounted. TDE encrypts data files directly and provides protection at the storage layer independent of OS access.

Audit encryption key storage for separation from encrypted data. Keys must not be stored in environment variables, plaintext config files, or any location on the same server as encrypted ePHI. Use AWS KMS, Azure Key Vault, or equivalent HSM-backed key management with Customer-Managed Keys.

Verify TLS 1.3 is configured for all external ePHI transmissions. Test with: openssl s_client -connect your-ai-endpoint:443 -tls1_3 (should succeed) and openssl s_client -connect your-ai-endpoint:443 -tls1 (should fail with handshake error).

Audit internal service-to-service communications for TLS. Microservice architectures where AI components communicate over internal networks often omit TLS for performance. Internal network isolation is not a substitute for encryption — assume network-level access can be obtained by an attacker who has compromised any internal system.

Verify backup and archive files are encrypted before leaving production environment. S3 backup buckets must have server-side encryption with KMS (SSE-KMS) configured. Verify the bucket policy denies uploads without encryption: aws:SecureTransport and s3:x-amz-server-side-encryption conditions in bucket policy.

Implement annual encryption key rotation for all ePHI data encryption keys. Document the rotation schedule, the KEK/DEK architecture used, and the procedure for rotating keys without data re-encryption downtime. Test the rotation procedure before relying on it under compliance pressure.

Inventory all mobile devices and endpoint systems that access or store ePHI. Full-disk encryption (FileVault for macOS, BitLocker for Windows, LUKS for Linux) must be enabled on every endpoint. MDM enrollment required to enforce encryption policy and enable remote wipe on lost/stolen devices — directly addressing the Catholic Health Care Services vulnerability.

Verify AI system log files are encrypted at rest before archival. Production application logs containing patient context (even session-tokenized) should be encrypted before archival to long-term storage. CloudWatch Logs, ELK Stack, and Splunk all support encryption at rest — verify it is configured, not just available.

Test certificate validation in AI-to-EHR API calls. Client code that accepts self-signed certificates or ignores certificate validation errors creates a MITM attack surface. Verify that the AI system's FHIR client rejects connections with invalid or expired certificates — do not rely on the framework's default behavior without explicit testing.

Audit EncryptionContext use in KMS calls for patient-specific data. AWS KMS EncryptionContext cryptographically binds an encryption key to specific metadata (patient ID hash, session ID). This prevents an attacker from using one patient's encrypted key to decrypt another patient's data. Verify EncryptionContext is set for all patient-specific KMS operations.

Verify FIPS 140-2 validated cryptographic modules are used in AI system components. For maximum compliance posture, configure Python's ssl module with FIPS-compliant OpenSSL, or use AWS/Azure/GCP SDKs that are FIPS-validated by default in their GovCloud regions.

Document encryption decisions in the HIPAA risk analysis. For each implementation, document: the encryption algorithm and key length, the key management approach, the rationale for the chosen implementation, and the risk assessment if encryption is not implemented for a specific data pathway. The documentation creates the compliance record OCR expects to see during investigation.

How Claire Implements ePHI Encryption Architecture

1. Zero ePHI Stored at Rest in Claire's Infrastructure

Claire's architecture eliminates the data-at-rest encryption problem for ePHI by not storing patient PHI in Claire's infrastructure. Patient health data resides in your EHR and is accessed ephemerally via FHIR API during active sessions. There is no Claire-side patient database, no embedding store of patient health data, and no log archive containing patient PHI. The encryption requirement exists; Claire satisfies it by having no ePHI to encrypt at rest.

2. TLS 1.3 for All ePHI in Transit

All communications between Claire components and your EHR's FHIR API use TLS 1.3 with certificate validation and hostname verification. Claire's FHIR client rejects connections with invalid certificates and does not accept TLS 1.2 or lower for any connection path that transmits patient data. TLS version and cipher suite configuration is published in Claire's security documentation and verified annually by third-party penetration testing.

3. AWS KMS Customer-Managed Keys for Operational Data

Operational data that Claire does retain — session management tokens, configuration data, audit logs — is encrypted using AWS KMS with Customer-Managed Keys in your AWS account. You retain key ownership and can revoke Claire's access to encrypted operational data at any time by modifying the KMS key policy. This satisfies the separation-of-key-custody requirement and gives your organization control over the encryption lifecycle.

Encryption Is Not Optional for AI Healthcare Systems

The Catholic Health Care Services settlement — $650,000 for an unencrypted iPhone — established that OCR will enforce encryption requirements for small organizations serving vulnerable populations. For AI healthcare systems processing thousands of patient interactions daily, the scale of potential exposure from an encryption failure is orders of magnitude larger than a stolen mobile device. The technical controls in this checklist — AES-256 TDE, TLS 1.3 with certificate validation, HSM-backed key management, backup encryption — are the baseline that any AI vendor proposing to handle healthcare ePHI must be able to demonstrate, not merely certify.