Cloud cryptography cannot be governed by a single “FIPS compliant” checkbox. On October 14, FedRAMP published RFC-0035, Cryptographic Module Use Rules Updates, a proposal to revise its Consolidated Rules for 2026 across FedRAMP 20x and Rev. 5.
The proposal would change the Class D expectation for using Cryptographic Module Validation Program (CMVP)-validated modules from “must” to “should,” matching Class C. It would not change agency obligations under FIPS 140-3, impose post-quantum requirements, or require operating cloud services to change immediately. Instead, it puts greater weight on documentation that lets an agency determine where validated modules protect federal data and where they do not.
Flexibility increases the need for precision
RFC-0035 acknowledges that some cloud services use cryptography outside a validated module for legitimate technical or operational reasons. It also notes that requiring a separate government-only cryptographic path can increase cost, lag commercial security updates, or reduce performance.
That flexibility is useful only when customers can see the boundary. The proposal retains a requirement for providers to document cryptographic modules used in each service, or groups of services using the same modules, when cryptography protects federal customer data. The documentation must identify whether those modules are CMVP validated.
A decision-ready record should include:
- cloud service, feature, tenant configuration, and protected data flow;
- cryptographic function, algorithm, mode, protocol, and purpose;
- module name, version, implementation boundary, and operating environment;
- CMVP certificate number, status, security policy, and covered algorithms;
- whether the deployed operation is inside the validated configuration;
- non-validated components or algorithms used alongside the validated module;
- provider evidence, observation date, confidence, and accountable owner; and
- exceptions, agency decisions, remediation, and reassessment triggers.
Without that detail, an agency cannot distinguish a validated module from a product that happens to contain one.
Validation scope is narrower than product capability
The proposal defines a CMVP-validated module as one with an active validation, or an update stream of such a module. It also draws an important boundary: if an update stream adds an algorithm that was not previously validated, that new algorithm is not validated merely because it appears in the same module.
This matters for post-quantum adoption. A provider may add an ML-KEM implementation to a module or service that already has validated traditional algorithms. The existence of the validated module does not automatically extend validation to ML-KEM. Inventory records should attach validation evidence to the exact algorithm, function, version, and deployment mode it covers.
Procurement and compliance language should separately report available capability, enabled configuration, observed use, and validated use. Collapsing those states invites unsupported conclusions.
A module change can be a risk-decision event
RFC-0035 proposes treating replacement of a CMVP-validated module with a non-validated module as a transformative change for Class B, C, and D services when the cryptography protects federal customer data. The purpose is timely notice so agencies can revisit their risk determination.
That is a powerful operating principle beyond FedRAMP. Cryptographic inventory should not be a periodic snapshot. Changes in module, algorithm, validation status, configuration, or service boundary should generate review work for affected consumers.
The relationship graph matters: which tenants, workloads, contracts, controls, and data classes depended on the prior state? Who must approve the new state? What evidence must be refreshed? A change notification without impact mapping still leaves agencies to reconstruct exposure under time pressure.
Hybrid PQC needs two kinds of evidence
The proposal states that adding a non-validated algorithm while a validated module continues to protect federal data—such as a hybrid implementation—is not by itself the same transformative change as replacing the validated module. That does not make the new algorithm validated or risk-free.
Hybrid deployments should retain evidence for both components and the composition: component versions, negotiation behavior, combiner design, failure handling, covered traffic, validation boundary, and interoperability tests. Teams must preserve the difference between continuity of validated traditional protection and assurance for the added PQC path.
What organizations should do next
First, inventory cryptographic modules at the service and data-flow level, not only at the vendor level. One cloud offering may use different modules across features and tenants.
Second, map each validation claim to a certificate, security policy, algorithm, version, operating environment, and approved mode. Keep unsupported relationships visibly unresolved.
Third, define cryptographic change events. Module replacement, validation-status change, newly enabled algorithm, boundary change, and hybrid deployment should trigger impact review.
Fourth, require providers to supply machine-usable evidence where possible. Evidence should include effective dates and affected service populations, not only a general assurance statement.
Finally, remember that RFC-0035 is a proposal. Track its disposition and any resulting rules before treating the language as a final FedRAMP requirement.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through discovery, canonical inventory, evaluation, action, and proof. Teams can connect services, assets, modules, algorithms, validation evidence, owners, exceptions, and remediation in one governed model.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory and CBOM and compliance resources.
Where uncertainty remains
RFC-0035 is open policy work rather than a final rule, and agencies remain responsible for their own FIPS 140-3 obligations and risk decisions. The durable lesson is independent of the outcome: more flexible technology choices require more precise, current, and traceable cryptographic evidence.
Source
- RFC-0035 Cryptographic Module Use Rules Updates, FedRAMP, October 14, 2026.