The FedRAMP Consolidated Rules for 2026 (CR26) change more than vocabulary and certification mechanics. They make cryptography protecting federal customer data explicitly accountable.
Under the new Cryptographic Module Use (CMU) rules, Cloud Service Providers (CSPs) must document which cryptographic modules protect federal customer data, where those modules are used, and whether they hold an active NIST Cryptographic Module Validation Program (CMVP) validation or qualify as an eligible update stream.
That sounds simple in theory. In practice, it exposes a gap many cloud providers struggle with: cryptographic debt.
Cryptographic implementations accumulate across applications, dependencies, infrastructure, platforms, and third-party components. Some may be outdated, unvalidated, outside policy, or simply unknown to the teams responsible for compliance.
Our earlier post, FedRAMP CR26: Cryptography and PQC Readiness, looks at the broader implications of CR26 for cryptography, automation, and post-quantum readiness.
This article focuses on the operational question: What do the CR26 Cryptographic Module Use rules require, and what should CSPs be prepared to prove?
The Three FedRAMP CR26 Cryptographic Module Use Rules
Three rules govern how CSPs document, select, and configure cryptography.
1. CMU-CSO-CMD: Cryptographic Module Documentation
For Certification Classes B, C, and D, providers MUST document the cryptographic modules used in each service—or groups of services sharing the same modules—where cryptography protects federal customer data.
That documentation must identify whether each module:
- Holds an active CMVP validation, or
- Is part of an eligible update stream of a validated module
The important word is used.
The obligation is not simply to state that a product “supports FIPS.” CSPs need an accurate record of the cryptographic modules actually protecting federal customer data across their services.
Key takeaway: CR26 turns cryptographic module documentation from a high-level product assertion into an operational evidence requirement.
2. CMU-CSO-UVM: Using Validated Cryptographic Modules
CR26 applies a risk-based approach to validated cryptography, with requirements becoming stronger as Certification Class increases:
| Certification Class | CR26 Validation Requirement |
| Class A | MAY use validated modules or update streams |
| Class B | MAY use validated modules or update streams |
| Class C | SHOULD use validated modules or update streams |
| Class D | MUST use validated modules or update streams |
That distinction is important. FedRAMP CR26 does not apply the same cryptographic validation requirement identically across every Certification Class.
3. CMU-CSO-CAT: Configuration of Agency Tenants
For Classes B, C, and D, providers SHOULD configure agency tenants by default to use cryptographic services backed by modules—or eligible update streams—with active CMVP validations where those options are available.
Taken together, the CMU rules change the practical question from:
“Does our product support FIPS?”
to:
“Which cryptographic module is this service actually using, what is its validation status, and can we prove that accurately?”
FedRAMP CR26 Timelines: 20x vs. Rev5
The Cryptographic Module Use rules do not follow the same implementation schedule for FedRAMP 20x and Rev5.
FedRAMP 20x
- Optional adoption: July 4, 2026
- Obtain: July 4, 2026
- Maintain: January 1, 2027
- Grace period ends: With the first FedRAMP independent assessment started after January 1, 2027
FedRAMP Rev5
- Optional adoption: July 4, 2026
- Obtain: January 1, 2027
- Maintain: January 1, 2027
- Grace period ends: June 1, 2027
Regardless of path, January 2027 is an important operational milestone for maintaining CR26 evidence.
For organizations moving to FedRAMP 20x, this sits within a broader shift toward persistently maintained, structured security evidence through mechanisms such as the Security Decision Record.
For cryptography specifically, the requirement is clear: CSPs need documentation that reflects the cryptographic modules actually protecting federal customer data and their current validation status.
Why Cryptographic Documentation Is Harder Than It Sounds
Most engineering teams can produce a high-level list of cryptographic technologies they intend to use.
Far fewer can map what is actually running across a production environment at any given moment.
Cryptography enters an authorization boundary through many paths:
- Application dependencies and frameworks
- Base container images and operating system libraries
- Cloud and platform services
- TLS termination and network infrastructure
- Certificates and PKI components
- Third-party commercial software
- Embedded and inherited components
Meanwhile, development teams release new code, dependencies change, infrastructure is rebuilt, and configurations drift.
A spreadsheet created for an assessment may have been accurate when it was written. That does not mean it still reflects the environment weeks or months later.
This is where cryptographic debt becomes an operational problem.
Older, unknown, unvalidated, or out-of-policy cryptographic implementations can accumulate faster than compliance teams can document them manually.
Under a model built around persistently maintained evidence, that gap becomes increasingly difficult to ignore.
You Cannot Document Cryptography You Cannot See
Consider what CR26 requires a CSP to know.
Which cryptographic module protects federal customer data in each service?
Which version is actually deployed?
Does it hold an active CMVP validation?
Is the deployed software covered by an eligible update stream?
Has the module’s validation status changed?
Did a dependency, container, or pipeline change introduce a different implementation?
If answering those questions requires surveying engineering teams or reconciling spreadsheets every time the environment changes, the challenge is no longer simply documentation.
It is cryptographic visibility.
That is also why September 2026 FIPS 140-2 sunset matters in a continuous-evidence environment. When a certificate moves from Active to Historical, CSPs need to know which services rely on it and where a FIPS 140-3 replacement is required.
The PQC Mandate Lives Next Door
CR26 does not mandate post-quantum cryptography.
The CMU rules do not prescribe ML-KEM, ML-DSA, or another PQC algorithm, and they do not establish a PQC migration deadline.
But a parallel federal policy track reaches many of the same organizations.
Executive Order 14412, issued June 22, 2026, directs federal agencies to transition high-value assets and high-impact systems to post-quantum cryptography for key establishment by December 31, 2030, and digital signatures by December 31, 2031.
The order also directs the FAR Council to propose requirements for covered federal contractors to comply with applicable NIST FIPS incorporating PQC by December 31, 2030.
OMB Memorandum M-26-15 followed two days later and pushes the migration further toward execution. It directs agencies to develop risk-based PQC migration plans, coordinate shared migration responsibilities with FedRAMP-authorized cloud service providers, and use automation where feasible to improve cryptographic discovery and inventory.
The connection to CR26 is not that the two requirements are identical.
They depend on the same underlying capability.
CR26 asks CSPs to know which cryptographic modules protect federal customer data today.
PQC migration asks which cryptography will need to change tomorrow.
You cannot migrate an algorithm you cannot find. You cannot document a module you cannot see.
Five Questions Every CSP Should Be Able to Answer
Before cryptographic evidence becomes an assessment problem, CSPs should be able to answer five questions:
- Which cryptographic modules protect federal customer data across every applicable service in our authorization boundary?
- Does each module hold an active CMVP validation, or is the deployed software covered by an eligible update stream?
- Can we detect when a dependency, image, platform, or pipeline change introduces different or unvalidated cryptography?
- Can we keep this information current as fast as our applications and infrastructure change?
- When cryptography needs to change—because of validation status, policy, vulnerability, or PQC migration—can we verify that the remediation reached every affected service?
If answering those questions requires a manual survey across teams, the underlying issue is bigger than CR26 documentation.
It is the ability to continuously understand and govern your cryptographic posture.
How SafeLogic Supports Continuous Cryptographic Visibility
Compliance evidence should not require an audit-season scramble.
SafeLogic Cryptographic Posture Management (CPM) helps organizations discover, understand, remediate, and continuously govern cryptographic risk across applications, infrastructure, networks, cloud environments, repositories, and development pipelines.
SafeLogic CPM can help organizations build and maintain visibility into:
- Cryptographic implementations and algorithms
- Applications and infrastructure using them
- Policy and validation status
- Ownership and dependencies
- Post-quantum exposure
- Remediation priorities
- Changes over time
It also supports continuously maintained operational Cryptographic Bills of Materials (CBOMs), helping move cryptographic inventory from a point-in-time spreadsheet to an operational source of evidence.
That visibility can support CR26 cryptographic documentation while also providing the foundation for a post-quantum migration strategy.
When discovery identifies cryptography that needs to change, SafeLogic provides an implementation path across the cryptographic lifecycle:
CryptoComply provides FIPS 140-3 validated cryptographic software for modern application environments, giving organizations a validated foundation for replacing cryptography that no longer meets policy or compliance requirements.
RapidCert provides a path to a FIPS 140-3 certificate in your organization’s own name in about 90 days, compared with the 2+ years often associated with traditional validation.
MaintainCert helps keep validations current as software, operating environments, algorithms, and requirements evolve.
SafePQ supports phased post-quantum migration and hybrid cryptography as organizations move from inventory and planning toward implementation.
Together, these capabilities connect visibility with remediation rather than leaving cryptographic inventory as an end state.
Know Your Cryptographic Posture Before It Becomes an Assessment Question
CR26 makes cryptographic module documentation explicit.
Federal PQC policy makes cryptographic discovery increasingly urgent.
Treating those as separate exercises risks duplicating work while leaving the same underlying visibility problem unresolved.
A better approach is to maintain an operational understanding of your cryptography: what is running, where it is running, whether it meets current requirements, and what needs to change next.
Compliance evidence can then become a byproduct of managing cryptographic risk well—not a document reconstructed before every assessment.
Talk to a SafeLogic Cryptography Expert to explore how SafeLogic CPM can support cryptographic visibility for CR26 requirements and your post-quantum roadmap.
