FedRAMP 20x Class D Proposal: Document Post-Quantum Status

An algorithm inventory is more useful when a reviewer can see what each algorithm protects, what its status means and which transition questions remain open. The proposed FedRAMP 20x Class D post quantum status provision gives security architects a specific documentation question to prepare for without setting a universal migration date.

As checked on October 26, 2026, RFC-0036 still presents CMU-CSO-PQS as a proposal. Its note places the new provision in the Phase 4 pilot and Consolidated Rules for 2027 work, expressly separate from RFC-0035 Cryptographic Module Use Rules Updates. That description does not make PQS an effective requirement today.

Start with the proposed scope

Proposed CMU-CSO-PQS uses MUST for providers with 20x Class D certifications to document the post-quantum cryptography status of digital key establishment and digital signatures used to protect federal customer data. Keep both cryptographic uses and the protected-data condition visible in the inventory. RFC-0036, Post-Quantum Cryptography Status

The proposed record would include at least:

• Whether each algorithm is post-quantum cryptography, part of a hybrid implementation with post-quantum cryptography, or neither.
• Its target date for transition to post-quantum cryptography or a hybrid implementation, if available and applicable.

The clause supplies neither a list of approved algorithms nor a named deadline for moving everything. Its three descriptions concern algorithm status, while the date field preserves two conditions: a target is available and a transition target is applicable.

Connect each status to an actual use

As an editorial inventory practice, connect an algorithm entry to the service or component using it, the relevant key-establishment or signature function, and the federal customer data it protects. Add the operational owner and the evidence supporting the status classification.

This working structure helps separate an algorithm name found in a supplier document from evidence about the implementation your offering uses. If the same algorithm appears in several places, retain enough context to understand each use rather than assuming one description answers every deployment question.

For example, a supplier roadmap may describe a future hybrid implementation while the deployed service still has a different configuration. Keep the planned state and observed state distinct. An inventory that silently substitutes the roadmap for the current implementation is difficult to review, even if the supplier's description is accurate about its future plans.

Keep missing information visible

Do not turn uncertainty into the proposal's “neither” category. Missing evidence about an implementation is an open review question; “neither” is a substantive status description. Track the unresolved question and its owner separately while gathering enough support to classify the algorithm.

Apply the same discipline to transition dates. If no target is available, record that gap in your working notes instead of inventing a date to fill the field. If a target is available, preserve its source and the reason it applies to the use being reviewed. These are editorial ways to retain uncertainty, not an added official category or a FedRAMP-approved timeline.

Keep validation and change decisions separate

A post-quantum or hybrid status description does not establish cryptographic module validation. The existing Cryptographic Module Use rules address module and update-stream validation separately; proposed PQS describes algorithm status and transition information.

Keep the relevant validation evidence alongside the status inventory without treating the two as interchangeable. Similarly, a target date does not settle how a planned replacement should be evaluated under the applicable change rules. Use the significant change classification guide for that separate decision, and review the current rules for the actual change.

Before using the inventory in proposal feedback, ask another architect to trace one entry from protected-data use to status evidence and transition rationale. The useful result is a reviewable description of current knowledge and open questions. Recheck the proposal's status before turning that preparation into a claimed FedRAMP obligation.