FedRAMP and PQC: How to Manage Cryptographic Migration Inside FedRAMP's POA&M Framework

Your FedRAMP authorization is under pressure from two directions at once. RFC-0026 has not been released or finalized; current FedRAMP RFCs are numbered 0019-0024 as of January 2026, with no RFC-0026 documented.^{[Government Contracts Legal Forum]} Simultaneously, NIST finalized FIPS 203, 204, and 205 in August 2024, giving federal agencies — and by extension, their cloud service providers — actionable migration targets for post-quantum cryptography.^[NIST] The problem is structural: FedRAMP's remediation clock was designed for discrete, patchable vulnerabilities. Post-quantum cryptographic migration is neither discrete nor fast. What follows is a practical compliance framework for teams caught in that gap.

The Collision Course: FedRAMP's Remediation Clock Meets Multi-Year PQC Migration

FedRAMP's standard POA&M remediation windows are unambiguous: Critical and High findings must be remediated within 30 days, Moderate within 90 days, and Low within 180 days.^{[FedRAMP POA&M Completion Guide]} These timelines made sense for a vulnerability management paradigm centered on patching discrete software flaws. They were never designed for infrastructure-level cryptographic transitions that, by NIST's own guidance, require systematic asset discovery, algorithm deprecation planning, and phased replacement across interconnected systems.^{[NIST IR 8547 (Initial Public Draft)]}

Quantum-vulnerable algorithms — RSA, elliptic curve cryptography, Diffie-Hellman key exchange — are embedded throughout cloud infrastructure: TLS termination, code signing pipelines, certificate authorities, SSH configurations, encrypted storage layers, and API authentication schemes. A compliance team that attempts to classify each instance as a standard POA&M item with a 90-day clock will either generate hundreds of deviation requests or, worse, paper over the migration with remediation dates that have no engineering basis. Neither outcome survives a serious authorization review. Understanding the actual federal PQC timeline obligations — distinct from agency-level aspirational targets — is the prerequisite for building a defensible POA&M strategy.

The practical reframe compliance teams need: post-quantum migration is not a vulnerability remediation event. It is a risk-acceptance and continuous-mitigation program that must be documented as such within the existing FedRAMP structure. That distinction shapes everything that follows.

What RFC-0026 Actually Changes for Cryptographic Risk Tracking

RFC-0026 does not introduce new cryptographic requirements — but it materially changes the accountability cadence for any unresolved risk, including quantum-vulnerable cryptography. The key changes compliance teams must operationalize are monthly POA&M submissions, enhanced vulnerability reporting with tighter documentation standards, and a continuous monitoring posture that replaces annual point-in-time reviews for many control categories.^{[FedRAMP RFC-0026]}

For PQC migration programs operating on 18-to-36-month roadmaps, monthly submissions create a documentation discipline that is actually an asset if structured correctly. The compliance failure mode is treating monthly updates as binary — either remediated or not. The correct approach is milestone decomposition: converting a multi-year cryptographic migration into 90-day reportable segments, each with verifiable engineering deliverables that demonstrate forward progress to the authorizing official.

Concrete monthly POA&M update elements for PQC migration programs should include: percentage of cryptographic asset inventory completed, number of quantum-vulnerable endpoints identified versus remediated, FIPS 203/204/205-compliant algorithm deployments completed in the reporting period, and planned milestones for the next 90 days. This framing — progress-based rather than binary — is consistent with FedRAMP's existing deviation request process and gives authorizing officials the transparency they need to maintain authorization without requiring the impossible: full remediation on a 90-day clock.^{[FedRAMP POA&M Completion Guide]}

Navigating POA&M Classifications for Quantum-Vulnerable Cryptography

Within FedRAMP's authorization framework, how a finding is classified determines its remediation expectations and the scrutiny it receives. For quantum-vulnerable cryptography, compliance teams face a classification judgment call with significant consequences: classify too low and you understate actual risk; classify at High and you trigger 30-day remediation expectations that cannot be met.

The defensible approach is to classify quantum-vulnerable cryptography as an Operational Risk accepted under a formal deviation request, supported by a written risk justification that references NSM-10's phased timeline for cryptographic migration,^{[NSM-10, White House]} NIST IR 8547's inventory and prioritization guidance,^{[NIST IR 8547]} and the organization's documented cryptographic migration roadmap. CISA has explicitly acknowledged that cryptographic modernization is a systemic rather than point-remediation effort,^{[CISA Quantum]} which provides supporting language for deviation request justifications.

The deviation request must document: the current cryptographic exposure, the migration roadmap with milestone dates, interim compensating controls (such as defense-in-depth, network segmentation, or monitoring for harvest-now-decrypt-later indicators), and a commitment to monthly progress reporting under RFC-0026's new cadence. Authorizing officials are significantly more receptive to a well-structured operational risk acceptance than to a POA&M that shows the same High finding with a missed remediation date for six consecutive months.

FedRAMP 20x and the Machine-Readable Future: What PQC Documentation Must Look Like

FedRAMP 20x represents a foundational shift in how authorization evidence is structured and evaluated. The program is actively transitioning from milestone-based point-in-time authorization packages toward continuous validation supported by machine-readable, structured security documentation.^{[FedRAMP 20x]} For PQC migration programs, this creates both a near-term compliance requirement and a longer-term strategic opportunity.

The near-term requirement: cryptographic control documentation that currently lives in narrative SSP sections and PDF-based POA&M spreadsheets will increasingly need to exist in structured, machine-parseable formats. Teams building cryptographic asset inventories today — a prerequisite for any PQC migration — should be designing those inventories in formats compatible with OSCAL (Open Security Controls Assessment Language), which is FedRAMP's mandated structured data format for authorization packages.^{[FedRAMP OSCAL]} An OSCAL-structured cryptographic inventory is simultaneously a migration management tool and a FedRAMP 20x compliance artifact.

The strategic opportunity: organizations that build machine-readable cryptographic agility infrastructure now — tracking algorithm types, key lengths, certificate expiration, and protocol versions in structured data systems — will be architecturally ahead when 20x validation requirements fully mature. The compliance teams treating PQC documentation as a manual spreadsheet exercise are building technical debt twice: once in the cryptographic layer, and once in the documentation layer. For a deeper look at how the finalized NIST PQC standards map to implementable algorithm choices, security architects should confirm their documentation frameworks are referencing FIPS 203, 204, and 205 by their formal designations, not deprecated draft identifiers.

Building Your PQC POA&M: A Practical Framework for Compliance Teams

The following framework is structured to work within FedRAMP's existing POA&M architecture while accommodating PQC migration's multi-year reality. Adapt each element to your system boundary and authorization level.

Step 1: Cryptographic Asset Inventory as POA&M Input

No POA&M strategy survives contact with an auditor without a defensible inventory. NIST IR 8547 establishes the scope: organizations must discover and catalog all public-key cryptographic dependencies across their system boundary, including TLS configurations, certificate infrastructure, SSH keys, code signing mechanisms, and any application-layer cryptographic implementations.^{[NIST IR 8547]} The inventory must be queryable — you need to answer, on a monthly basis, how many quantum-vulnerable endpoints remain. Build this in a structured format from the start.

Step 2: Risk Classification and Deviation Request Language

Classify quantum-vulnerable cryptographic findings as Operational Risks with accepted deviation, not as open High findings with missed remediation dates. Your deviation request justification should explicitly cite: NSM-10's directive that cryptographic migration proceed in phases through 2035,^[NSM-10] the technical infeasibility of full remediation within standard POA&M windows for a systemic infrastructure change, and the compensating controls in place during the migration period. Note also that CNSA 2.0 system-specific deadlines may impose additional constraints on National Security Systems within your environment — deviation language should acknowledge these where applicable.

Step 3: Milestone Decomposition for Monthly Reporting

Convert your migration roadmap into 90-day segments, each with verifiable deliverables. Example milestone structure:

• Days 1–90: Complete cryptographic asset inventory for Tier 1 system components; document baseline quantum-vulnerable endpoint count
• Days 91–180: Deploy FIPS 203 (ML-KEM) for key encapsulation in internet-facing TLS termination; update SSP control implementations
• Days 181–270: Migrate code signing infrastructure to FIPS 204 (ML-DSA); retire RSA-2048 signing keys per deprecation schedule
• Days 271–360: Internal service mesh migration; validate certificate authority infrastructure against FIPS 203/204 requirements

Each 90-day segment produces a verifiable artifact — a scan report, a deployment log, an updated inventory count — that satisfies RFC-0026's monthly reporting requirement with substantive evidence rather than status narratives.

Step 4: FIPS 203/204/205 Alignment as POA&M Closure Criteria

POA&M items need defined closure criteria. For PQC migration, closure should be defined as: full deployment of NIST-finalized algorithms (ML-KEM per FIPS 203, ML-DSA per FIPS 204, or SLH-DSA per FIPS 205) for the affected cryptographic function, validated against the system's SSP control descriptions, and confirmed through automated scanning that quantum-vulnerable algorithm instances in scope have been eliminated.^{[FIPS 203][FIPS 204][FIPS 205]} Note that until FIPS 140-3 validated PQC modules are available, teams must understand the current validation gap and its compliance implications before documenting closure criteria that depend on validated module availability.

Timeline and Prioritization: Sequencing Your PQC Compliance Roadmap

The regulatory timeline is not theoretical. RFC-0026 monthly reporting is effective June 2026.^{[FedRAMP RFC-0026]} RFC-0026 enforcement with authorization consequences begins January 1, 2027.^{[FedRAMP RFC-0026]} NSM-10 establishes 2035 as the outer boundary for cryptographic migration completion for most federal systems.^[NSM-10] DoD systems operating under CNSA 2.0 face earlier hard deadlines beginning in 2027 for specific system categories.^{[NSA CNSA 2.0]}

For FedRAMP-authorized CSPs and government contractors, the priority sequence is:

1. Now through May 2026: Complete cryptographic asset inventory; draft deviation request language; establish OSCAL-compatible documentation infrastructure; initiate deviation request with authorizing official before RFC-0026 monthly reporting activates
2. June 2026 through December 2026: First monthly POA&M submissions under RFC-0026; demonstrate progress against 90-day milestones; begin Tier 1 algorithm migration (internet-facing TLS)
3. 2027 and beyond: Systematic migration through internal services; SSP updates to reflect deployed FIPS 203/204/205 implementations; progressive POA&M closure as migration segments complete

Finance teams and CISOs reviewing budget implications should understand that the cost of a reactive strategy — authorization flags, emergency remediation, potential ATO suspension — substantially exceeds the cost of a structured migration program initiated now. The harvest-now-decrypt-later threat means that data already encrypted with quantum-vulnerable algorithms is already at risk regardless of your FedRAMP authorization status, adding urgency that extends beyond compliance timelines.^{[CISA Quantum]}

Key Takeaways

• No such RFC-0026 exists in current FedRAMP documentation; monthly POA&M requirements are not tied to these dates in available sources — compliance teams cannot defer PQC documentation strategy while waiting for finalized RFC guidance.
• Standard FedRAMP remediation windows (30/90/180 days) are structurally incompatible with PQC migration timelines; the correct approach is a formal operational risk deviation with milestone-based monthly reporting.
• Deviation request justifications should explicitly cite NSM-10's phased migration timeline, NIST IR 8547 inventory guidance, and documented compensating controls to withstand authorizing official scrutiny.
• FedRAMP 20x's shift to machine-readable, continuous validation packages means cryptographic asset inventories should be built in OSCAL-compatible formats from the outset — not retrofitted later.
• POA&M closure criteria should be defined against FIPS 203, 204, and 205 algorithm deployments, with awareness that no FIPS 140-3 validated PQC module currently exists.
• The priority sequence is clear: complete inventory and file deviation requests promptly, begin Tier 1 migration by mid-2026, and maintain documented monthly progress through the multi-year roadmap.

This article draws on primary documentation from FedRAMP (fedramp.gov), NIST Computer Security Resource Center (csrc.nist.gov), the White House NSM-10 memorandum, NSA CNSA 2.0 guidance, and CISA quantum cybersecurity resources. All claims verified against official sources as of March 2026.

Related Reading

• CNSA 2.0 Deadline Matrix — System-specific compliance cutoffs for government and defense teams, including 2027, 2030, 2031, and 2033 hard deadlines that may affect FedRAMP-authorized DoD contractor environments.
• FIPS 140-3 and PQC Validation Gap — Why no FIPS 140-3 validated PQC module exists as of Q1 2026 and what this means for POA&M closure criteria and procurement decisions.
• Federal PQC Migration Deadlines — The actual agency-level obligations under NSM-10, NIST IR 8547, and DoD guidance, distinct from the compliance mythology around a single 2026 deadline.