A cryptographic module can change quietly inside a product, while its compliance implications are anything but small.
On October 14, 2026, FedRAMP published RFC-0035, proposing updates to its Cryptographic Module Use rules for both FedRAMP 20x and Rev5 certifications. The proposal clarifies how providers identify NIST-validated cryptographic modules and classify certain changes to those modules.
These details matter because changes to the components that protect federal customer data can affect security evidence, agency expectations and decisions about cloud service updates. However, RFC-0035 does not require every provider to replace its cryptographic modules immediately. Nor does it establish a post-quantum cryptography mandate.
This blog explains what the proposal could mean for security teams and how better module records, change reviews and customer communication can help organizations prepare.
What RFC-0035 Proposes
RFC-0035 remains open for public comment through November 17, 2026. It proposes updates to the 2026 Consolidated Rules for FedRAMP 20x and Rev5. One change defines a “CMVP-validated module” as a cryptographic module with an active validation under NIST’s Cryptographic Module Validation Program (CMVP) or an update stream of such a module.
Another change would replace “MUST” with “SHOULD” in the Class D guidance for using validated modules, aligning it with Class C. This would relax a firm restriction for some Class D use cases but it would not change agency obligations under FIPS 140-3. The proposal also introduces a rule that would classify certain changes from a validated module to a non-validated module as transformative for Class B, C and D certifications when the cryptographic service protects federal customer data. FedRAMP states that currently operating cloud services do not need to change their practices in response to this proposal. Until FedRAMP finalizes the rules, teams should treat RFC-0035 as a proposed direction rather than an adopted requirement.
Why Module Visibility Matters Before a Change
A cryptographic module is not necessarily the same as the product or service that contains it. A cloud platform, VPN, security appliance or application may rely on an embedded module. A general product claim such as “uses FIPS encryption” does not prove that the deployed module holds a valid certification or that its version and operating environment match the validation. NIST recommends checking certificate details and asking vendors how their products use validated components. Security teams can start with the NIST CMVP validated-module database.
FedRAMP’s existing 2026 rules already require applicable providers to document the cryptographic modules they use to protect federal customer data, including each module’s validation status or its relationship to a recognized update stream. Teams should connect each module to the relevant service, vendor, version, certificate, operating environment and accountable technical owner. NIST distinguishes active, historical and revoked validations in its records. Teams should therefore verify each module’s current status instead of relying indefinitely on information from an older assessment package.
Distinguish a Module Update From a Change in Validation Scope
RFC-0035 distinguishes between updating a validated module through its recognized update stream and replacing it with a non-validated module. Under the proposal, an update through the recognized stream would not, by itself, qualify as a transformative change.
However, an update stream does not automatically extend a module’s existing validation to every new algorithm. If a service starts using a newly added algorithm instead of a validated algorithm to protect federal customer data, the proposal treats that change as potentially transformative. The RFC also clarifies that adding a non-validated algorithm alongside a validated module, such as in a hybrid implementation, differs from replacing the validated module, provided the validated module continues to protect federal customer data.
These distinctions mean teams should not classify every patch as transformative or assume that every vendor update remains within the validated scope. Instead, they should determine which cryptographic components and algorithms the service actually uses to protect the data.
Put Cryptographic Dependencies Into Change Reviews
When a planned platform migration, library replacement or vendor release affects cryptographic services, the change request should identify the module involved and the function it performs. Reviewers should determine whether the change affects the module, its version, its validation status, the algorithms in use or the way the service protects federal customer data. Teams can incorporate these checks into their existing change control processes rather than creating a separate committee for every routine update.
The decision record should link to supporting evidence, including the NIST certificate entry, vendor confirmation, architecture or data flow diagrams, test results, security impact analysis and rollback plan. Reviewers should also assess the effects on key handling, interoperability, tenant configuration, service availability and dependent applications where relevant. If the available evidence does not clearly establish what will change, reviewers should seek clarification before approving the request. A broad compliance claim should never substitute for technical evidence.
Connect Technical Review to FedRAMP and Customer Decisions
Security engineers can determine what has changed but compliance and program owners must assess the implications. They should review the service’s certification class, the applicable FedRAMP rules and relevant agency commitments. If FedRAMP adopts RFC-0035, a change from a validated module to a non-validated module may qualify as transformative for affected Class B, C or D services. Teams should confirm the assessment and communication process under the final rules rather than assume that every service follows the same path.
Customer communication should be specific and proportionate. Explain which service or data path the change affects, which module or algorithm will change, whether the validation scope will change, what testing the team has completed and whether customers need to take action. This approach gives agency stakeholders useful information and helps account teams answer questions consistently. It also preserves the technical rationale behind the decision.
What Security Teams Can Do While the Proposal Is Open
The public comment period gives organizations an opportunity to review their current practices before FedRAMP finalizes the proposal.
Start by checking the module inventory against vendor documentation and the NIST CMVP database. Identify planned cryptographic changes and ask suppliers to distinguish updates within a recognized update stream from changes involving modules or algorithms outside that validation scope. If a supplier cannot provide clear evidence, document the gap and resolve it through technical review or procurement. Organizations can also submit comments on RFC-0035 by November 17, 2026, particularly if the proposed distinctions raise operational questions.
Keep post-quantum cryptography planning separate. FedRAMP explicitly states that RFC-0035 does not establish post-quantum requirements or change agency obligations under FIPS 140-3. The immediate priority is better visibility into cryptographic dependencies and more informed change decisions, not an unnecessary migration.
Frequently Asked Questions
RFC-0035 is a proposal that FedRAMP published on October 14, 2026, to update its Cryptographic Module Use rules for 20x and Rev5. It clarifies terminology for CMVP-validated modules and proposes how teams should classify certain changes from validated to non-validated modules.
No. FedRAMP states that currently operating cloud services do not need to change their practices in response to the proposal. Providers should continue following the rules that currently apply to their services and monitor RFC-0035 throughout the public comment process.
Under the proposal, a change from a CMVP-validated module to a non-validated module would qualify as transformative for Class B, C and D certifications when the affected cryptographic service protects federal customer data. The proposal distinguishes this change from an update through a module’s recognized update stream.
No. FedRAMP explicitly states that the proposal does not establish post-quantum cryptography requirements. It also does not change agency obligations under FIPS 140-3.
Search the NIST CMVP validated-module database and review the certificate details. Ask the vendor to confirm which module and version the product uses and whether that implementation aligns with the validation.
Strengthen Cryptographic Change Management With XieTek
XieTek LLC provides Cybersecurity Services to help organizations assess security risks, improve cloud and application security, strengthen compliance readiness and maintain evidence that supports informed decisions.
For federal contractors, technical changes require clear ownership, traceable evidence and a thorough understanding of operational impact.
Reviewing cryptographic dependencies or improving change control practices? Contact XieTek LLC to discuss cybersecurity support aligned with your systems, security requirements and operational needs.