Cryptography Requirements in PCI DSS and HIPAA

By Khimananda Oli | Last reviewed: August 2026

Implementing correct cryptography is the single most critical technical control for protecting sensitive data, yet misconfigurations remain a primary cause of compliance failures. Understanding the specific cryptography requirements in PCI DSS and HIPAA prevents costly audit findings and data breaches by ensuring you use only approved algorithms and secure key lifecycle management. This guide breaks down the exact standards, from FIPS validation to TLS configuration, that DevOps engineers must enforce in production environments today.

What are the mandatory cryptography requirements in PCI DSS and HIPAA?

Both frameworks converge on fundamental principles despite different regulatory origins. PCI DSS v4.0.1 explicitly requires strong cryptography for cardholder data (CHD) and sensitive authentication data (SAD), while HIPAA’s Security Rule treats encryption as an "addressable" specification that effectively becomes mandatory when risk analysis shows it is reasonable and appropriate—which, in 2026, it always does for electronic PHI (ePHI).

The non-negotiable baseline includes three pillars. First, you must use only publicly vetted, industry-standard cryptographic protocols; proprietary or custom algorithms are strictly prohibited. Second, encryption must cover both data at rest (stored CHD/ePHI) and data in transit (network transmissions). Third, cryptographic keys must be managed securely throughout their entire lifecycle, from generation to destruction, with strict access controls separating key custodians from system administrators.

A common mistake I see during audits is teams focusing solely on the encryption algorithm while neglecting the implementation context. Encrypting a database column with AES-256 satisfies the letter of the law, but if the application logs plaintext values or stores decryption keys in the same repository as the ciphertext, you have failed the spirit of the requirement. For practical secrets handling in containerized environments, refer to Kubernetes secrets management done right to avoid exposing keys in pod specs or environment variables.

Which encryption algorithms and protocols satisfy compliance standards?

Selecting approved algorithms is straightforward if you stick to current NIST and industry standards. Legacy protocols like SSLv3, TLS 1.0, TLS 1.1, DES, 3DES, MD5, and SHA-1 are universally deprecated and will trigger immediate findings in any PCI DSS or HIPAA assessment. Your infrastructure must enforce modern equivalents exclusively.

For FIPS 140-3 validation—a requirement for many government-adjacent HIPAA implementations and increasingly expected in PCI environments—you must use cryptographic modules that appear on the NIST CMVP validated list. This means your OpenSSL build, cloud KMS, or hardware security module (HSM) must carry a valid certificate. Simply claiming "we use AES" is insufficient; the specific library version and configuration must be validated.

Enforcing TLS Configuration

On Nginx or similar reverse proxies, restrict cipher suites explicitly. A compliant configuration block looks like this:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_stapling on;
ssl_stapling_verify on;

This configuration enforces forward secrecy via ECDHE, uses only GCM-mode ciphers, and disables server preference to allow clients to negotiate optimally within the safe set. Always test with tools like nmap --script ssl-enum-ciphers or Qualys SSL Labs before going live.

How do you implement secure key management for regulated workloads?

Key management separates compliant organizations from breached ones. Both PCI DSS Requirement 3.5 and HIPAA §164.312(a)(2)(iv) demand that cryptographic keys be protected against unauthorized access, modification, and disclosure. In practice, this means you never store keys in plaintext files, source code, configuration management databases, or alongside the encrypted data itself.

1. Centralize key storage. Use AWS KMS, Azure Key Vault, GCP Cloud KMS, or a dedicated HSM. Never generate or store master keys on application servers.
2. Enforce separation of duties. The team that manages encryption keys must differ from the team that accesses encrypted data. Implement RBAC policies that reflect this division.
3. Automate rotation. Define rotation schedules (typically annual for data encryption keys, more frequent for session keys) and automate re-encryption pipelines. Manual rotation fails under audit scrutiny because human error is inevitable.
4. Implement envelope encryption. Encrypt data with a unique Data Encryption Key (DEK), then encrypt the DEK with a Key Encryption Key (KEK) stored in your KMS/HSM. This limits blast radius if a DEK is compromised.
5. Log all key operations. Every key creation, usage, rotation, and deletion event must be logged immutably. Auditors will request these logs to verify no unauthorized access occurred.

For teams managing database credentials and connection strings alongside encryption keys, integrating with a proper secrets manager is essential. The patterns described in secrets management with HashiCorp Vault provide a vendor-neutral approach that satisfies dual-control requirements while remaining portable across cloud providers.

Practical Key Rotation Script Pattern

When automating rotation for PostgreSQL-backed applications, combine KMS API calls with application-level re-encryption:

#!/bin/bash
# Rotate DEK for patient records table
NEW_DEK_ARN=$(aws kms generate-data-key \
  --key-id alias/patient-records \
  --key-spec AES_256 \
  --query CiphertextBlob --output text)

# Store new encrypted DEK in metadata store
vault write secret/data/db/dek \
  ciphertext="$NEW_DEK_ARN" \
  rotated_at="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

# Trigger async re-encryption job
kubectl create job rotate-dek-$(date +%s) \
  --image=internal/reencryptor:v2.1 \
  --env="NEW_DEK_REF=vault:secret/data/db/dek"

This pattern ensures the plaintext DEK never touches disk or shell history, leverages Vault's transit engine for secure storage, and decouples rotation from application downtime through asynchronous batch processing.

What documentation and evidence do auditors require for cryptographic controls?

Technical implementation alone does not pass audits; documented policy and verifiable evidence do. Auditors assessing cryptography requirements in PCI DSS and HIPAA will request specific artifacts. Prepare these proactively rather than scrambling during fieldwork.

• Cryptographic Policy Document: Defines approved algorithms, minimum key lengths, acceptable vendors/modules, and roles/responsibilities. Must be reviewed annually and signed by leadership.
• Key Inventory: Complete register of all cryptographic keys including purpose, owner, creation date, rotation schedule, storage location, and associated data classification.
• FIPS Validation Certificates: Current CMVP certificates for every cryptographic module in use, including library versions and operating configurations.
• Key Lifecycle Procedures: Step-by-step runbooks for generation, distribution, storage, rotation, archival, and destruction—including verification steps after each action.
• Access Control Evidence: IAM policies, HSM quorum configurations, and access review records demonstrating least privilege and separation of duties.
• Monitoring and Alerting Config: Screenshots or exports showing alerts for anomalous key usage, expiration warnings, and failed access attempts.

A frequent gap is missing destruction verification. When decommissioning systems or rotating out old keys, you must prove the key material was cryptographically erased—not just deleted from a filesystem. KMS disable-and-delete workflows with confirmation logs satisfy this; manual file deletion does not.

How do you validate cryptographic controls in CI/CD pipelines?

Shift-left validation catches misconfigurations before they reach production. Integrate cryptographic compliance checks directly into your deployment pipeline rather than relying on periodic manual reviews. This aligns with the automation-first philosophy detailed in DevSecOps shift security left in CI/CD.

Start with static analysis of configuration files. Tools like checkov, tfsec, or kics can scan Terraform, Kubernetes manifests, and Dockerfiles for weak cipher suites, missing encryption flags, or hardcoded secrets. Add these as mandatory pipeline gates that block merges on failure.

Next, implement runtime validation. Deploy testssl.sh or sslyze against staging endpoints post-deployment to verify actual TLS negotiation matches declared configuration. Compare results against your approved cipher suite list; alert immediately on drift. For cloud-native workloads, query KMS audit logs via CloudWatch or Stackdriver to detect unauthorized key access patterns that indicate compromise or policy violation.

Finally, automate evidence collection. Configure your CI/CD system to archive compliance artifacts—scan reports, certificate validations, key rotation confirmations—to an immutable store after each successful deployment. This creates a continuous audit trail that dramatically reduces preparation time when assessors arrive. Remember: if it isn't automated and observable, it isn't production-ready.

Securing Sensitive Data Through Disciplined Cryptography

Meeting the cryptography requirements in PCI DSS and HIPAA demands more than checking boxes on a compliance worksheet. It requires disciplined engineering: approved algorithms enforced at the infrastructure level, key management treated as a first-class operational concern, and continuous validation embedded in your delivery pipeline. The frameworks converge on fundamentals even where terminology differs, so building to the stricter PCI standard typically satisfies HIPAA obligations while reducing maintenance overhead.

If your team needs help designing compliant cryptographic architectures, preparing for an upcoming assessment, or remediating findings from a failed audit, reach out to discuss your specific environment. Getting cryptography right protects your customers, your reputation, and your business continuity—make it a foundation, not an afterthought.