FedRAMP CR26 and FIPS: What Changed, and the Deadline That's 55 Days Out

If you skim the new FedRAMP Consolidated Rules for 2026 — everyone is calling them CR26 — you'll probably land on the cryptography section and feel a wave of relief. Validated cryptographic modules are now a "MAY" at two of the four Certification Classes. After years of treating FIPS validation as a blanket prerequisite, that looks like a reprieve.

It isn't. Read it that way and you'll build a compliance position that a single agency contracting officer can take apart.

CR26 didn't lower the bar. It moved the bar from "show us a certificate" to "prove, at service and version level, that the thing you deployed is the thing you documented — and keep proving it." For a lot of providers that's more work, not less. And one date on the calendar makes it urgent: September 21, 2026, 55 days from this writing, is when FIPS 140-2 modules stop being usable for new systems.

Here's what actually changed, where the traps are, and what to do about it now.

Worth stating up front: this is an analytical compliance guide, not legal advice and not an authorization decision. A FedRAMP Certification is not an agency ATO, and any agency can impose stricter contractual, technical, or risk-acceptance conditions than what follows.

Key takeaways

  • "FedRAMP authorization" is now "FedRAMP Certification." It's reusable evidence, not a government-wide risk acceptance.
  • Certification Classes A–D are not impact levels. They describe how much assurance you commit to supply — not the FIPS 199 categorization of an agency's system. This is the single most common misread.
  • Validated crypto is MAY at A and B, SHOULD at C, MUST at D — when cryptography protects federal customer data.
  • Documenting your modules is a MUST at every class. There's no permissive tier for the paperwork.
  • September 21, 2026 is a hard deadline. After it, FIPS 140-2 certificates go Historical and are limited to existing systems. CR26 requires active validations at Classes C and D.
  • A FedRAMP "MAY" is not an agency waiver. NIST CMVP guidance still says that when an agency requires information to be cryptographically protected, the cryptography must be validated.

Contents

What CR26 actually changed

CR26 isn't a template refresh. It's a new operating model, and the vocabulary change tells you why.

You used to say CR26 says What it means in practice
FedRAMP authorization FedRAMP Certification Reusable evidence. Not a government-wide ATO, not universal risk acceptance.
Low / Moderate / High offerings Classes A / B / C / D Assurance you supply — not agency system impact.
Base System Security Plan Certification Package Overview Concise overview plus detailed records, in human-readable and JSON form.
Static control narratives Security Decision Record Explain how each rule is addressed, verified, and validated.
Continuous Monitoring Ongoing Certification An operating process, with a report every three months.
Provider POA&Ms Accepted Weaknesses Systematic disposition and transparent reporting, not a monthly artifact.

Two structural changes matter most for crypto teams.

Evidence became structured and perishable. Your Certification Package Overview needs to be machine-validatable against published schemas, and it needs to be fresh enough to support a current decision rather than a historical snapshot. For 20x, maintenance cadence scales with class: Class A at least every 3 months (SHOULD), B monthly, C every two weeks, D weekly (all MUST). FedRAMP's expectation is that you automate this as changes occur — not that a human rereads the package weekly.

"Vulnerability" got much broader. CR26's definition covers architecture review, testing, threat intelligence, supply-chain monitoring, bug bounty findings, and — this is the important one — documentation drift. An outdated rule statement is itself a vulnerability, because it misrepresents the certified system.

Applied to cryptography, all of these are now reportable weaknesses:

  • a deployed library version that no longer matches your package
  • a CMVP certificate moving from Active to Historical or Revoked
  • an approved mode getting disabled
  • a cloud provider silently changing the module underneath you
  • a certificate that doesn't cover your deployed operating environment
  • a tenant default that allows a nonvalidated path
  • an update-stream release that introduced a material cryptographic change
  • inaccurate public claims about your FIPS validation

That last one deserves emphasis. Under CR26, your marketing page is in scope.

Certification Classes are not impact levels

If you take one thing from this post, take this.

A Certification Class describes the assurance you commit to make available: depth of evidence, update frequency, independent assessment expectations, ongoing transparency. Agencies still categorize their own systems under FIPS 199 and FIPS 200. The two are separate axes.

So:

  • A Class A or B service is not automatically "Low impact."
  • A Class C or D service is not automatically "Moderate" or "High."
  • A lower-class service can be used in a higher-impact architecture, if the agency has acceptable risk treatment, compensating controls, and enough evidence.
  • The agency decides whether your cryptographic posture suits its use. Always.

FedRAMP's general orientation:

Class Typical use Assurance implication
A Pilots, testing, public information, negligible-risk use Lowest commitment; an accessible entry point for mature commercial offerings.
B Lower-risk production, some higher-impact use with agency compensating controls More than A, but several advanced expectations stay optional.
C Most Low and Moderate use, some High with compensating controls Stronger, more frequent evidence. Many expectations become MUST; validated crypto is SHOULD.
D Broad agency use, including high-assurance scenarios Highest commitment. Validated crypto becomes a MUST.

Also worth knowing: FedRAMP 20x is the forward path. It went widely available in June 2026, it's built for services that can demonstrate security through machine-readable evidence, and you generally don't need an agency sponsor for the 20x Program path. Rev5 stays available during transition — particularly for provider-operated infrastructure, existing sponsored efforts, and Class D until 20x Class D is generally available — but FedRAMP stops accepting new Rev5 Certification applications on June 11, 2027.

The three cryptographic rules, in plain English

CMU-CSO-CMD — document your modules (MUST, every class)

Where cryptographic services protect federal customer data, you must document the modules used by each service or group of services sharing the same modules, including whether each module is CMVP-validated or is an update stream of a validated module.

Note what this rule is not asking for. "AES-256," "TLS 1.2," and your cloud product name are algorithms, protocols, and products. None of them is a validated cryptographic module.

A defensible record identifies the service group, crypto use case, data and security objective, module vendor and name, version or build, FIPS standard and certificate number, certificate status, covered operating environment, approved-mode configuration, whether implementation is direct/inherited/customer-controlled, update-stream lineage, the agency tenant default, evidence source and owner, and the date last verified.

That's fifteen fields. If your current answer is a spreadsheet column that says "yes," you have work to do.

CMU-CSO-UVM — use validated modules (class-dependent)

When cryptographic services protect federal customer data:

Class Rule How to read it
A MAY use modules or update streams with active CMVP validations Not a class prerequisite — but an agency or another control may still require them.
B MAY Same caution. Certification flexibility ≠ agency acceptance.
C SHOULD Validated crypto is the expected implementation. A deviation needs a strong documented rationale, surfaced to relying agencies.
D MUST A direct requirement. A nonqualifying implementation is a compliance gap, not a risk exception.

The load-bearing word is active. A certificate number is not a status. You need to know whether it's Active, Historical, Revoked, or otherwise constrained — and you need to know that continuously, not at assessment time.

CMU-CSO-CAT — default your agency tenants correctly (SHOULD)

You should configure agency tenants by default to use cryptographic services backed by modules — or update streams of modules — with active CMVP validations, where available.

This quietly changes the question from "can the product support FIPS?" to a much harder set:

  • Is the federal tenant actually created in that configuration?
  • Is it inherited automatically, or does it depend on customer action?
  • Can an admin turn it off by accident?
  • Do your APIs, agents, CLIs, private endpoints, and service meshes follow the same default?
  • Are failover and DR paths equivalent?
  • Are non-FIPS endpoints clearly separated and disclosed?
  • Is any of this continuously tested?

If you offer a FIPS-capable endpoint but leave the ordinary nonvalidated endpoint as the default, you will have a hard time arguing you addressed this rule.

The trap: a FedRAMP "MAY" is not an agency waiver

CR26's transition guidance says FIPS 140 encryption is expected for sensitive data, and that not all federal customer data or metadata should be assumed sensitive. That's a genuine, meaningful reduction from the old blanket presumption.

But it only works if you keep three questions separate.

1. Must this data or operation be cryptographically protected at all?

That answer comes from FIPS 199/200 categorization, an SP 800-53 control, law, regulation, contract, agency policy, your threat model, the agency's architecture, data-type-specific rules, or an inherited shared-responsibility requirement. CR26 lets you explain why cryptography isn't necessary for a given layer. It doesn't eliminate the underlying protection requirement.

2. If cryptography is used, what does my class require?

The UVM matrix above. A/B MAY, C SHOULD, D MUST.

3. What will the agency accept for its ATO?

Entirely their call. NIST CMVP is unambiguous: when a federal agency specifies that information must be cryptographically protected, FIPS 140 validation applies. So:

  • an A or B Certification is not a waiver of federal cryptographic policy
  • a C deviation from "SHOULD" may still be unacceptable to your customer
  • an agency may contractually require active FIPS 140-3 modules regardless of class
  • an agency may require a specific approved mode, certificate, algorithm, key size, endpoint, or HSM deployment
  • specific Rev5 controls independently require validated technology — SC-13 points at the CMU rules; SC-12(2) retains FIPS-validated or NSA-approved key management; SA-4(7) can require FIPS validation where no NIAP protection profile exists

The rule that resolves all of this: apply the most specific binding requirement. A class-level "MAY" never overrides a control, contract, or agency condition that says MUST.

Practical strategy: treat the class rule as your minimum FedRAMP certification position, and design your federal service configuration to satisfy the likely agency position.

September 21, 2026: the FIPS 140-2 cliff

Here's where CR26's language collides with NIST's calendar.

NIST accepts FIPS 140-3 validations onto the Active list for five years (two for Interim Validations). FIPS 140-2 modules may be used for new systems only through September 21, 2026. After that, those certificates move to the Historical list and are limited to existing systems.

Now re-read CMU-CSO-UVM. It says active validations.

At Class D, a FIPS 140-2 certificate that goes Historical on September 22 is no longer active. Absent additional transition treatment from FedRAMP, relying on it wouldn't satisfy the plain text of the rule for new or changed Class D implementations.

At Class C, the same lifecycle problem hits the "SHOULD." If you keep relying on a newly historical certificate, be ready to explain why no FIPS 140-3 replacement exists, whether your deployed version is an update stream of an actively validated module, your migration date, compensating controls, algorithm posture, customer impact, and how you documented the decision in your Security Decision Record.

At Classes A and B, the rule is permissive — but agencies can still reject an old module for a new system. Don't market a Historical FIPS 140-2 module as equivalent to an active FIPS 140-3 validation.

What to have done by September 21

  1. Identify every reliance on a FIPS 140-2 certificate.
  2. Determine whether each use is a new or existing system under agency policy.
  3. Identify an active FIPS 140-3 certificate or a credible vendor roadmap.
  4. Confirm the target certificate covers your deployed operating environment.
  5. Test approved mode and interoperability.
  6. Document any update-stream relationship.
  7. Update tenant defaults and customer guidance.
  8. Plan the package and public-claim changes.
  9. Notify agencies of material migration risk.
  10. Build a contingency for certificates that go Historical, get Revoked, or slip.

Note that the CR26 crypto rules carry their own grace dates — for 20x, the first independent assessment begun after January 1, 2027; for Rev5, June 1, 2027. Don't read a grace date as permission to delay discovery. Your inventory, migration plan, evidence model, and customer configuration model should exist before the maintain date.

Update streams: flexibility with an evidence burden

CR26 expressly permits an update stream of a module with an active validation. This carries forward a genuinely good idea from FedRAMP's January 2025 cryptographic policy: holding vulnerable software back purely to stay on a directly validated build can create more risk than patching it. When validation currency and vulnerability remediation conflict, FedRAMP generally prefers eliminating known vulnerabilities.

What CR26 did not do is make every descendant of a validated product automatically acceptable. A defensible update-stream claim shows:

  1. Base validation — the exact active certificate and validated module the stream derives from
  2. Lineage — version and build ancestry from validated module to deployed release
  3. Change analysis — whether boundaries, algorithms, entropy sources, self-tests, key handling, interfaces, or approved-mode behavior changed
  4. Operating environment — whether your platform is still covered or equivalent
  5. Vulnerability rationale — why the updated build has a better risk posture than the validated branch
  6. Vendor evidence — release notes, assurance statements, CMVP status, roadmap, support commitments
  7. Configuration evidence — proof the federal deployment still uses the intended approved functions and mode
  8. Continuous monitoring — detection of version drift and certificate-status change
  9. Agency transparency — clear disclosure that you're running an update stream, not the exact validated version
  10. Independent assessment — testing sufficient to substantiate the lineage and configuration

Stop using fips=true

A single boolean collapses materially different conditions into one misleading label. Use a controlled status instead:

direct-active-validation
update-stream-of-active-validation
historical-validation-existing-use
validation-in-process
nonvalidated-with-documented-rationale
not-applicable-no-required-protection
inherited-pending-evidence
revoked-or-nonacceptable

Those last two are the ones that save you. "Inherited, pending evidence" is an honest state that a boolean has no way to express — and it's exactly the state most cloud-dependent services are actually in.

Inherited crypto is not out of scope

Modern services inherit cryptography from load balancers, API gateways, managed databases and storage, KMS and HSM services, CDNs, identity providers, service meshes, container runtimes, host operating systems, and third-party APIs.

CR26 requires you to identify third-party information resources in assessment scope and document modules by service or service group. So "inherited" is not a synonym for "out of scope." For each inherited cryptographic service, keep: the upstream Marketplace identifier, the exact service and feature, the module or certificate evidence the upstream provider supplies, required region/endpoint/policy configuration, customer responsibilities, whether FIPS mode is automatic or selectable, who monitors certificate status, evidence your own tenant is configured right, fallback behavior when the FIPS endpoint or HSM is unavailable, and change-notification terms.

And avoid claiming an entire infrastructure platform is "FIPS validated." CMVP validates a defined module in specified operating environments and configurations — not a cloud product, an application, or a supply chain.

Dates for your calendar

Date Milestone
July 4, 2026 Optional early adoption opens; some 20x rules have an immediate obtain date
July 6, 2026 Initial Implementation Marketplace listings open
July 28, 2026 FedRAMP Ready becomes legacy — no new Ready submissions; providers directed to 20x Class A
August 3, 2026 20x Class A pipeline opens
August 10, 2026 Limited temporary Rev5 Class B/C paths open (Ready Conversion, Lost Sponsor)
August 31, 2026 20x Class B and C pipelines open
September 21, 2026 FIPS 140-2 no longer usable for new systems; certificates go Historical
January 1, 2027 CR26 mandatory adoption; crypto rules' maintain date
June 11, 2027 Last day to apply for a new Rev5 Certification

A seven-priority action plan

1. Establish governance and applicability. Pick your Certification Type, Path, and Class. Map each applicable ruleset to its obtain, maintain, and grace dates. Confirm agency-specific FIPS and control requirements. Assign named owners for crypto architecture, inventory, CMVP status, customer configuration, and evidence.

2. Build a service-level cryptographic inventory. For every in-scope service and information flow: where crypto is used, what federal data or function it protects, whether protection is required or defense-in-depth, the actual module and deployed version, the certificate and its status and operating environment and mode, whether it's direct/inherited/customer-controlled, update-stream lineage, tenant defaults, and customer responsibilities.

3. Resolve FIPS 140-2 dependencies. See the ten-step list above. Surface material risk before September 21.

4. Make federal defaults safe. Default new agency tenants to the validated path. Make drift detectable. Disable or clearly segregate nonvalidated fallbacks. Test alternate endpoints, regions, failover, and DR. Make customer responsibilities explicit and testable.

5. Automate evidence. Generate crypto evidence from engineering sources of truth — SBOMs and CBOMs, package and container registries, cloud configuration inventories, IaC, TLS/SSH scanners, KMS and HSM inventories, dependency management, CMVP status feeds, deployment metadata — not from a compliance spreadsheet. Then update the package at your class cadence in both JSON and human-readable form.

6. Align vulnerability and exception handling. Treat documentation drift as a vulnerability. Record Accepted Weaknesses instead of building legacy POA&Ms. Include crypto changes and accepted risks in quarterly Ongoing Certification Reports. Define escalation triggers for revoked or historical certificates, critical CVEs, and fallback activation.

7. Fix your public claims. Precise language looks like:

"The service uses [module name], validated to FIPS 140-3 under CMVP Certificate #[number], in the listed operating environment and approved mode."

"The deployed version is an update stream derived from the module validated under CMVP Certificate #[number]."

Retire: "FIPS compliant." "The product is FIPS certified" when only a module is validated. Citing an algorithm certificate as though it were a module certificate. Implying a whole cloud platform is validated. Omitting update-stream or customer-configuration qualifications.

Also plan for the meetings: Class C and D providers must host quarterly review sessions, and Class B providers should.

Twelve ways teams get this wrong

  1. Confusing algorithms with modules. An AES or SHA certificate doesn't establish FIPS 140 module validation.
  2. Treating a certificate as timeless. Status changes to Historical or Revoked.
  3. Ignoring the operating environment. A valid certificate may not cover your OS, architecture, hardware, or build.
  4. Documenting the product, not the module. "AWS," "Azure," "OpenSSL," "our HSM service" — not enough.
  5. Assuming support equals use. The product has a FIPS mode; the federal tenant is running something else.
  6. Keeping vulnerable software just to hold a direct certificate. This now conflicts with your vulnerability responsibilities.
  7. Calling every patched version an update stream. The lineage and cryptographic delta have to be substantiated.
  8. Assuming Class A/B means FIPS doesn't matter. Agency policy, contracts, and specific controls say otherwise.
  9. Treating Class C "SHOULD" as optional without explanation. A deviation must be explicit, risk-based, verified, and visible.
  10. Saying "FIPS compliant." NIST expects claims to name the validated module and certificate.
  11. Not updating the package after a release. Stale certification data is a weakness under CR26.
  12. Leaving inherited crypto unowned. You still own understanding the configuration and change risk.

On the assessor side, expect testing well past certificate numbers: whether the documented module is the deployed module, whether the operating environment is covered, whether approved mode is on, whether the claimed use is inside the module boundary, whether nonapproved algorithms get invoked, whether update-stream lineage is credible, whether tenant defaults match the documented posture, and whether public claims are accurate. At Class D, failure to use an active validated module or qualifying update stream is a direct rule failure.

FAQ

Does CR26 mean FIPS validation is no longer required?

No. CR26 replaced a broad presumption with a class- and use-case-based rule. Module documentation remains a MUST at every class, validated crypto is a MUST at Class D and SHOULD at Class C, validated tenant defaults are encouraged everywhere — and agencies remain free to require validated cryptography regardless of your class.

Are Certification Classes the same as Low/Moderate/High?

No, and this is the most consequential misunderstanding in CR26. Classes describe the assurance a provider supplies. FIPS 199/200 impact levels describe an agency's system. A Class B service can serve a higher-impact architecture if the agency accepts the risk with compensating controls.

What happens to my FIPS 140-2 certificate after September 21, 2026?

It moves to the Historical list and is limited to existing systems — it can't back new systems. Because CMU-CSO-UVM requires active validations, this creates a real problem at Classes C and D for new or changed implementations.

Can I run a patched build that isn't itself validated?

Yes, if it qualifies as an update stream of a module with an active validation and you can evidence base validation, lineage, change analysis, operating environment, vulnerability rationale, vendor support, configuration, monitoring, agency disclosure, and independent testing. The permission is real; the evidence burden is the price.

Is inherited cloud cryptography out of scope?

No. You must identify third-party resources in assessment scope and document modules by service group, including certificate evidence from upstream, your own tenant configuration, and the split of responsibility for monitoring certificate status.

Should I pursue 20x or Rev5?

20x is the forward path and generally doesn't need an agency sponsor. Rev5 remains available for provider-operated infrastructure, existing sponsored efforts, and Class D until 20x Class D is generally available — but applications for new Rev5 Certifications close June 11, 2027.

The bottom line

Don't summarize CR26 as "FIPS is no longer required." Summarize it this way:

FedRAMP replaced a broad presumption with a class- and use-case-based certification rule, while preserving mandatory module documentation, encouraging validated tenant defaults, and leaving agencies and specific federal requirements entirely free to demand validated cryptography.

The near-term risks that will actually bite people: reading Classes as impact levels, treating A/B permissive language as an agency waiver, thin justification at Class C, missing the direct Class D requirement, FIPS 140-2 certificates going Historical in September, unsupported update-stream claims, stale inventories, sloppy marketing claims, and untested tenant defaults.

The strategy that handles all of them is the same one: build a continuously maintained cryptographic inventory and evidence pipeline that links services, data, modules, versions, CMVP status, configurations, vulnerabilities, and agency responsibilities. Generate it from engineering systems, not from a spreadsheet someone updates before an assessment.

That's more work than a one-time FIPS checkbox. It also produces something the checkbox never did: an answer you can defend at version level, on the day an agency asks.

Start with the September 21 exposure. You have 55 days.

Sources

FedRAMP CR26

NIST CMVP

Rule IDs referenced: CMU-CSO-CMD (module documentation), CMU-CSO-UVM (using validated modules), CMU-CSO-CAT (agency tenant configuration), CPO-CSO-OVR (Certification Package Overview), CPO-CSX-CPM (20x package maintenance), CCM-OCR-AVL (Ongoing Certification Report), VDR-CSO-VDE (vulnerability detection).