HIPAA encryption requirements are rarely a clean list at the implementation level. The Security Rule is technology-neutral: it sets objectives without specifying how to reach them. The practical translation for a PACS admin or security engineer is TLS 1.2 or 1.3 for everything in transit, AES-256 for everything at rest, and a documented key management lifecycle covering generation, rotation, escrow, and destruction. This guide walks through each layer in order.
Why HIPAA Encryption Requirements Are Not Prescriptive
Under 45 CFR 164.312(e), HIPAA requires covered entities to implement “technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic network.” Encryption of ePHI at rest is addressed under 45 CFR 164.312(a)(2)(iv) as an “addressable” implementation specification, which does not mean optional: it means you must either implement it or document why a reasonable alternative achieves the same protection. For imaging data, there is no credible alternative. DICOM files containing patient identifiers and pixel data must be encrypted.
HIPAA does not mandate a specific cipher or key length. That gap is filled by NIST guidance. SP 800-111, the NIST guide to storage encryption, and SP 800-52 Rev. 2, which covers TLS, together define what “reasonable and appropriate” means for federal contexts and set the bar that healthcare security auditors measure against. Aligning your PACS to those standards is both the right technical choice and the strongest documentation position in the event of an OCR audit. The HIPAA Security Rule Technical Safeguards guidance from HHS directly references both publications as implementation resources.
TLS 1.2 and 1.3 for DICOM in Transit
The DICOM TLS Transport Profiles
DICOM defines its secure transport mechanisms in Part 15 (Security and System Management Profiles). The profiles you need for a compliant production environment are the BCP 195 family, specifically:
- Profile B.9 (BCP 195 TLS): Requires TLS 1.2 with a FIPS-approved cipher suite. Acceptable suites include
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256andTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. These use ephemeral ECDHE key exchange, which provides forward secrecy. - Profile B.12 (BCP 195 RFC 8996/9325 TLS): The 2024-updated profile that adds TLS 1.3 support and explicitly deprecates TLS 1.0 and 1.1. This is where new deployments should land.
RFC 8996 formally deprecated TLS 1.0 and 1.1 in 2021. If your PACS or DICOM modalities still negotiate those versions, that is an active finding in any modern security audit. The DICOM PS3.15 2026b Security and System Management Profiles standard lists all current transport profiles and cipher suite requirements in Section B.
TLS 1.3 Specifics for DICOM
TLS 1.3 changes the handshake in ways that matter for PACS deployments. The protocol eliminates static RSA key exchange entirely, meaning all connections use ephemeral key agreement. It also reduces the handshake to one round-trip, which helps reduce latency on high-volume DICOM associations. The mandatory cipher suites are:
TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256
For healthcare environments prioritizing FIPS alignment, TLS_AES_256_GCM_SHA384 is the preferred choice. CHACHA20-POLY1305, while strong, is not FIPS-approved.
Certificate Management for DICOM TLS
DICOM TLS requires X.509 certificates on both the SCU (Service Class User, typically the modality or viewer) and the SCP (Service Class Provider, typically the PACS server). Key configuration decisions:
- Certificate Authority: Use an internal CA for DICOM peer authentication. Browser-trusted public CAs are not appropriate for DICOM-to-DICOM machine authentication.
- Certificate lifetime: Limited to 365 days or less. Longer lifetimes are a liability if private key material is compromised.
- Revocation: Configure CRL Distribution Points or OCSP stapling. Unrevocable certificates are a significant risk in environments with high modality turnover.
- Key type: RSA 2048-bit is the minimum; RSA 4096 or ECDSA P-384 are preferred for new certificates. ECDSA P-384 offers security equivalent to RSA 7680 with a fraction of the key size, reducing TLS handshake overhead.
One practical note: many legacy DICOM modalities have limited TLS 1.3 support. Before enforcing TLS 1.3 across a network, audit modality firmware versions and negotiate vendor upgrade timelines. A PACS that drops TLS 1.1 for viewer connections but leaves modality-to-PACS associations on 1.1 has a significant gap.
OmniPACS handles certificate lifecycle management within its platform, including automated renewal and configurable cipher policy, so that PACS admins do not have to manage certificate rotation manually across dozens of endpoints.
AES-256 for DICOM at Rest
Why AES-256 and Not AES-128
AES-128 is computationally secure by current standards. The choice of AES-256 for healthcare is not primarily about current attack surfaces: it is about margin against future cryptanalytic advances and alignment with NIST SP 800-111 recommendations for long-lived sensitive data. DICOM files may remain in storage for five to ten years or longer under retention requirements. Data encrypted today with AES-128 needs to remain protected against attacks in 2030 and beyond. AES-256 provides the headroom.
For PACS implementations, AES-256 in GCM (Galois/Counter Mode) is the right choice. GCM provides authenticated encryption: the ciphertext includes a tag that detects unauthorized modification, satisfying both confidentiality and integrity requirements under HIPAA’s Technical Safeguards simultaneously.
Envelope Encryption for PACS Storage
Encrypting each DICOM object individually with a long-lived key creates a management problem: if the key is ever compromised, the entire archive is exposed. Envelope encryption solves this by using a two-tier key hierarchy:
- Data Encryption Key (DEK): A unique AES-256 key generated per object or per study. This key encrypts the DICOM file itself.
- Key Encryption Key (KEK): A master key held in a KMS or HSM. The DEK is encrypted by the KEK and stored alongside the ciphertext.
To decrypt a DICOM file, the application requests the KEK from the KMS, decrypts the DEK, and uses the DEK to decrypt the file. Rotating the master key requires re-encrypting only the stored DEKs, not re-encrypting the entire archive. This is computationally tractable even for archives with millions of studies.
Cloud-based PACS deployments on AWS, Azure, or GCP can use their native KMS services (AWS KMS, Azure Key Vault, GCP Cloud KMS) to implement this pattern natively. Each service supports AES-256 KEKs with hardware-backed protection and audit logs of every key usage. For on-premises deployments, a purpose-built HSM or a FIPS 140-3-validated software KMS serves the same role.
OmniPACS uses envelope encryption by default, with per-study DEKs managed through a FIPS-validated key management layer. This means archived studies are cryptographically isolated from each other, even within the same storage backend.
Key Management Lifecycle
NIST SP 800-57 Part 1 Rev. 5 defines key management through four operational phases: Generate, Distribute, Rotate, and Destroy. For a PACS environment, here is what each phase requires in practice.
Generation
Keys should be generated using a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) within a FIPS 140-3 validated module. Never generate encryption keys in application code using language-level random functions. AES-256 DEKs need 256 bits of true entropy. The KMS or HSM handles this; document your generation mechanism for audit purposes.
Distribution
DEKs should never travel in plaintext. The envelope model described above handles this: the DEK is encrypted by the KEK before storage. For TLS certificates, private keys should be generated on the target system (not generated elsewhere and then transferred). If transfer is unavoidable, use encrypted transport with a separate key.
Rotation
NIST SP 800-57 does not prescribe a universal rotation interval; it prescribes rotation based on cryptoperiod, which is a function of usage volume and sensitivity. For healthcare environments:
- TLS private keys: rotate annually, aligned with certificate renewal
- KMS master keys: rotate annually or on any indication of compromise
- DEKs: a new DEK per study provides continuous rotation at the data level without a scheduled process
Destruction
When a key is retired, it must be destroyed in a way that makes reconstruction infeasible. For HSM-held keys, the HSM’s zeroization function meets this requirement. For software KMS keys, overwrite with random data multiple times. For cloud KMS, the provider handles secure deletion, but you should verify that it is covered by your BAA.
KMS vs. HSM: When Each Is Appropriate
The distinction matters for HIPAA and FIPS compliance discussions:
| Factor | Software KMS | Hardware HSM |
|---|---|---|
| FIPS 140-3 validation | Level 1 (some products) | Level 3 or Level 4 |
| Cost | Low to moderate | High |
| Tamper resistance | None | Physical tamper evidence |
| Key extraction prevention | Depends on implementation | Hardware-enforced |
| Cloud-native integration | Native (AWS KMS, Azure Key Vault) | Requires CloudHSM or on-prem |
For most cloud-based PACS deployments, a FIPS 140-3 Level 1 software KMS is sufficient for HIPAA compliance purposes. The HIPAA Security Rule does not mandate HSMs. HSMs become necessary when FIPS 140-3 Level 3 is contractually required (typically by federal health programs or defense-adjacent healthcare work) or when an organization’s risk posture demands hardware-enforced prevention of key extraction.
Key Escrow and Recovery
Encrypted data is permanently inaccessible if the KEK is lost. Key escrow solves this, but introduces its own risks: the escrow copy is a high-value target. A practical escrow architecture for PACS:
- Store a copy of the KEK in an offline HSM held by a designated key custodian
- Require dual-person authorization (split knowledge) to access the escrow copy
- Test key recovery annually, documented in your security management process
- Store escrow copies in a geographically separate location from the primary KMS
Split knowledge means no single person can reconstruct the key from their fragment alone, satisfying NIST SP 800-57 guidance on protecting critical keys.
FIPS 140-3 Considerations
FIPS 140-3, published by NIST in March 2019, superseded FIPS 140-2 and defines four security levels for cryptographic modules, from Level 1 (basic software security) to Level 4 (tamper-active physical protection).
For PACS environments, the relevant question is often not “which level do we need” but “are our cryptographic modules validated at all?” HIPAA does not mandate FIPS 140-3 validation, but three scenarios change that:
- Organizations pursuing federal contracts or CMS program participation must meet FISMA requirements, which mandate FIPS-validated modules
- State health agencies often inherit federal requirements through grant conditions
- Using FIPS-validated modules is the most defensible position in an OCR audit
Verify FIPS 140-3 validation status of any specific module through NIST’s Cryptographic Module Validation Program (CMVP) database. When evaluating a PACS vendor, ask for the CMVP certificate number, not just whether they “use AES-256.” AES-256 in an unvalidated module has no independent assurance of correctness.
OmniPACS operates on AWS infrastructure, using FIPS 140-3-validated cryptographic modules across storage and key management, providing a defensible foundation for FISMA-adjacent healthcare deployments.
Post-Quantum Readiness
NIST finalized its first post-quantum cryptographic standards in 2024 (FIPS 203, 204, and 205). For current PACS deployments, post-quantum migration is not yet urgent for data at rest: AES-256 is resistant to known quantum attacks because quantum speedup applies only to brute-force search, not to the AES algorithm itself.
The more pressing concern is the use of asymmetric cryptography in TLS. RSA and ECDSA key exchange are vulnerable to Shor’s algorithm on a future quantum computer. Future revisions to DICOM Part 15 TLS profiles are expected to add post-quantum key agreement options as NIST’s new standards mature.
For now, PACS admins should ensure cryptographic agility: systems should be configurable to swap cipher suites without architectural changes. A PACS that hard-codes RSA-2048 will require a major update when post-quantum migration becomes mandatory, while a system with a configurable cipher policy needs only a configuration change.
OmniPACS maintains crypto-agility as a design principle, meaning cipher suite policy can be updated without application redeployment as standards evolve.
What This Means for PACS Admins and Security Engineers
Encryption is necessary but not sufficient for HIPAA compliance. It must be accompanied by documented risk analysis, auditable key management procedures, and access controls. If you cannot answer “who has access to the KEKs, and what happens when that person leaves,” you have an undocumented key management process, regardless of the algorithm’s strength.
Start with a gap analysis across four areas: TLS version and cipher suite for all DICOM connections (modality-to-PACS, PACS-to-viewer, teleradiology links); encryption algorithm and mode for the storage backend; key management documentation covering rotation intervals and escrow; and FIPS module validation status for your KMS or HSM. The broader picture of HIPAA-compliant medical imaging storage is a useful context before the cryptographic layer. If you are assessing baseline compliance, Whether your PACS system is HIPAA compliant blog covers the broader controls that wrap around encryption.
Encryption is the hardest control to bypass when implemented correctly. That is why the implementation details matter.
Frequently Asked Questions
Does HIPAA require AES-256 specifically?
No. HIPAA is technology-neutral and does not mandate a specific cipher. AES-256 is the industry alignment point because NIST SP 800-111 recommends it for long-lived sensitive data and because it provides a post-quantum resilience margin that AES-128 does not. AES-256 in GCM mode meets the “reasonable and appropriate” standard for any OCR auditor.
Is TLS 1.2 still acceptable for DICOM connections?
Yes, TLS 1.2 with FIPS-based cipher suites remains compliant under current NIST and DICOM standards. TLS 1.3 is preferred for new deployments because it eliminates non-forward-secret cipher suites and reduces handshake complexity. The practical constraint is legacy modality support: many installed DICOM devices cannot upgrade to TLS 1.3 without firmware updates.
What is the difference between a KMS and an HSM for key management?
A KMS is a software service managing key lifecycle operations: generation, storage, rotation, and destruction. An HSM is a tamper-resistant physical device that performs those operations in hardware. HSMs can back a KMS. For most cloud-based PACS deployments, a FIPS 140-3 Level 1 software KMS is sufficient. HSMs at Level 3 or Level 4 are required when hardware-enforced key-extraction prevention is contractually or regulatory-required.
How often should PACS encryption keys be rotated?
TLS private keys: annually, aligned with certificate expiration. KMS master keys (KEKs): annually, or immediately on any indication of compromise. Data encryption keys (DEKs) in an envelope architecture: a new DEK per study provides continuous rotation without a scheduled process. Document all rotation activities as part of your HIPAA security management process.
What should we ask a PACS vendor about encryption?
Ask for: (1) which FIPS 140-3 validated module they use and its CMVP certificate number; (2) which DICOM TLS transport profile they support and whether TLS 1.3 is available; (3) how DEKs are managed and whether envelope encryption is in use; (4) their key rotation and escrow procedures; and (5) whether their BAA covers key management infrastructure. Vendors who cannot answer these questions specifically lack the implementation depth needed for a defensible HIPAA posture.
Facilities moving to a PACS built for compliant cloud operations can explore OmniPACS services directly. OmniPACS Delivers Scalable Monthly Plans designed around these security controls, so cryptographic compliance is a built-in baseline rather than a retrofit.