Dear Agencies: Let’s Make CR26 Work

CR26 modernizes FedRAMP, moving away from Word and Excel.

FedRAMP’s Consolidated Rules for 2026 represent a serious attempt to move federal cloud compliance out of the era of sprawling Word documents, fragile Excel workbooks, monthly file exchanges, and authorization packages that struggle to keep up with today’s modern systems. Federal agencies have a huge opportunity to contribute to the success of that attempt.

CR26 has established structured, machine-readable certification data, publish JSON Schemas, encourage automated retrieval, and retire obsolete templates. However, to reduce the compliance burden, agencies must support the implementation and pivot away from Word documents and Excel spreadsheets. If agencies don’t adopt the new formats, CSPs will be forced to operate two compliance programs simultaneously: one that satisfies FedRAMP CR26, and another that preserves every agency’s preferred version of legacy FedRAMP.

Word and Excel are not compliance databases.

Microsoft Word and Excel are useful products. They are not appropriate authoritative data stores for modern cybersecurity programs. A Word document can describe a security implementation, but it cannot reliably validate whether required information is present, identify conflicting statements across hundreds of pages, automatically update every reference affected by a system change, or tell another application what changed between versions.

An Excel workbook can display vulnerability information, but formulas break, columns drift, identifiers are reformatted, macros fail, filters hide records, and multiple copies inevitably begin circulating. Anyone who has participated in a monthly POA&M review knows the ritual:

Structured information addresses these problems. Required fields can be validated against a schema. Identifiers remain consistent across submissions. Changes can be version controlled. Records can be queried, compared, filtered, transformed, correlated, and reused without requiring a human to copy and paste information into the next template.

There’s also a common misconception that something “machine-readable” makes it “human unreadable”. The machine-readable record does not eliminate human-readable information. JSON can generate a dashboard, table, webpage, PDF, or spreadsheet whenever someone needs one. The critical difference is that the document becomes a view of the authoritative data, not a competing source of truth.

This is consistent with the component-oriented approach stackArmor has advocated for years: compliance information should be modular, reusable, version-controlled, and capable of propagating changes through every affected artifact. Maintaining a 700-page monolith through manual updates virtually guarantees inconsistencies, redundancies, and stale information.

CR26 codifies the FedRAMP PMO’s expectations for agencies.

AGU-AGC-NAR — No Additional Security Requirements — serves as the PMO’s mandate:

Note that clarification in the rule: the agency head or an authorized delegate may determine there is a demonstrable need and notify FedRAMP. This is a fair ask by the PMO. They aren’t saying that an agency can’t request additional information, but they are saying that an agency should come together as a whole and decide what additional information is needed based on their Authorization program. This both allows for iteration on required deliverables, while preventing each individual department head, Information System Security Officer (ISSO) or Security Control Assessor (SCA), from individually requesting information and templates that are a personal preference.

The rule makes clear that ordinary clarification questions about existing FedRAMP certification data are permissible and encouraged. That distinction matters. An agency can (and should) ask a CSP to clarify a vulnerability, explain an implementation, or answer a question about certification data. What the rule seeks to prevent is individuals within an agency having the ability to decide that the CR26 submission is insufficient because a singular internal process still expects a Word document. When FedRAMP requires structured JSON vulnerability reporting, it would be best if agencies avoided:

When FedRAMP accepts machine-readable certification materials, an agency should not require the provider to recreate that information in an agency-specific, legacy Word template that the agency’s reviewers are more comfortable.

If the Word or Excel deliverable is not independently required by FedRAMP, requiring a separately maintained version becomes a request for additional information or materials. Under AGU-AGC-NAR, the request must come from an agency head, via formal notification. The appropriate agency official must determine that there is a demonstrable need and notify FedRAMP.

Modernization is just as critical for agencies as it is for the rest of the FedRAMP ecosystem.

CR26 does not place the entire burden of modernization on Cloud Service Providers (CSPs). Rule AGU-AGC-GRC requires agencies to ensure their internal governance, risk, compliance, and inventory tools can produce and ingest machine-readable artifacts using FedRAMP-identified formats, including mandatory JSON schemas. That is important because it provides a common format in which the ecosystem can thrive.

Without a doubt, these are real operational challenges. But these are modernization opportunities that agencies must seize to keep up with the ever-evolving risk landscape their systems face. Agencies do not necessarily need to replace every GRC platform tomorrow. But they do need to begin treating CR26-native information as authoritative and modernizing their processes around it.

Washington is in full support of this modernization effort.

CR26 did not invent the idea that paperwork-driven compliance slows down real security work. In June 2026, the same administration signed two actions built on exactly that premise for artificial intelligence. National Security Presidential Memorandum 11 (NSPM-11), issued June 5, directs the national security enterprise to accelerate AI adoption because, in the President’s words, agencies had let “undue bureaucracy” hamper the pace of adoption. Three days earlier, Executive Order 14409, Promoting Advanced Artificial Intelligence Innovation and Security, made the same point for civilian agencies and industry.

Neither document mentions FedRAMP. Both describe the same failure mode CR26 is built to fix: process that has calcified around paperwork instead of outcomes. NSPM-11 goes further, directing OMB and the Committee on National Security Systems to govern AI with “maximum consistency” between national-security and civilian oversight, rather than stand up a second, parallel regime. That is the same discipline AGU-AGC-NAR asks of agencies running CR26. Don’t build a shadow process when a structured, authoritative one already exists.

“The right GRC engineers can handle it” misses the point.

Whatever assurances are offered that maintaining both formats is “easy with the right GRC engineers,” translation between CR26 schemas and legacy agency templates is neither free nor harmless. Every translation layer is software.

It requires field mappings, transformation logic, validation rules, exception handling, regression testing, release management, documentation, and ongoing maintenance. When the CR26 schema changes, the translation must be evaluated. When an agency modifies its spreadsheet, the translation must be evaluated again.

Some transformations also require human judgment because the two formats may not describe information in the same way. Someone must decide where information belongs, how it should be summarized, which records should be duplicated, and what happens when one format requires a field the other does not have. Yes, capable engineers can build that system.

Duplicate documentation produces lower-quality documentation.

When a CSP must maintain CR26-native records and a separate agency package, one of three things happens.

None of these outcomes benefits the agency, the security ecosystem, or really anyone at all. Duplicate maintenance divides finite resources. It delays updates. It introduces transcription errors. It creates semantic differences between artifacts supposedly describing the same system. Eventually, teams begin optimizing for submission deadlines rather than maintaining an accurate representation of the cloud service.

The POA&M will be the hardest habit to break.

The most difficult transition will almost certainly be the traditional CSP Plan of Action & Milestones. For years, the FedRAMP POA&M has functioned as the register for vulnerabilities, assessment findings, deviation requests, remediation schedules, accepted risks, and vendor dependencies associated with a cloud service. Agencies have built review boards, dashboards, contract requirements, metrics, and entire monthly processes around that somewhat fragile spreadsheet.

Unfortunately, the concept of open POA&M items becoming a proxy for system risk, despite the obvious problem that a diligent provider may document more findings than a provider with weak detection and reporting capabilities, has become all too common. CR26’s Vulnerability Detection and Response process replaces the traditional vulnerability scanning and POA&M approach.

VER gives agencies more than the POA&M ever did.

Vulnerability Evaluation and Reporting (VER) does not deprive agencies of vulnerability information. It gives them more meaningful, structured, and risk-focused information. Under VER-RPT-VDT, the Vulnerability Detail Report captures eleven required fields for every finding:

Accepted vulnerabilities are separately reported with their reachability, exploitability, current N-rating, justification for acceptance, and information agencies can use to assess or mitigate the resulting risk. That gives agencies the information needed to answer the questions that matter:

• Can the vulnerability be reached?
• Is it likely to be exploited?
• How could exploitation affect federal customers?
• What has the provider already done?
• What reduction in impact comes next?
• What residual risk remains?
• What can the agency do to reduce its own exposure?

VER also requires a consistent human-readable vulnerability activity report at least monthly. For the applicable certification classes, historical vulnerability activity can additionally be made available in JSON for automated retrieval, with update expectations increasing by certification class.

This is not just a FedRAMP idea, either. Executive Order 14409 directs the Treasury Department, the National Security Agency, and CISA to stand up an AI cybersecurity clearinghouse that:

That is a federal vulnerability-management pipeline built on the same logic as VER: continuous, coordinated, machine-driven disposition of vulnerabilities rather than a spreadsheet one reviewer updates by hand. The legacy POA&M moves in the opposite direction from where the rest of the administration’s cybersecurity policy is already headed.

Agencies now have the opportunity to “own” the POA&M.

The deprecation of the CSP vulnerability POA&M creates an opportunity to return the POA&M to its proper purpose. NIST CA-5 (removed from the CSP baselines as part of CR26) describes a POA&M as documenting the organization’s planned remediation actions to correct weaknesses and deficiencies and reduce or eliminate vulnerabilities. The key word is “organization”.

A CSP can report a vulnerability affecting its cloud service. It can explain reachability, exploitability, potential impact, compensating measures, planned remediation, and residual risk. Only the agency can determine what that vulnerability means for its mission, architecture, data, and risk tolerance.

An agency might need to disable an optional integration, restrict a network route, increase monitoring, change how sensitive data is processed, add a compensating control, adjust an operational procedure, obtain explicit risk acceptance, or migrate away from an affected capability. Those are legitimate agency POA&M items.

In fact, CR26 expressly says agencies should use provider-reported vulnerability information to maintain agency security-program POA&Ms when relevant. For example, when the agency takes action to mitigate exploitation risk or continues using a service with accepted vulnerabilities that could put agency systems at risk. That is how the shared-responsibility model should operate:

CR26 is an evolution in modern security authorization.

Agencies should begin accepting CR26-native artifacts as authoritative:

• Accept the JSON
• Use the schemas
• Update agency GRC tools
• Ingest VER data directly into agency risk processes
• Generate human-readable views from the structured source when needed
• Create agency POA&Ms for agency-specific risk responses

And when additional information is genuinely necessary, follow AGU-AGC-NAR: establish the demonstrable need at the appropriate level and have the agency head notify FedRAMP.

What agencies should avoid is supporting an ecosystem where additional Word and Excel packages are treated as routine, unreviewed, and mandatory. CR26 cannot modernize FedRAMP by itself. Schemas cannot create reciprocity if agencies don’t modernize their processes in order to consume them. Structured reporting cannot reduce burden if CSPs must reproduce records in both modern and legacy formats. Deprecating the CSP POA&M accomplishes nothing if every agency immediately resurrects it through contract deliverables.