Cryptographic Requirements Across FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA

Quick answer: Cryptographic compliance means proving that your algorithms, keys, certificates, and protocols meet FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA at once. Each framework demands strong, current cryptography with documented ownership and evidence. The fastest path is one verified inventory mapped to every framework, not five separate compliance projects.

If your organization handles sensitive data, you are almost certainly subject to multiple regulatory frameworks, and each has something to say about cryptographic compliance. FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA were written for very different purposes, yet they converge on the same expectations: use strong cryptography, manage it properly, and be able to prove that you are doing so.

Tackling cryptographic compliance one framework at a time is slow, costly, and easy to get wrong. The overlap between them is substantial, so a single, well-maintained view of your cryptography can satisfy much of what each one asks. This guide maps what FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA each require to specific controls, control owners, and audit-ready evidence, and lays out the implementation steps and checklist that turn five overlapping obligations into one program.

Key Takeaways

• FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA all require the same four things of cryptography: know where it is used, keep it strong and approved, manage keys and certificates through their lifecycle, and produce evidence on demand.
• FIPS 140-2 validated modules move to the CMVP Historical List on September 21, 2026; new procurements and assessments should confirm FIPS 140-3 validation rather than an expiring FIPS 140-2 certificate.
• PCI DSS v4.0.1 is the active standard, and every future-dated requirement, including the cryptographic inventory in Requirement 12.3, has been mandatory since March 31, 2025.
• HIPAA currently treats ePHI encryption as addressable rather than required; a proposed rule would make it mandatory, but it remains unfinalized as of this update.
• A single cryptographic inventory, mapped once to controls, owners, and evidence artifacts, can satisfy the crypto-specific portion of all five frameworks, cutting audit preparation from a recurring scramble to a standing report.

The Common Thread Across Every Framework

FIPS, PCI DSS, HIPAA, GDPR, and DORA come from different worlds: federal security, payments, healthcare, privacy, and financial resilience. But they increasingly converge on the same expectations: use strong, approved cryptography; manage keys and certificates properly; know where cryptography is used; and be able to demonstrate it. The hard part is rarely the rule itself; it is proving compliance across a sprawling, constantly changing environment.

FIPS 140-3

What it is: A U.S. federal standard, maintained by NIST’s Cryptographic Module Validation Program (CMVP), that defines security requirements for cryptographic modules. It is widely referenced beyond government as a benchmark of cryptographic assurance.

Cryptographic focus:

• Use of approved algorithms and validated cryptographic modules.
• Proper key management and secure handling of cryptographic material.
• Avoidance of weak or non-approved algorithms.

What changed recently: NIST retires FIPS 140-2 validations on September 21, 2026, moving every remaining certificate to the CMVP Historical List. FIPS 140-2 modules already deployed can generally continue in existing systems, but NIST no longer accepts new FIPS 140-2 submissions, and new procurements should specify FIPS 140-3 validated modules.

How CBOM Secure helps: Identifies the algorithms in use across your environment, flags non-approved or weak choices, and gives you the inventory needed to demonstrate that approved cryptography, and the correct validation standard, is in place.

PCI DSS

What it is: The Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council, which protects cardholder data for any organization that stores, processes, or transmits it. Version 4.0.1 is the active release.

Cryptographic focus:

• Strong cryptography to protect stored account data (Requirement 3).
• Strong cryptography and secure protocols to protect data transmitted over open or public networks (Requirement 4).
• Documented key and certificate management throughout the lifecycle.
• A documented, regularly reviewed inventory of cryptographic cipher suites and protocols in use (Requirement 12.3).

What changed recently: All future-dated PCI DSS v4.0 requirements, including the Requirement 12.3 cryptographic inventory, became mandatory on March 31, 2025, under the current v4.0.1 release. Any assessment conducted now is scored against the full standard, not the earlier phased timeline.

How CBOM Secure helps: Maintains the cipher-suite and protocol inventory PCI DSS expects, surfaces weak protocols and algorithms, and provides continuous evidence that strong cryptography is in use.

HIPAA

What it is: The U.S. healthcare framework whose Security Rule governs the protection of electronic protected health information (ePHI).

Cryptographic focus:

• Encryption of ePHI at rest and in transit as a safeguard against unauthorized access.
• Encryption to recognized standards, which can reduce breach-notification exposure.

What changed recently: Under the current rule, encryption remains an addressable implementation specification, meaning a covered entity can adopt an equivalent alternative if it documents the reasoning. HHS proposed a rule in January 2025 that would remove that flexibility and make encryption of ePHI required, but the rule is still unfinalized, with a federal review target now pushed to mid-2027. Treat mandatory encryption as the direction of travel, not yet the binding requirement.

How CBOM Secure helps: Verifies that systems handling sensitive data use strong, current encryption, and highlights gaps or weak cryptography that could undermine those safeguards, whether encryption is treated as addressable or required.

GDPR

What it is: The European Union’s General Data Protection Regulation, governing the protection of personal data.

Cryptographic focus:

• Encryption is named explicitly as an appropriate measure to protect personal data (Article 32).
• Strong encryption can reduce the obligation to notify individuals after a breach (Article 34).

How CBOM Secure helps: Provides evidence that personal data is protected by strong cryptography and identifies weak or missing protection across your estate.

DORA

What it is: The European Union’s Digital Operational Resilience Act, Regulation (EU) 2022/2554, which strengthens the ICT risk posture of financial entities and their technology providers. It has applied directly across EU member states since January 17, 2025.

Cryptographic focus:

• Encryption of data at rest and in transit as part of ICT risk management.
• A defined policy for cryptographic controls and key management.
• Attention to evolving threats, including the move toward post-quantum cryptography.

What changed recently: 2026 is DORA’s supervision and enforcement phase. National competent authorities across the EU have moved from implementation guidance to active reviews of ICT risk management, including cryptographic controls, so an undocumented key management policy is now an examination finding rather than a planning gap.

How CBOM Secure helps: Backs your cryptographic controls policy with real inventory, identifies gaps, and supports resilience and post-quantum planning with continuous visibility.

What These Cryptographic Compliance Requirements Have in Common

Strip away the sector-specific language, the differing legal bases, and the regional scope, and the five frameworks converge on the same handful of expectations. Whether the driver is federal assurance, payment security, patient privacy, data protection, or operational resilience, each one ultimately asks you to do the same four things with your cryptography:

Know where cryptography is used across your environment: You cannot protect, validate, or report on what you cannot see. This means building and maintaining a complete inventory of the algorithms, protocols, keys, and certificates in use across applications, servers, databases, network traffic, source code, and cloud services, not just the systems you happen to remember to check.

Ensure it is strong, approved, and free of deprecated algorithms: Every framework expects modern, well-vetted cryptography and the retirement of anything weak or broken, such as MD5, SHA-1, DES, or undersized RSA keys. As standards evolve and computing power grows, the definition of strong keeps moving, so this is a continuous exercise rather than a one-time clean-up.

Manage keys and certificates throughout their lifecycle: Strong algorithms are only as trustworthy as the keys behind them. Generation, distribution, storage, rotation, and revocation all need defined controls, and expired or poorly protected keys and certificates are a common cause of both outages and breaches.

Be able to demonstrate all of the above, on demand: Auditors, regulators, and customers increasingly want evidence rather than assurances. That calls for current, accurate documentation of your cryptographic posture that you can produce quickly during an audit, a vendor assessment, or a breach investigation, instead of reconstructing it under pressure.

Each framework dresses up these expectations in its own terminology, but an organization that handles all four well is most of the way to satisfying every standard at once. That is precisely the problem CBOM Secure is built to solve.

Mapping Requirements to Controls, Owners, and Evidence

Knowing what a framework expects is only useful once it is assigned to a person and backed by something an auditor can inspect. The table below breaks each framework’s cryptographic expectation into a specific control, the role that typically owns it, and the evidence artifact an assessor will ask to see.

Framework	Cryptographic Control	Typical Control Owner	Evidence Artifact
FIPS 140-3	Only FIPS 140-3 validated modules used for new cryptographic deployments	Security engineering / platform team	CMVP certificate numbers mapped to deployed modules
PCI DSS	Documented, reviewed inventory of cipher suites and protocols (Req. 12.3)	PCI compliance manager / QSA liaison	Current cryptographic inventory export plus review sign-off
HIPAA	Encryption of ePHI at rest and in transit, or a documented equivalent alternative	HIPAA Security Officer	Risk analysis documenting the encryption decision and coverage
GDPR	Encryption of personal data as an Article 32 technical measure	Data Protection Officer	Records of processing activities citing the applied encryption
DORA	Documented cryptographic controls and key management policy	ICT risk management function	Policy document plus continuous control-testing results

The specific artifact each framework wants differs, but every one of them is generated from the same underlying inventory. Build that inventory once, tag it against each framework’s control, and the evidence column stops being a separate project per regulation.

Side-by-Side Framework Comparison

Here is how the five frameworks compare on primary cryptographic focus and current status, so the common ground and the open questions are easy to see at a glance.

Framework	Primary Cryptographic Focus	Current Status (as of this update)
FIPS 140-3	Approved algorithms and validated modules	Sole active validation standard; FIPS 140-2 moves to CMVP Historical on Sept. 21, 2026
PCI DSS	Strong crypto and a cipher/protocol inventory	v4.0.1 active; all future-dated requirements mandatory since March 31, 2025
HIPAA	Encryption of ePHI at rest and in transit	Encryption addressable today; mandatory-encryption rule proposed, not yet final
GDPR	Encryption of personal data	Article 32 stable; no pending change to the encryption provision
DORA	Crypto-controls policy and resilience	Applied since Jan. 2025; 2026 is the active supervision and enforcement phase

Implementation Steps: Building One Program for All Five Frameworks

The sequence below turns the mapping above into a repeatable program rather than a one-time compliance sprint.

1. Build a complete cryptographic inventory: Discover every algorithm, key, certificate, and protocol across applications, infrastructure, source code, and cloud services. An inventory that only covers systems someone remembered to check is not an inventory an auditor will accept.
2. Map each asset to the frameworks it touches: Tag inventory items against the specific controls in the table above so one scan answers FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA questions simultaneously instead of five separate ones.
3. Assign a named owner to every control: Ownership without a name attached is the most common reason evidence cannot be produced on demand. Match each row in the mapping table to a role, not a team.
4. Remediate weak, deprecated, or unvalidated cryptography: Prioritize algorithms flagged by NIST guidance (MD5, SHA-1, DES, undersized RSA keys) and any module still relying on an expiring FIPS 140-2 certificate.
5. Automate evidence collection: Point-in-time spreadsheets go stale before the next audit cycle starts. Continuous, timestamped exports hold up better under examination than a document reconstructed the week before an assessment.
6. Set a review cadence tied to each framework’s cycle: Annual PCI DSS assessments, ongoing DORA supervisory reviews, and HIPAA risk analyses all expect current data, not a snapshot from the last audit.
7. Build post-quantum migration into the same inventory: DORA already calls out post-quantum readiness, and the other frameworks will follow. Tracking quantum-vulnerable algorithms now avoids a second inventory project later.

Audit-Ready Compliance Checklist

Use this checklist to confirm the program above is actually producing what an assessor will ask for, across any of the five frameworks:

• A current cryptographic inventory covering algorithms, keys, certificates, and protocols, dated within the last review cycle.
• Documented mapping of each inventory item to the specific control it satisfies in each applicable framework.
• A named owner and escalation path for every cryptographic control, not just a team distribution list.
• Confirmation that new cryptographic modules are FIPS 140-3 validated, with CMVP certificate numbers on file.
• A remediation log for weak, deprecated, or expiring algorithms, with target dates rather than open-ended commitments.
• Key and certificate lifecycle records covering generation, rotation, and revocation, not just issuance.
• A documented cryptographic controls policy that a DORA or internal ICT risk review can point to directly.
• An export format (such as CycloneDX) an auditor can consume without a manual translation step.
• A tracked count of quantum-vulnerable algorithms, so post-quantum readiness is a number, not an assertion.

Limitations of a Single Compliance Program

A unified cryptographic inventory closes the crypto-specific gap across all five frameworks, but it does not replace each framework’s non-cryptographic requirements. PCI DSS still requires network segmentation testing and access control reviews unrelated to encryption. HIPAA still requires business associate agreements and breach-notification timelines. GDPR still governs lawful basis, data subject rights, and cross-border transfer mechanisms well beyond Article 32. DORA still requires incident reporting and third-party risk oversight covering more than cryptography. Treat this guide, and CBOM Secure, as the cryptographic layer of a broader compliance program, not a substitute for legal review or a formal audit.

Meeting Every Framework with Encryption Consulting

Knowing what the frameworks demand is one thing; satisfying all of them, continuously, across an ever-changing environment is another. It takes both the right expertise and the right platform. Encryption Consulting’s Compliance Advisory Services interpret FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA for your specific environment, assign the control owners in the mapping table above, and build the policy documentation examiners expect. CBOM Secure is the platform that keeps the underlying inventory and evidence current between engagements.

Together, the advisory work and the platform give you:

• A compliance program design that names control owners and evidence artifacts for each framework in scope, not a generic checklist.
• A single, continuously updated inventory of all cryptography across on-premises, cloud, and application environments, detailed further in how CBOM Secure builds compliance evidence.
• Automatic detection of weak, deprecated, and non-compliant algorithms and protocols, such as MD5, SHA-1, DES, and legacy TLS.
• Risk prioritized and mapped to FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA, so you address what matters most first.
• Continuous, audit-ready evidence you can produce on demand, rather than point-in-time snapshots.
• Expert remediation and advisory across PKI, key management, HSMs, and post-quantum readiness.

Encryption Consulting helps you turn overlapping requirements into a single, manageable program, backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

Conclusion

FIPS 140-3, PCI DSS, HIPAA, GDPR, and DORA were written for very different purposes, but they all point in the same direction: strong, well-managed, and demonstrable cryptography. The organizations that cope best are not the ones chasing each framework in isolation, but the ones that build a single, accurate view of their cryptography, map it to named owners and evidence, and keep it current. That view is what turns five overlapping obligations into one manageable program.

CBOM Secure gives you that view: continuous visibility into every algorithm, protocol, key, and certificate, the audit-ready evidence each framework expects, and a foundation for the move to post-quantum cryptography. Encryption Consulting’s Compliance Advisory Services bring the expertise to interpret findings, assign ownership, close gaps, and keep you compliant as both your environment and regulations evolve.

Facing one framework or five? Talk to Encryption Consulting about meeting your cryptographic requirements with CBOM Secure and Compliance Advisory Services.

FAQs

What happens to FIPS 140-2 in September 2026?

FIPS 140-2 modules remain active until September 21, 2026, when NIST moves existing FIPS 140-2 certificates to the CMVP Historical List. FIPS 140-3 is now the only standard NIST accepts for new cryptographic module validation, so any new procurement or system should confirm FIPS 140-3 validation rather than relying on a historical FIPS 140-2 certificate.

Does PCI DSS require FIPS-validated cryptography?

PCI DSS 4.0.1 does not mandate FIPS-validated modules by name, but it requires strong cryptography, documented key management, and a reviewed inventory of cipher suites and protocols under Requirements 3, 4, and 12.3. Many organizations use FIPS 140-3 validated modules to satisfy the strong cryptography expectation because it is a recognized, auditable benchmark.

Is encryption mandatory under HIPAA?

Not yet. Under the current HIPAA Security Rule, encryption of ePHI is an addressable implementation specification, meaning covered entities can adopt an equivalent alternative if they document the reasoning. A proposed rule issued in January 2025 would remove that flexibility and make encryption required, but it remains unfinalized, with a federal review target now set for mid-2027.

Does GDPR require encryption?

GDPR Article 32 names encryption explicitly as an appropriate technical measure to protect personal data, and strong encryption can reduce breach-notification obligations under Article 34. GDPR does not mandate a specific algorithm, so organizations must be able to justify that the cryptography used is current and proportionate to the risk.

How does DORA treat cryptographic key management?

DORA requires financial entities to manage cryptographic controls as part of ICT risk management, including a documented policy for encryption and key management and attention to emerging threats such as the shift toward post-quantum cryptography. Since 2026, EU national competent authorities have moved from guidance to active supervision of these controls.

Can one cryptographic inventory satisfy multiple compliance frameworks?

Yes, in principle. Every framework converges on the same underlying expectations: know where cryptography is used, keep it strong and current, manage keys and certificates properly, and produce evidence on demand. A single, continuously maintained cryptographic inventory can satisfy the crypto-specific portion of all five, though each framework still has non-cryptographic requirements that need separate coverage.