FedRAMP 20x: What RFC-0035 Proposes for Crypto Replacements

A cryptographic change can replace validated protection, update a module, or add another algorithm alongside existing protection. RFC-0035 treats those situations differently in its proposed CMU-CSO-TSC rule. For Class B and C engineering teams, the useful question is what protects federal customer data before and after the change.

FedRAMP 20x RFC 0035 crypto replacements are still a proposal topic. As checked on October 26, 2026, the official RFC index lists RFC-0035 as open, with an October 14 opening date and November 17, 2026 closing date. The comment deadline is not an adoption date.

Identify the proposed replacement trigger

Proposed CMU-CSO-TSC uses MUST to classify a change from a CMVP-validated module to a non-CMVP-validated module as transformative when those cryptographic services protect federal customer data. The RFC says this new provision would apply to Class B, C and D certifications under both 20x and Rev5.

The proposal defines a CMVP-validated module as a cryptographic module with an active validation under NIST's Cryptographic Module Validation Program, or an update stream of such a module. Its note preserves the distinction between a module update and newly added algorithms that have not been validated.

That scope matters for a 20x Class B or C change review. The proposed classification is tied to replacing validated protection of federal customer data; it is not simply a label attached to every cryptography-related code change.

Compare the three cases in the RFC

The TSC notes distinguish these cases:

Read the table as a comparison within the proposal. A statement that a case is not this change does not exempt it from general change evaluation or establish that the overall implementation is compliant.

Prepare a before-and-after explanation

As an editorial planning aid, record the existing module and algorithms, the proposed module and algorithms, and the federal-data protection each supplies. Link the validation evidence and identify whether the plan retains validated protection, replaces it, or leaves that point unresolved.

Include the implementation owner and the evidence behind the description. An update-stream label alone is not enough to explain whether a newly added algorithm replaces a validated one. Likewise, calling a design “hybrid” does not explain whether the CMVP-validated module continues to protect the federal customer data in question.

For an uncertain case, write the uncertainty as a specific question for review or RFC feedback. For example: which part of the data protection would change, and what evidence shows that the validated module remains in use? This working record is not an approval to migrate or a new official artifact.

Keep current duties and the Class D proposal separate

Current SCN-CSO-EVA requires evaluation of all potential significant changes to determine their type and follow the appropriate notification rules. Continue that current analysis; the significant change classification guide covers the broader workflow.

RFC-0035 separately proposes changing Class D's CMU-CSO-UVM force from MUST to SHOULD. That Class D change is distinct from TSC's proposed B/C/D replacement classification. The RFC expressly says it does not change agency obligations under FIPS 140-3 or establish post-quantum cryptography requirements.

Use the comment window for a precise question

The RFC index's feedback instructions direct commenters to the discussion in FedRAMP's GitHub RFC repository, or to an alternative mechanism specified in an RFC. Recheck the current instructions before submitting.

A useful comment identifies the before-and-after protection, the proposed clause being interpreted and the remaining ambiguity. Keep that feedback separate from a decision under today's rules, and check the published outcome before treating proposed TSC language as effective.