Cryptography Requirements in PCI DSS and HIPAA

By Kokil Thapa | Last reviewed: September 2026

Cryptography Requirements in PCI DSS and HIPAA are not abstract security theory. They are concrete rules that decide how you store card numbers, protect health records, and configure TLS on production servers. If your Laravel checkout, legal-tech portal, or clinic booking app touches payment data or electronic protected health information (ePHI), weak crypto is a compliance failure—not just a bug. This guide maps both frameworks to decisions you make in code, config, and deployment. Start with our PCI DSS essentials for developers if card data is new territory for your team.

What Are the Cryptography Requirements in PCI DSS and HIPAA?

Both frameworks require you to protect sensitive data with industry-standard algorithms and sound key handling. They differ in scope, terminology, and how prescriptive the rules read on paper.

PCI DSS applies when your environment stores, processes, or transmits Primary Account Numbers (PAN) and related cardholder data. The Payment Card Industry Security Standards Council publishes versioned requirements. As of 2026, most merchants still align with PCI DSS v4.0.x. Requirement 3 covers protection of stored account data. Requirement 4 covers protection during transmission over open, public networks.

HIPAA applies to covered entities and business associates handling ePHI under the U.S. Health Insurance Portability and Accountability Act. The Security Rule at 45 CFR §164.312 lists technical safeguards. Encryption and decryption are addressable implementation specifications—not literally the word "required" in the statute text. In practice, a documented risk analysis that skips encryption without a strong compensating control rarely survives an OCR audit.

On legal-tech portals and client portals I have built, the overlap appears often. A law firm intake form may collect health details for a disability claim. The same site may collect a retainer payment. One feature can trigger HIPAA-style ePHI handling. Another triggers PCI scope for card data. Treat them as separate compliance threads even when they share one codebase.

PCI DSS encryption at a glance

PCI DSS Requirement 3.5 requires documented cryptographic key management. Requirement 3.6 covers key generation, distribution, storage, and retirement. Requirement 3.7 restricts key access to the fewest custodians needed. Requirement 4.2 mandates strong cryptography and security protocols whenever cardholder data crosses public networks—including the internet and Wi‑Fi.

HIPAA encryption at a glance

§164.312(a)(2)(iv) covers encryption and decryption for ePHI. §164.312(e)(1) covers transmission security. §164.312(e)(2)(ii) covers encryption for ePHI sent over electronic communications. NIST Special Publication 800-111 remains a common reference for full-disk and file encryption guidance cited in HIPAA risk assessments.

How Does PCI DSS Define Encryption for Cardholder Data?

PCI DSS draws a hard line around PAN. If you store it, render it unreadable using one of several approved methods. Strong cryptography with associated key management is the path most application teams take.

Approved approaches include truncation, tokenization, hashing with salt, and one-way hashes of the full PAN. You cannot store sensitive authentication data after authorization—even encrypted. That category includes full magnetic-stripe data, CAV2/CVC2/CVV2/CID codes, and PIN blocks.

For encryption at rest, PCI DSS expects algorithms and key lengths aligned with industry standards. AES-256 in GCM or CBC with proper IV handling is typical for application-layer encryption. Full-database transparent encryption helps but does not replace application controls when PAN appears in logs, exports, or backup files.

For encryption in transit, TLS 1.2 is the practical floor. TLS 1.3 is preferred where client libraries support it. Self-signed certificates fail external-facing payment flows. Certificate expiry monitoring belongs in your support and maintenance checklist alongside application patches.

Practical PCI patterns for Laravel and PHP stacks

The lowest-scope pattern is hosted payment fields. Stripe Checkout, PayPal Smart Buttons, or a gateway iframe keeps raw PAN off your servers. Your app stores only a token and the last four digits. That design dramatically reduces PCI assessment surface.

If legacy code still stores encrypted PAN—a pattern I discourage—you must use vetted libraries. PHP's sodium_crypto_secretbox or Laravel's encrypt() helper wraps AES-256-CBC with HMAC. Never roll your own cipher modes.

# .env — separate DEK from application secret
PAN_ENCRYPTION_KEY=base64:...   # 32-byte key, stored in KMS or vault
APP_KEY=base64:...              # not reused for PAN

# config/services.php
'pan_cipher' => [
    'key' => env('PAN_ENCRYPTION_KEY'),
    'cipher' => 'AES-256-GCM',
],

# Migration — never store CVV
Schema::create('payment_methods', function (Blueprint $table) {
    $table->id();
    $table->foreignId('user_id')->constrained();
    $table->text('pan_ciphertext');      // encrypted or token reference
    $table->char('pan_last4', 4);
    $table->string('gateway_token')->nullable();
    $table->timestamps();
});

On eCommerce builds such as Quick And Easy Nepalese Grocery, gateway tokenization plus strict log redaction kept quarterly PCI self-assessment questionnaires manageable for a small team.

What Encryption Does HIPAA Require for ePHI?

HIPAA does not publish a single mandated cipher suite in the rule text. It requires reasonable and appropriate safeguards based on your risk analysis. Encryption is the default answer for ePHI on laptops, backup drives, and cloud object storage.

At rest, encrypt ePHI on servers, databases, and portable media. Full-disk encryption on staff laptops is baseline. Application-level field encryption helps when ePHI lives in multi-tenant tables or mixed-purpose databases.

In transit, use TLS for web portals, API calls, and email systems that carry ePHI. SFTP or SCP beats plain FTP for file transfers. Internal service-to-service traffic on a private VLAN still deserves TLS when ePHI crosses it.

Document your decisions. An addressable specification you decline to implement needs written rationale and compensating controls. "We skipped encryption because it was hard" fails audits. "We use a HSM-backed key store with quarterly rotation per policy DOC-SEC-014" passes review.

Client portals with document upload—like those on Mijar Law Associates—need encrypted storage, signed download URLs with short TTL, and audit trails on every access event.

HIPAA vs PCI: what auditors actually compare

Read our cryptography fundamentals for engineers article before choosing ciphers. Both frameworks assume you understand why AES-256 and modern TLS beat legacy options.

How Should Developers Implement TLS and Key Management?

TLS configuration is where compliant apps most often fail automated scans. A working HTTPS padlock is not enough. Weak cipher suites, expired intermediates, and mixed-content HTTP assets still trigger findings.

For Apache on Ubuntu 24 with PHP 8.4 or 8.5, a production vhost should disable TLS 1.0 and 1.1. Prefer TLS 1.3 cipher suites. Enable OCSP stapling. Redirect all HTTP to HTTPS with a 301.

# /etc/apache2/sites-available/app-ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256
SSLHonorCipherOrder on
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

# Laravel — force HTTPS in AppServiceProvider
URL::forceScheme('https');

Key management separates amateur deployments from audit-ready ones. Generate keys with a CSPRNG. Store production keys outside Git. Restrict file permissions to the PHP-FPM user. Rotate keys on a schedule and after staff departures.

PCI DSS Requirement 3.6.4 expects key changes at cryptoperiod end or when a key is suspected compromised. Document the rotation runbook. Test decrypt of archived backups before you destroy the old key.

For HIPAA workloads, align key custody with minimum-necessary access policies. Developers should not hold production ePHI decryption keys on laptops used for daily coding.

Use our password generator for service account secrets. Use a dedicated KMS or envelope encryption for data keys—not reused user passwords.

Which Common Cryptography Mistakes Fail PCI DSS and HIPAA Audits?

Most failures I see in production reviews are operational—not exotic cryptanalysis. Teams pick reasonable algorithms but implement them in ways assessors flag immediately.

1. Logging PAN or ePHI. Laravel's Log::info($request->all()) during debugging has caused real breaches. Redact before write. Use structured log processors.
2. Encrypting but not authenticating. AES-CBC without HMAC invites padding-oracle classes of bugs. Prefer AES-GCM or Laravel's authenticated encryption.
3. Hard-coded keys in Git. Scan repos with gitleaks or GitLab secret detection in CI. Rotate any exposed key immediately.
4. TLS termination only at the CDN. Origin-to-edge must also be encrypted when card or health data flows through that path.
5. Skipping backup encryption. mysqldump files and S3 buckets often hold the same PAN or ePHI as production tables.
6. Weak password storage for portal accounts. Use bcrypt or Argon2id via Laravel's default hasher. Never MD5 or SHA-1 for credentials.

API integrations that relay tokens or health payloads need rate limiting and auth hardening. See our guide on API rate limiting and abuse prevention for adjacent controls.

How Do You Build an Audit-Ready Cryptography Checklist?

Compliance documentation is part of the deliverable—not paperwork you add after launch. Build evidence alongside code so quarterly reviews do not become fire drills.

Pre-launch engineering checklist

• Data inventory listing every field that may hold PAN, CVV, or ePHI.
• Architecture diagram showing encryption boundaries and trust zones.
• TLS scan report from SSLLabs or testssl.sh with grade B or higher.
• Key custodian register with named owners and escalation contacts.
• Confirmed BAAs with hosting, email, SMS, and payment vendors.
• Log sample proving PAN and ePHI redaction in application and web server logs.
• Backup restore test showing encrypted dumps stay encrypted at rest.

WireGuard and modern VPN tunnels encrypt admin access paths. Our WireGuard cryptography explained post covers tunnel crypto for teams managing servers that hold regulated data.

On shared EC2 infrastructure I maintain for legal-tech sister sites, Deployer 7 releases plus restricted SSH keys keep production access aligned with least-privilege expectations both frameworks imply.

Version and dependency hygiene

Run supported runtime versions. PHP 8.3 or 8.4 is appropriate for Laravel 12 applications in 2026. Laravel 13 requires PHP 8.3 minimum. MySQL 8.4 LTS or MySQL 9.7 remain common database choices. Patch OpenSSL and curl promptly—they carry TLS implementations your app inherits.

Composer 2.10 and current framework releases receive security advisories through GitHub Dependabot or GitLab dependency scanning. Treat those alerts as compliance work, not optional chores.

Enterprise builds with mixed regulatory scope benefit from upfront architecture review. Our enterprise application development practice maps data classes before schema design—not after the first payment form ships.

For infrastructure hardening—UFW, fail2ban, certificate automation—see Linux system administration. Server crypto settings and application crypto settings must match.

Test encryption paths during QA cycles. Testing and optimization sprints should include negative tests: tampered ciphertext, expired TLS certs, and revoked API keys.

Payment-heavy storefronts should pair crypto controls with gateway integration review under e-commerce development. API development engagements need the same when mobile apps transmit tokens or appointment details containing ePHI.

Custom portals with document workflows fall under custom software development. Scope encryption in the statement of work—not as a change order after go-live.

Use the Base64 encoder and decoder only in development environments. Never expose production keys in browser-based tools.

External references anchor your control selections during assessor interviews. The PCI Security Standards Council document library publishes official PCI DSS v4 requirement texts. The HHS HIPAA Security Rule summary links to the authoritative regulatory language. NIST SP 800-52 Revision 2 defines approved TLS configurations federal assessors recognize.

Key Takeaways

• PCI DSS mandates strong cryptography for stored PAN and for card data crossing public networks; never persist CVV or track data.
• HIPAA treats encryption as addressable, but risk analyses almost always require it for ePHI at rest and in transit.
• Tokenize card payments at the gateway to shrink PCI scope before building custom PAN encryption.
• Document key generation, rotation, custodians, and retirement—PCI Req 3.5–3.7 and HIPAA audits both ask for proof.
• Redact PAN and ePHI from logs, queues, error reports, and analytics pipelines as strictly as from database columns.
• Run TLS 1.2 or higher everywhere regulated data moves, including origin servers behind a CDN.

People Also Ask

Is encryption mandatory under HIPAA?

HIPAA lists encryption as an addressable specification, not a strict mandate in every case. Covered entities must perform a risk analysis. If they omit encryption, they need documented compensating controls that provide equivalent protection. For ePHI on web applications, encryption in transit and at rest is the practical standard OCR expects.

What TLS version does PCI DSS require?

PCI DSS Requirement 4.2 requires strong cryptography for cardholder data on public networks. Industry practice and ASV scan tools expect TLS 1.2 as the minimum. TLS 1.0 and 1.1 are deprecated. TLS 1.3 is recommended where supported. Certificate chains must be valid and trusted.

Can I store encrypted credit card numbers in my database?

PCI DSS allows encrypted PAN storage when you follow key management requirements in Requirement 3. Storing encrypted PAN still keeps your environment in scope for assessment. Tokenization through a payment gateway is lower risk and lower scope. Never store sensitive authentication data such as CVV, regardless of encryption.

Does HIPAA apply to web developers in Nepal?

HIPAA applies to U.S. covered entities and their business associates—not geography alone. If a Kathmandu agency builds or hosts a portal for a U.S. clinic and accesses ePHI, it needs a Business Associate Agreement and the same encryption safeguards. Payment data for U.S. customers still falls under PCI DSS through acquirer contracts.

Ship Compliant Crypto Without Guesswork

Cryptography Requirements in PCI DSS and HIPAA translate directly into Laravel config, Apache TLS settings, gateway choices, and key rotation runbooks. Map your data before you write migrations. Tokenize payments when you can. Encrypt ePHI fields and backups when you must. Document every decision so your next audit is evidence review—not archaeology.

Need help scoping a payment flow, client portal, or mixed PCI-HIPAA architecture? Review relevant work on the portfolio, read more on the blog, or contact us for a structured review of your stack.