RFC-0024 FedRAMP Rev5 Machine-Readable Packages

[pete-gov]

RFC-0024 FedRAMP Rev5 Machine-Readable Packages

❓ Please note that FedRAMP will not answer questions in this thread as it is reserved for public comment. If you would like to ask a question or generally discuss this RFC informally, please use the General discussion / Q&A for RFC-0019 through RFC-0024 thread. Thank you!

Status: Closed
Start Date: January 13, 2026
Closing Date: March 11, 2026

Summary

This RFC proposes modifications to the FedRAMP Rev5 process for current and future Rev5-based assessments and authorizations to ensure that cloud service providers produce machine-readable authorization data that can be ingested by agency tools. This RFC applies only to the FedRAMP Rev5 process and does not apply to FedRAMP 20x.

These modifications include explicit requirements for the production of machine-readable authorization data by FedRAMP Rev5 providers, related timelines, and corrective actions for those who fail to meet these requirements. This RFC also proposes requirements for the structured nature of this required machine-readable authorization data to ensure interoperability between diverse government and industry systems, including the use of OSCAL (Open Security Controls Assessment Language).

Finally, this RFC proposes requirements and timelines for Rev5-based assessments and authorizations to transition, where feasible, from human-written narratives (or machine-generated probabilistic text designed to mimic human-written narratives) to machine-generated deterministic telemetry.

This RFC is aligned with other concurrent RFCs that have additional detail on specific topics but have been published separately to encourage topic-specific comments:

• RFC-0020: FedRAMP Authorization Designations
• RFC-0021: Expanding the FedRAMP Marketplace
• RFC-0023: Rev5 Program Certifications

Background

The history of federal information system security plans charts a fascinating course through the past 50+ years. Laws and policies throughout the 1970s and 1980s established recommendations for maintaining the security of federal information systems that changed rapidly in response to technology and shifting global politics. Momentum for system security plans reached an initial peak when the Office of Management and Budget (OMB) transmitted Appendix III to OMB Circular No. A-130 in 1985. This appendix, titled “Security of Federal Automated Information Systems”, established a “minimum set of controls to be included in Federal automated information systems security programs” and required agency officials to maintain information security programs.

The Computer Security Act of 1987 soon followed, creating the first statutory requirement for all agencies to “establish a plan for the security and privacy of each Federal computer system.” In 1988, OMB Bulletin No. 88-16 responded to the Computer Security Act by directing agencies to prepare security plans for each identified system and submit them to the National Bureau of Standards (which would soon be renamed to NIST) for advice and comment.

NIST completed a review of the resulting government-wide computer security and privacy plans in 1990 and published a report (NIST IR 4409) that found, among many other issues, a lack of consistency and standardization in these plans across government agencies. A key result from this report was that NIST would develop guidance on computer security planning. Notably, this report included the following warning in its conclusion:

“It is unclear whether the plans submitted to NIST and NSA under OMB Bulletin 88-16 were true computer security planning instruments, or only artifacts produced to satisfy an external submission requirement.”

Eventually, in 1998, NIST first published the NIST SP 800-18 Guide for Developing Security Plans for Information Technology Systems. This guide recommended a format for system security plans that improved on the original format from OMB Bulletin No. 88-16 and provided a significant amount of supporting guidance on the creation of system security plans.

In 2016, NIST collaborated with FedRAMP to begin the development of OSCAL, the Open Security Controls Assessment Language, to provide a standardized machine-based representation of these artifacts to encourage a transition from manual human-written documents to materials that included machine-generated deterministic telemetry. Industry is generally quick to adopt capabilities that reduce cost, complexity, and risk but has shown little interest in leveraging OSCAL at scale in spite of its considerable promise. In 2025, FedRAMP processed 100+ Rev5 authorizations without a single submission that used OSCAL; no formal participants in the FedRAMP 20x Phase 1 pilot used it to structure the required machine-readable materials.

Today, at the beginning of 2026, the FedRAMP system security plans used by providers and agencies for the Rev5 process are at best a minor incremental improvement over the template provided in the original SP 800-18. The expectation remains that a human will manually write narrative responses to a series of questions, attaching supporting documents and materials, and justify an implementation for each control in text that is not directly tied to the system itself… and that these materials will all be reviewed manually by a different human.

Definitions

Italicized terms are explained in the Rev5 Balance Improvement Releases Definitions, with the most commonly used terms in this document provided below for quick reference:

• Machine-Readable: Has the meaning from 44 U.S. Code § 3502 (18) which is "the term "machine-readable", when used with respect to data, means data in a format that can be easily processed by a computer without human intervention while ensuring no semantic meaning is lost."

• Authorization Data: The collective information required by FedRAMP for initial and ongoing assessment and authorization of a cloud service offering, including the authorization package.

• Authorization Package: Has meaning from 44 USC § 3607 (b)(8) which is "the essential information that can be used by an agency to determine whether to authorize the operation of an information system or the use of a designated set of common controls for all cloud computing products and services authorized by FedRAMP."

The following terms will be newly explained as follows:

• Machine-Generated: Automatically produced by a computer process, application, or other mechanism without the intervention or manipulation of a human during production.

• Deterministic Telemetry: Verifiable data collected directly from an authoritative source that represents a factual and reproducible observation of the attributes of a system such as the system’s state, configuration, or behavior.

  Note: Probabilistic inferences, generative outputs, or predictive assessments such as those produced using generative transformer models (commonly referred to as “Generative AI”) do not constitute a factual record of the system state and must not be used to generate deterministic telemetry.

• FedRAMP Certification: This is a draft label for FedRAMP Rev5 authorization discussed separately in RFC-0021: Updating the FedRAMP Marketplace.

The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this documentation are to be interpreted as described in IETF RFC 2119.

Motivation

The FedRAMP Authorization Act and OMB Memorandum M-24-15 directed FedRAMP to create a modernized assessment, authorization, and continuous monitoring process for cloud services used by agencies; FedRAMP 20x is being developed from first principles to ensure this process will support native machine-generated deterministic telemetry that is persistently distributed via machine-readable artifacts. FedRAMP is carefully integrating select improvements that have been piloted and tested with 20x into the Rev5 process to balance modernization with stability.

This set of requirements and recommendations, unique to the Rev5 process, are designed to ensure that legacy Rev5 FedRAMP Certified cloud service offerings can produce modern validated authorization data and that agencies can automatically consume this data to make both initial and ongoing authorization decisions.

First, the groundwork will be laid by aggressively transitioning FedRAMP authorization data from traditional word-processor and spreadsheet based submission materials to machine-readable structured information. This will address the “chicken or the egg problem” that has hindered wide-scale adoption of machine-readable structured materials by establishing formal requirements and deadlines for industry adoption of this capability; without industry adoption, there are no machine-readable structured materials for agencies to consume, so the change must begin outside the government even if the machine-readable structured materials are only used to generate traditional documents for agencies at first.

Second, as industry adopts, improves, and innovates with the production of machine-readable structured authorization data, FedRAMP will encourage and reward the integration of machine-generated deterministic telemetry within these materials. Providers following the Rev5 process that incorporate Balance Improvement Releases and build in machine-generated deterministic telemetry will be ranked higher in the Marketplace, receive additional support from FedRAMP such as centralized continuous monitoring, and be more likely to meet updated agency procurement requirements.

These changes will allow the Rev5 process to continue to exist and compete against the new 20x process until the ecosystem is ready to fully transition to 20x.

Summary of Deadlines

This summary is provided only for convenience and is not authoritative; please review the full proposed requirements and recommendations below for authoritative effective dates and specific applicability. In the event of a mismatch between deadlines in this summary and effective dates in the requirements and recommendations below, use the effective date for the specific requirement.

• April 15, 2026: Deadline for FedRAMP to publish materials to support industry adoption of machine-readable authorization packages.
• September 30, 2026: Requirements for adopting machine-readable authorization packages take effect; failure to meet these requirements on the applicable timelines will result in public notification. (Note: This is not a universal deadline as some requirements have additional delays built in, such as “the next annual assessment after September 30, 2026”)
• September 30, 2027: Grace period for adopting machine-readable authorization packages expires and any non-compliant service loses FedRAMP Certification.

---

Proposed Requirements for Rev5 Machine-Readable Packages

After public comment, the final form of these requirements and recommendations will apply to all cloud services obtaining or maintaining a Rev5 FedRAMP Certification based on the final Effective Date(s).

Unless otherwise specified in a specific requirement, the default corrective actions for cloud service providers that fail to address these requirements will be as follows:

1. Initial grace period until 2PM ET on September 30, 2027: Public notification that the provider has failed to meet this requirement and is pending revocation of FedRAMP Certification on September 30, 2027, unless this requirement is addressed.

2. After 2PM ET on September 30, 2027: Revocation of FedRAMP Certification (including revocation of any legacy exceptions based on FedRAMP Certification status), requiring a completely new initial authorization that meets all FedRAMP requirements for new assessments and authorizations at that time.

LMR-FRX-LAM List of Authorization Materials

FedRAMP MUST publish and maintain a list of required information for a Rev5 authorization package, including security controls from the NIST SP 800-53 and FedRAMP-specific assignments and guidance for these controls; once published, FedRAMP will no longer publish or maintain word-processor based templates for these materials.

Note: This will include all standard Rev5 Appendices.

Effective Date: 2PM ET on April 15, 2026 (tentative)

LMR-FRX-LAF List of Approved Formats

FedRAMP MUST publish and maintain a list of approved standardized formats for the submission of machine-readable authorization data. Any approved standardized format that has not been adopted by any cloud service providers within 1 year of its inclusion will be removed from the list. This list will include:

1. Any standardized format in the public domain that 5 or more FedRAMP Certified cloud service providers agree to use and maintain, subject to verification and validation from FedRAMP. Any such alliance may publish their intent, agreement, and the standardized format publicly then notify FedRAMP and the public by announcing this intent in the Rev5 Discussion section of the FedRAMP Community.
2. The NIST Open Security Controls Assessment Language (OSCAL), so long as this project is maintained and responsive to industry input.

Note: There is no need for a single universal standardized format as structured formats are machine-interchangeable; automatically converting between standardized formats has been a normal part of exchanging data between computer systems for 50+ years. Industry is strongly encouraged to create innovative solutions that can compete with or replace OSCAL if that is necessary for the wide-scale production of machine-readable authorization data.

Effective Date: Concurrent with the publication of this document as a formal policy.

LMR-FRX-AMR Accepting Machine Readable-Packages

FedRAMP MUST accept and review new authorization packages submitted in a machine-readable approved format for FedRAMP Certification.

Effective Date: 2PM ET on April 15, 2026 (tentative)

LMR-FRX-PRM Prioritizing Review of Machine-Readable Submissions

FedRAMP MUST prioritize the Certification of new authorization packages submitted in an approved machine-readable format over those that are not; FedRAMP will extend the target final review window from 30 days to 90 days and operate a separate lower-priority pipeline for authorization packages that are not submitted in an approved machine-readable format to ensure machine-readable authorization packages are properly prioritized.

Note: FedRAMP will continue to perform Certification as quickly as possible based on the submission pipeline; packages that are not in an approved machine-readable format are likely to complete final assessment and authorization within 30 days until or unless the submission pipeline is flooded with machine-readable submissions.

Effective Date: 2PM ET on April 15, 2026 (tentative)

LMR-FRX-GPM General Prioritization of Machine-Readable Packages

FedRAMP MUST publicly identify FedRAMP Certified cloud service offerings with machine-readable authorization packages, prioritize their listing in search results, and coordinate additional support for agency adoption of such; this MUST include additional identification, prioritization, and support for services that leverage machine-generated deterministic telemetry or have adopted Rev5 Balance Improvement Releases.

Note: This demonstrates FedRAMP’s strong support for prioritizing and supporting cloud service providers that adopt changing requirements that benefit the federal government and ensures cloud service providers who prioritize security-based improvements to meet changing FedRAMP requirements will benefit from doing so when agencies consider their use.

Effective Date: 2PM ET on April 15, 2026 (tentative)

LMR-GEN-ICR Initial Certification Requirements

Providers MUST submit new authorization packages for initial FedRAMP Certification in an approved machine-readable format.

Notes:

• This requirement does not apply to providers with an active Rev5 FedRAMP Certification (see LMR-GEN-OAR for existing Rev5 Certified cloud services).
• New authorization packages will not be accepted by FedRAMP unless they are in an approved machine-readable format once this rule takes effect; there will be no grace period or exceptions regardless of demand, delay, or other factors. This includes authorization packages that are In Process for Agency Authorization; such authorization packages must be converted into an approved machine-readable format prior to submission to FedRAMP for Certification.
• This is effectively a 9+ month advance warning for cloud services seeking a Rev5-based FedRAMP Certification to transition to a machine-readable format before the final package is submitted to FedRAMP after an agency authorization; this should be sufficient time to acquire or deploy necessary capabilities.

Effective Date: 2PM ET on September 30, 2026 (no grace period)

LMR-GEN-OAR Ongoing Authorization Requirements

Providers MUST submit a full authorization package in an approved machine-readable format for each annual assessment to maintain FedRAMP Certification.

Notes:

• This requirement applies to all cloud service providers with a current Rev5 FedRAMP Certification.
• This requirement applies to the next annual assessment that is completed after the Effective Date.

Effective Date: 2PM ET on September 30, 2026

LMR-GEN-SDS Service-based Data Separation

Providers SHOULD separate the authorization data for services or sets of services when submitting machine-readable authorization packages so that customers are able to easily review authorization data for specific services or sets of services, as appropriate; such separation SHOULD at least align with services or sets of services that are commonly procured separately.

Notes:

• This requirement will result in increased transparency of the services included in a FedRAMP Certification and make per-service customer adoption assets available to agencies and other customers
• Providers are expected to make their own determinations about the appropriate separation of per-service (or sets of services) authorization data and are encouraged to do this programmatically such that customers can pull only the assets they need for the services they plan to use. Implementation of this requirement should be done in consultation with the business branches of the cloud service provider.
• This requirement only applies to cloud service offerings when they next submit a machine-readable authorization package after the effective data; for example, a machine-readable authorization package submitted in August of 2026 will not be impacted by this requirement until they submit a new package as part of their annual assessment in August of 2027, at which point they will have until October 1, 2027 to meet the requirement or lose their FedRAMP Certification.

Effective Date: 2PM ET on September 30, 2026

LMR-GEN-USC Updates after Significant Changes

Providers MUST update their machine-readable authorization package after completing significant changes to accurately reflect the current state of their cloud service by 2PM ET at the end of the following month.

Notes:

• This addresses a significant problem with legacy authorization packages when cloud service providers make significant changes such as adding or integrating additional services in a way that creates confusion for agencies reviewing their authorization package for potential use because these changes are not documented in the primary materials.
• The “end of the following month” is used to simplify setting deadlines; for example, if a significant change is completed on February 12 then the deadline is 2PM on March 31.
• Providers are encouraged to exceed this deadline; where relevant, the average number of days it takes a provider to update their primary materials after making a significant change may be tracked and published by FedRAMP.
• This only applies to providers after they have submitted their first machine-readable authorization package in alignment with other requirements and effective dates in this document.

Effective Date: 2PM ET on September 30, 2026

Corrective Actions: This requirement will be enforced over a rolling 1 year period as follows:

1. First action: Public notification and a 3 month grace period to address the requirement; failure or a new occurrence that is not addressed by the end of the grace period will lead to Strike 2.
2. Second action: Revocation of FedRAMP Certification (including revocation of any legacy exceptions based on FedRAMP Certification status), requiring a completely new initial authorization that meets all FedRAMP requirements for new assessments and authorizations at that time, with a 3 month resubmission penalty.

LMR-GEN-DGI Deterministically Generated Illustrations

Providers SHOULD use machine-generated deterministic telemetry to generate all necessary illustrations and diagrams, including at least the Authorization Boundary Diagram.

Effective Date: 2PM ET on September 30, 2026

Note: The marketplace listing and authorization package for cloud services that do not follow this recommendation will include a warning that illustrations and diagrams are artisanal artifacts and may be unreliable.

LMR-GEN-UDT Use Deterministic Telemetry

Providers SHOULD use machine-generated deterministic telemetry in place of manually or probabilistically generated narratives in authorization data where feasible.

Note: FedRAMP is deliberately leaving this vague and up to the cloud service provider; use of machine-generated deterministic telemetry will be a factor in both initial and ongoing FedRAMP Certification.

Effective Date: 2PM ET on September 30, 2026

LMR-GEN-HRV Human-Readable Versions

Providers MUST also make human-readable versions of all materials in the machine-readable authorization package available in standard formats, such as Word and Excel, if requested by FedRAMP or an agency.

Notes:

• Generation of human-readable versions from structured machine data should be a default capability of any approved format and a relatively trivial task.
• This will be necessary for some period of time as industry and agencies adopt machine-readable formats for Rev5 authorization packages.
• The grace period for this requirement is co-terminus with the grace period for providing a machine-readable package; that is, once a provider begins sharing machine-readable materials then any grace period expires.

Effective Date: 2PM ET on September 30, 2026

[brian-ruf]

Since there is a Background section that addresses FedRAMP's OSCAL history, I want to offer the following additions and corrections.

When did Filming Start?

In 2016, NIST collaborated with FedRAMP to begin the development of OSCAL, the Open Security Controls Assessment Language, ...

• 2018: NIST OSCAL technical team formed and began collaboration with the FedRAMP PMO
• June 2021: OSCAL 1.0.0 was released
• June 2022: First OSCAL-based FedRAMP SSP submitted to FedRAMP PMO
• August 2022: First full OSCAL-based authorization package submitted to FedRAMP PMO

What's Up with the Ratings?

Industry is generally quick to adopt capabilities that reduce cost, complexity, and risk but has shown little interest in leveraging OSCAL at scale in spite of its considerable promise.

Industry showed overwhelming interest in OSCAL from 2018 through 2024 as evidenced by consistently high attendance of NIST and FedRAMP OSCAL events from Agencies, CSPs and GRC tool vendors. The annual NIST OSCAL conference typically filled large auditoriums with participants overwhelmingly focused on FISMA and FedRAMP use cases.

Industry says, "Show Me the Money!"

Most stakeholders - especially CSPs - have been clear for years: A "considerable promise" isn't sufficient for their boards and shareholders.

Short of a mandate, they couldn't justify an investment until the FedRAMP PMO was able to demonstrate:

• a readiness to receive OSCAL; and
• clear benefits to stakeholders for transitioning to OSCAL

(Extra emphasis on the word "demonstrate".)
(Did I mention the key word is "demonstrate"?)

It's Showtime!

A few brave souls took a chance on OSCAL in 2022:

• June 2022: AWS submitted a FedRAMP OSCAL SSP to the PMO generated by Telos Xacta.
• August 2022: DNAnexus and Shellman submitted the first complete FedRAMP OSCAL package generated by DRT Confidence.

At that time the PMO:

• ✅ could validate the submissions for basic OSCAL schema compliance (after considerable effort)
• ❌ couldn't validate it for FedRAMP completeness/compliance
• ❌ couldn't correlate the information across artifacts
• ❌ couldn't use it in a workflow to expedite reviews
• ❌ couldn't offer a single tangible benefit (aside from bragging rights) to these stakeholders
• ❌ couldn't even render it for reviewers to read

Industry's take-a-way:

• ❌ FedRAMP isn't ready yet.
• ⌛ We should wait.

Everybody started to hold their breath waiting for PMO's readiness to improve.
Most passed out years ago.
A few are turning blue, but still hanging in.

FedRAMP Automation: TNG

• In early 2024, GSA leadership took a renewed interest in FedRAMP's OSCAL adoption.
• A new Automation Team was formed within the PMO, determined to make up for lost time.

Cancelled on a Cliff Hanger

• The Automation Team was on track to publish capabilities for validating OSCAL-based FedRAMP SSPs by early February 2025.
• All OSCAL work was paused late January 2025. Related contracts were de-funded. Related government staff were re-assigned or encouraged to take the fork.
• More people passed out from holding their breath.

If we are going to make assertions about industry's interest in OSCAL, we should do so with a more complete accounting of historical events.

[iMichaela]

This is not an endorsement for or against this comment but I would take a moment to clarify for the convenience and awareness of the public why 2016 was chosen for the statement regarding the beginning of collaboration between FedRAMP and NIST (it may be factually inaccurate or confusing either way and further comment clarifying this for the future is always welcome):

2016 was identified in the original draft based on the initial commit by NIST and the NIST blog post The Foundation for Interoperable and Portable Security Automation is Revealed in NIST’s OSCAL Project from 2021 which states:

"Because of this challenge, our NIST team partnered in 2016 with GSA/FedRAMP to research and develop OSCAL..."

CLARIFICATION: Thank you, @pete-gov, for pointing to the source of the timeline you used. Please find below the clarification:

Early engagement with FedRAMP during the late 2016–2017 timeframe focused on feasibility research and developing a deeper understanding of FedRAMP’s requirements. That dialogue resulted in the “OSCAL idea” being taken by two 18F team members who participated in the NIST–FedRAMP meetings and subsequently implemented the competing OpenControls a project in which NIST had no involvement, but which caused significant confusion in the community.

In 2018, I was able to secure a formal FedRAMP partnership through Ashley Mahan, whose leadership was instrumental and deserves renewed recognition. It was critical for the NIST team to work closely with the FedRAMP team detailed to us. Only then did we gain the ability to accurately model the data FedRAMP expected in an authorization package. This marked the inflection point and the true starting timeline for OSCAL’s implementation layer.

[cb-axon]

I agree with all the sentiments here. I don't think OSCAL is ready for this use case, but its more ready than any other schema unfortunately. So this would obviously need to be paired with more development of the schema for the new use cases being required here.

[iMichaela]

I agree with all the sentiments here. I don't think OSCAL is ready for this use case, but its more ready than any other schema unfortunately. So this would obviously need to be paired with more development of the schema for the new use cases being required here.

@cb-axon - What Brian describes in his comment above is not an issue with the OSCAL schema (aka the language itself). Rather, he is highlighting the 2022 state of the toolchain and infrastructure required to consume information that has been digitalized in OSCAL (the OSCAL artifacts packages and submitted to FedRAMP).

If this distinction remains unclear, please feel free to reach out. We are happy to provide clarification on the differences between OSCAL (the language specification), the digital artifacts expressed in OSCAL, and the tooling ecosystem required to ingest that information for the purpose of automating security assessments.

[cb-axon]

Thanks for the clarification. I understand that and agree, tooling is an issue overall, especially for agencies. I'm merely adding to it that not only is tooling an issue, the schema doesn't necessarily support all FedRAMP package needs currently (even as robust as it is). As a CSP, I plan to leverage a commercially available tool to generate the package artifacts that I can in OSCAL. That doesn't help when agencies don't have tools to ingest the package to aide in their review, and default to "human readable" without putting any effort into obtaining or procuring those tools.

[iMichaela]

Thanks for the clarification. I understand that and agree, tooling is an issue overall, especially for agencies. I'm merely adding to it that not only is tooling an issue, the schema doesn't necessarily support all FedRAMP package needs currently (even as robust as it is). As a CSP, I plan to leverage a commercially available tool to generate the package artifacts that I can in OSCAL. That doesn't help when agencies don't have tools to ingest the package to aide in their review, and default to "human readable" without putting any effort into obtaining or procuring those tools.

@cb-axon The OSCAL schemas are designed to provide robust, general-purpose risk management support across multiple regulatory frameworks. While FedRAMP is a primary use case, it is not the only one. By utilizing the OSCAL extension mechanism for FedRAMP-specific requirements or constraints, we maintain a flexible core model.

For CSPs with a global customer base, this is vital: if OSCAL were restricted solely to FedRAMP, you would lose the ability to reuse compliance data for other international standards, making the cost of maintaining authorizations significantly higher.
For example - check out AWS' services in OSCAL component definitions: https://docs.aws.amazon.com/fedramp/latest/userguide/introduction.html. They used 800-53, BUT, with the OSCAL control mapping model released in 1.2.0, this information becomes reusable. Not to mention that 800-53 is the "seed" for many other catalogs (Australia, Canada, Japan..).
Please never hesitate to reach out to our team if you have questions oscal@nist.gov

[brian-ruf]

Grateful for an Edgy Reimagining

On the whole, I am excited that PMO is considering a move to machine-readable packages and welcome the initiative. Please accept the comments below as helping to focus resources and avoid unnecessary challenges as the community moves toward this important goal!

This will address the “chicken or the egg problem” that has hindered wide-scale adoption of machine-readable structured materials by establishing formal requirements and deadlines for industry adoption of this capability;

As I mentioned in the above comment, industry could only justify a voluntary investment in OSCAL after the PMO to demonstrates readiness. Mandating machine-readable deliverables will likely get it done; however, PMO needs to be ready to receive and process this content.

There are a few tools that can start delivering FedRAMP packages to the PMO in OSCAL format immediately. PMO MUST be ready. Industry needs a better experience compared to the 2022 submissions.

57 Channels

Any standardized format in the public domain that 5 or more FedRAMP Certified cloud service providers agree to use and maintain, subject to verification and validation from FedRAMP.

Note: There is no need for a single universal standardized format as structured formats are machine-interchangeable; automatically converting between standardized formats has been a normal part of exchanging data between computer systems for 50+ years.

While I appreciate the spirit of PMO's intention to allow formats other than OSCAL, I'd caution the PMO not to trivialize what it takes to ingest and process multiple, competing formats when the subject matter is complex security information.

For comparison, when the PMO used to accept raw scanner tool output from CSPs, there were ~20 different formats. All very flat with about 15 fields that were relevant to PMO processing and ConMon reporting. It took a dedicated team of 5 FTEs and a bespoke tool to ingest and process.

Security package data is orders of magnitude more complex. Realistically, each new format will require a team of developers several months to adjust tooling. That challenge is compounded if PMO receives several new formats simultaneously during the initial transition period.

Regardless of other formats, there is no doubt OSCAL will be one of the formats PMO has to support. Too many CSPs have invested in it, and for those that need to comply with multiple frameworks, it is the only viable choice.

Perhaps the PMO should prepare to receive OSCAL content first, then use that to better estimate the LOE required to prepare for each new format.

Revising the Script

As one of the co-creators of OSCAL, I'll be the first to acknowledge it isn't perfect. Sometimes the team couldn't agree internally and we went one way or the other. Sometimes we did the best we could in the time we had and in the context of the use cases in front of us.

There are definitely opportunities for improvement. That said, OSCAL is fundamentally viable.
FISMA/FedRAMP use cases are well-exercised in the wild, and the OSCAL Foundation was formed last year as an industry/government partnership dedicated to improving OSCAL and better enabling its adoption.

I'd strongly encourage the PMO to bring any specific concerns it has with OSCAL to the OSCAL community either via a GitHub issue in the NIST OSCAL repo, or by putting it directly on the OSCAL Foundation's radar with an issue in the Foundation repo.

Casting Call

This does a great job of establishing the CSPs role. While the timeframes are for the CSPs to debate, the approach is great!

3PAO's need to be better written into the script given the SAP and SAR are their deliverables.

For example, there is a grace period for existing authorizations, but new authorizations are required to be machine-readable sooner. If the PMO's intention is for new authorizations to only use a 3PAO with the ability to generate a machine-readable SAP and SAR that might be fine. Either be explicit about that expectation or consider setting separat expectations for CSP deliverables vs 3PAO deliverables.

[cb-axon]

I agree with the point that mandating machine-readable deliverables will only work if the PMO is ready to receive and process them. However, I would add that PMO readiness alone is not sufficient. Agency customers must also have the capability and tooling to meaningfully ingest and use this data. The investment cannot sit solely with the PMO or solely with CSPs — it must be government-wide to realize any practical benefit.

On the “57 channels” concern, I agree with the caution against trivializing format interoperability. While the RFC allows for multiple formats, in practice OSCAL is the only currently viable schema that meaningfully captures the depth and structure of FedRAMP packages. XML or JSON alone are not sufficient — the real challenge is agreeing on and maintaining a shared schema. Without that, “machine-readable” becomes nominal rather than interoperable.

For that reason, I believe starting with OSCAL as the primary required format is the right approach. It provides a concrete schema and existing ecosystem investment. Alternative formats can evolve over time, but introducing multiple schemas at the outset risks fragmenting tooling and increasing PMO overhead dramatically.

Longer term, I suspect the future state won’t revolve around file exchange at all, but API-driven interoperability between reporting and governance tools. Until that ecosystem matures, anchoring to a single structured schema like OSCAL is the most pragmatic path forward.

[rgutwein]

I support this initiative to modernize authorization packages. A few observations:

PMO Readiness: The success of this transition depends on FedRAMP's own tooling being ready. Publishing validation tools and acceptance criteria well before April 2026 will help CSPs test their outputs and build confidence in the process.

Multiple Format Support: The provision for alternative formats (LMR-FRX-LAF) is flexible, but maintaining tooling parity across multiple formats will require significant effort. Consider clarifying the approval process and whether there's a practical limit on supported formats.

3PAO Obligations: The RFC focuses on CSP requirements but doesn't explicitly address 3PAO deliverables (SAP/SAR). Clarifying whether 3PAOs must meet the same machine-readable timelines would help avoid bottlenecks.

Significant Change Definition: LMR-GEN-USC requires updates within one month of significant changes. Updated guidance on what qualifies as "significant" in the machine-readable context would help ensure consistent compliance.

Overall, this is a welcome modernization effort. Clear communication and demonstrated PMO readiness will be key to successful adoption.

[cb-axon]

I strongly agree with the point regarding 3PAO obligations — this needs to be made much more explicit in the RFC.

“Authorization data” is ambiguous in practice. Many agencies interpret that to include the SAP and SAR, but those artifacts are produced and owned by the 3PAO, not the CSP. If machine-readable packages are required, the RFC must clearly state whether SAPs and SARs must also be machine-readable and whether that obligation applies directly to 3PAOs.

It would be inappropriate to place revocation or compliance penalties solely on CSPs if their contracted 3PAO does not yet have the tooling or capability to produce machine-readable SAP/SAR outputs. Many CSPs are already under contract for the current assessment year with their 3PAO, with scope, pricing, and deliverable formats defined. Imposing new format requirements mid-cycle could create cost overruns, contract amendments, or delays that are outside the CSP’s control.

If 3PAOs are expected to meet the same machine-readable timelines, that expectation and corresponding enforcement mechanisms must be clearly defined. Otherwise, this creates a bottleneck where CSPs bear risk for deliverables they do not directly control.

[austinsonger]

The Background section should reflect the actual OSCAL timeline and, more importantly, the real adoption story: strong stakeholder interest for years, but limited production adoption because the PMO could not demonstrate end to end intake readiness and tangible benefits CSPs could justify. As @brian-ruf is co-creator of OSCAL so he should know all about the history.

Second, I strongly agree with your caution in “Grateful for an Edgy Reimagining.” The RFC is right to push machine-readable packages, but we should not minimize what it takes for the PMO to ingest, validate, correlate across artifacts, and operationalize this at scale. Your “57 channels” point is exactly the risk. If multiple formats are allowed during the transition, the PMO and agencies will pay for it in duplicated tooling, inconsistent validation, and review friction.

Where I come out more strict is the format question. Even if structured formats are theoretically interchangeable, the government consumption problem is very real. Agencies will not want a world where CSP A submits OSCAL, CSP B submits some alternative, and each agency toolchain has to support both. That becomes an interoperability tax, and it will show up as annoyed agencies and slowed adoption.

My recommendation:

• Mandate one canonical submission format for Rev5 machine-readable packages, ideally OSCAL.
• Allow CSPs to use any internal representation they want, as long as the package submitted to FedRAMP is canonical OSCAL.
• Keep human-readable renderings as derived outputs, as the RFC already proposes.

That approach matches your caution about ingestion complexity while also preventing the fragmentation risk. It also creates the “demonstrate” moment CSPs need: a single target with predictable validation and predictable downstream utility.

On your “Casting Call” point, I also agree the RFC should be clearer on expectations and sequencing across CSPs, 3PAOs, and the PMO. If the PMO cannot validate for FedRAMP completeness and correlate across artifacts, requiring OSCAL will not, by itself, produce better outcomes. The readiness work and the mandate have to land together.

A compromise that still avoids chaos:

• Require one canonical submission format (OSCAL) for all providers.
• Allow providers to use whatever internal representations they want, as long as what they submit to FedRAMP is canonical OSCAL.
• Keep the “human-readable renderings on request” requirement, generated from the canonical package.

This is one of those areas where being less strict up front creates years of headache later. Consistency is the feature here. This feels like Congress passing a bill that’s so vague it invites loopholes and inconsistent interpretation. Same risk here. If FedRAMP leaves the file format open ended, providers will pick whatever is easiest for them, and agencies will be stuck dealing with the fallout. The requirement should be tightened with a single, specific mandated format.

[cb-axon]

I agree that OSCAL should be the initial required canonical submission format. It is the only mature, widely implemented schema today that meaningfully captures the depth of FedRAMP artifacts, and starting with a single canonical target reduces ingestion complexity for the PMO and agencies.

However, I strongly disagree that alternative formats should be permanently disallowed. Leaving the door open for innovation is important. Some of the most impactful open standards (e.g., OpenSSL and other ecosystem-defining projects) emerged from industry collaboration outside of initial government mandates. If multiple CSPs meaningfully collaborate on a schema that improves usability, performance, or interoperability beyond OSCAL, that should not be structurally blocked.

The key is not file format flexibility — it is schema rigor. Any alternative submission schema should be required to:

Cover the full set of required authorization artifacts (SSP, SAP, SAR, POA&M, boundary metadata, etc.).

Be publicly documented and version-controlled.

Include PMO collaboration or requirements alignment to ensure it meets core authorization data expectations.

Demonstrate tooling feasibility for ingestion and validation.

In practice, I suspect most CSPs will continue investing in OSCAL rather than reinventing the wheel. But modernization should not lock the ecosystem into a single permanent representation if better solutions emerge. The right balance is: one canonical required format today (OSCAL), with a structured path for future, schema-complete alternatives that meet defined interoperability criteria.

Heck, the future may not even be structured “files” like we’re talking about with OSCAL today. Many of us see this moving toward API- and webhook-based integrations where tools exchange only the deltas that changed, not entire packages. If we lock too tightly to a single file paradigm, we may unintentionally slow down that evolution.

[C-Cruse-MSI]

5.5 months between: "FedRAMP to publish materials to support industry adoption of machine-readable authorization packages." and this: "Requirements for adopting machine-readable authorization packages take effect; failure to meet these requirements on the applicable timelines will result in public notification." seems extremely tight and will be extraordinarily difficult to implement while meeting the intent of the requirement. Even more so for those with FedRAMP High authorizations where the lack of FedRAMP High authorized SaaS tools in this space leads to additional friction with agencies, and complexity in meeting the actual requirements.

More time should be provided between FedRAMP publishing materials and the adoption requirement takes effect (I understand there are exceptions based on annual assessment windows, etc.).

[cb-axon]

I agree that the proposed timeline is extremely aggressive. Five and a half months between publication of materials and enforcement is not realistic, particularly for High systems where tooling, boundary constraints, and agency friction are more complex.

Rather than forcing near-term compliance with revocation risk, this should initially be optional and tied to a Marketplace designation that differentiates providers who have implemented machine-readable packages. That creates incentive without creating operational instability.

More importantly, adoption should be driven by agency demand. Agencies should first develop or procure tooling that can actually ingest and use these packages, and then require CSP adoption with reasonable notice periods. That ensures industry effort is aligned with demonstrable customer value rather than speculative compliance.
These requirements could be worded like:
Agencies SHOULD adopt tooling capable of ingesting approved machine-readable authorization package formats, including OSCAL, to support automated review and continuous monitoring activities.

Agencies MAY require cloud service providers to submit authorization packages in an approved machine-readable format, provided the agency gives no less than six (6) months’ written notice of this requirement. Providers MUST comply with such a requirement within the specified notice period.

[Karenmeohas-GRC]

It would make a lot of sense to determine the the specific SSP parts that will be mandatory for submission under the new format. There was a short list of Appendix published a while back, but at this CSP needs a clear direction to be able to prioritize. There are already a few platforms/vendors offering this capability and, from a cost/planning perspective, CSPs need to know if this will be a requirement for the SSP as a whole or for parts of it. What about ConMon and POA&M submission?

[acloudcj]

I am a pretty strong supporter of mandating OSCAL as the canonical format, admittedly, even moreso after the release of this RFC. If CSP A submits in JSON, CSP B in YAML, and CSP C in OSCAL, every agency needs tooling that handles all three thereby all but mandating every GRC vendor builds translation layers for every combination. Some GRC tools are already executing here pretty well in regards to current word doc/excel format to OSCAL specifically. One format means one target for everyone instead of multiplying the problem across the CSP ecosystem.

The RFC is clear on what CSPs must produce but I don’t think it touches on an important subject about agency readiness to consume. From my experience, many agencies don't yet have capacity to ingest machine readable data, which risks making this an additive burden. Is FedRAMP actively advising or incentivizing agencies to adopt GRC tools to get ahead of consumption readiness, or is the expectation that changing CSP requirements will naturally pull agencies to the table as more authorized GRCs emerge to facilitate? I would ask you to consider adding language that sets expectations for CSPs on how long dual-format maintenance is anticipated, or establishes milestones for revisiting LMR-GEN-HRV as agency consumption becomes more commonplace.

[stephenbanghart0]

Hi - I'm Stephen Banghart, Technical Coordinator of the OSCAL Foundation. Below is the Foundation's response to RFC-0024:

The OSCAL Foundation appreciates FedRAMP’s continued dedication to working with industry to modernize the FedRAMP Rev5 process. We firmly believe that moving to machine-readable packages will create an ecosystem that is both more secure and more resource efficient for vendors, customers, auditors, and regulators. We applaud the general direction that these RFCs are suggesting and are excited for a future with less spreadsheets and more automation.

The Foundation membership agrees with the general industry sentiment that while flexibility within the package format can be helpful, multiple independent formats can ultimately lead to an increase in burden on agencies, vendors, and FedRAMP itself. Industry standards are born out of a shared desire to express information in an interoperable way, raising the bar for everyone and enabling use cases and workflows that wouldn’t otherwise be possible.

We acknowledge that the OSCAL formats are not perfect – standards rarely are – but that as an industry-led community we are dedicated to evolving OSCAL into the technology that FedRAMP and the wider community needs to accomplish the requirements laid out in these RFCs. To that end, the OSCAL Foundation is committed to addressing industry and FedRAMP feedback to rapidly develop and update OSCAL in the coming months. We hear the FedRAMP PMO’s call to show – not tell, so expect to see relevant materials and OSCAL updates as quickly as is practical.

We welcome all stakeholders to take a renewed look at OSCAL and to join us in shaping the common language for GRC interoperability — for FedRAMP and beyond.

[herrerazabely-boop]

Hi i need customer paymet pendiente
Govermet unted state of america
Thank so much Mosco con estilo oficial

[Cbat001]

Regarding: ""LMR-GEN-DGI Deterministically Generated Illustrations - Providers SHOULD use machine-generated deterministic telemetry to generate all necessary illustrations and diagrams, including at least the Authorization Boundary Diagram."

As a Rev 5 CSP with FedRAMP Moderate complete BoE based currently on all existing FedRAMP rev 5 Templates the conversion of the appropriate sections of the SSP Front Matter template seems to be able to be handled by current and existing OSCAL GRC tooling vendors we are speaking with. I am thinking also that all relevant appendices as well as the Rev 5 Ballance Improvement Releases can be managed via an OSCAL output process. What is NOT available is "use machine-generated deterministic telemetry to generate all necessary illustrations and diagrams, including at least the Authorization Boundary Diagram". From the GRC vendor, their position is for FedRAMP PMO to push this recommendation OUT at least until the vendors can provide a sustainable and readable solution.

I also agree that the timelines are very TIGHT between release of FedRAMP guidance and CSP full adoption. Understand completely the need to stress timelines, etc., just looks like a bit of a squeeze is all.

[kcarr91]

General Comment: Strategic Alignment with FedRAMP 20x

Given that FedRAMP has publicly announced the 20x framework as the modernized path forward with a long-term goal of sunsetting Rev5, I respectfully question whether substantial modifications to Rev5 packages represent the most effective use of CSP resources. Requiring parallel process changes may create duplicative compliance burdens for Cloud Service Providers and divert attention from the security-focused improvements that 20x is designed to deliver.

Assuming Implementation Proceeds: Specific Comments

Comment 1: Request for Phased Implementation via Beta Program

I strongly recommend that FedRAMP establish a formal beta program prior to full implementation of these requirements. Transitioning approximately ~500 CSO to machine-readable packages simultaneously introduces significant risk of widespread implementation issues.

FedRAMP already employs beta programs successfully for Balance Improvement Releases (BiR) involving far more modest process changes. A change of this magnitude warrants, at minimum, a comparable piloting approach. A structured beta period would allow FedRAMP and industry stakeholders to identify and resolve technical challenges, tooling gaps, and process inefficiencies before requiring compliance across the entire CSO population. This approach would strengthen the final implementation and reduce disruption to both providers and agencies.

Comment 2: LMR-FRX-LAF (List of Approved Formats) — Recommend Limiting to OSCAL

I recommend that FedRAMP limit the approved machine-readable format to OSCAL exclusively.

If multiple providers adopt different formats, even with as few as five CSPs per alternative format, GRC vendors will face significant challenges supporting these variations at scale. This fragmentation would increase implementation costs, create integration complexity, and potentially undermine the interoperability goals this RFC seeks to achieve. Given that government and industry have largely converged on OSCAL as the standard for security control automation, formalizing this consensus would provide clarity and reduce ecosystem fragmentation.

While the RFC notes that "automatically converting between standardized formats has been a normal part of exchanging data between computer systems for 50+ years," this theoretical interoperability does not reflect the practical realities of the GRC tooling ecosystem.

Comment 3: LMR-GEN-DGI (Deterministically Generated Illustrations) — Recommend Removal

I recommend removing this requirement. For highly complex CSOs, deterministically generating accurate authorization boundary diagrams and related illustrations that then are human readable is not currently feasible with existing tooling.

Based on a review of the market, there is not quality commercially available software that can reliably produce these artifacts for complex environments (e.g., large multi-service, multi-IaaS). While some tools can technically generate diagrams, the outputs for complex environments are often so large and dense that they become effectively unreadable, defeating the purpose of the illustration. Establishing this as a recommendation, with the consequence that non-compliant packages will carry a warning label indicating diagrams "may be unreliable," effectively penalizes CSPs for limitations in the tooling market rather than for any deficiency in their security posture or documentation practices.

Comment 4: LMR-GEN-UDT (Use Deterministic Telemetry) — Recommend Removal

I recommend removing this requirement. While the intent to reduce manually written narratives is understood, the practical outcome may be counterproductive. In the absence of mature tooling, providers may resort to AI-generated content to produce "deterministic telemetry," resulting in outputs that appear machine-generated but lack genuine evidentiary value.

This concern is particularly relevant given the RFC's own definition explicitly excludes "probabilistic inferences, generative outputs, or predictive assessments such as those produced using generative transformer models." Without clear implementation guidance and available tooling, this requirement risks encouraging exactly the type of content it seeks to prohibit.

Comment 5: LMR-FRX-LAM (List of Authorization Materials) — Recommend Phased Scope

From a Cloud Service Provider perspective (excluding 3PAO-specific documents like the SAP and SAR), I recommend initially limiting the machine-readable format requirement to security controls, the Customer Responsibility Matrix (CRM), and the Control Implementation Summary (CIS) workbook.

These are the materials that benefit most from machine-readable formatting. Security controls are central to continuous monitoring, while the CRM and CIS are essential for agency adoption, helping customers quickly understand inherited controls and shared responsibilities. All other authorization documents could remain in standard Word or PDF formats during the initial phase, allowing providers to focus their efforts where automation delivers the most value.

[sam-aydlette]

RFC-0024 is a significant step toward enabling agencies to automate authorization decisions, and I am very excited about it. To fully realize this goal, the RFC should be strengthened by also addressing semantic standardization alongside format requirements. Machine-readable packages become machine-comparable when they share common identifiers. For example, requiring Package URL (PURL) for component identification, which is supported by both major SBOM formats, would enable consistent inventory comparison across multiple cloud service offerings, supplemented by CPE for commercial products where PURL coverage is limited.
The RFC should also include explicit guidance on vulnerability identification. CVE remains the appropriate primary standard, though there is value in ensuring package formats can accommodate identifier migration if needed. Encouraging Vulnerability Exploitability Exchange (VEX) statements, supported by CycloneDX and SPDX, would help agencies triage on actionable risk.
Finally, cross-package metrics will be most useful if FedRAMP defines what constitutes a "unique" component and a "unique" vulnerability. Does the same CVE found at five different detection dates across fifty components count once, five times, or fifty times? Clear definitions would ensure the aggregate data derived from machine-readable packages supports the consistent, automated analysis this RFC envisions.

[vedigaurav]

Gap #1 – PMO Readiness & Tooling
Issue: The FedRAMP PMO must be fully ready to receive, validate, and process machine-readable packages. Without operational tooling and workflows, mandating machine-readable submissions will not provide tangible benefits to CSPs or agencies.
Recommendation: Ensure PMO publishes validation tools, acceptance criteria, and workflow guidance before the adoption deadline. Establish milestones for testing and readiness verification.

Gap #2 – Implementation Timeline
Issue: The gap between FedRAMP publishing materials and mandatory adoption is extremely short (≈5–6 months). This timeline may be insufficient for CSPs and 3PAOs to adapt tools, convert content, and meet requirements.
Recommendation: Consider phased or beta implementation to give industry time to adapt. Separate timelines for new versus existing authorizations and CSP versus 3PAO submissions would help.

Gap #3 – 3PAO Deliverables
Issue: The RFC focuses on CSP submissions, but 3PAO requirements are not clearly defined, potentially creating bottlenecks in the authorization process.
Recommendation: Clarify 3PAO responsibilities, timelines, and deliverables, particularly for SAP and SAR machine-readable submissions.

Gap #4 – Deterministic Illustrations & Telemetry
Issue: Requirements for deterministically generated illustrations (LMR-GEN-DGI) and telemetry (LMR-GEN-UDT) may not be achievable with current tooling. CSPs could generate outputs that are unreadable or lack evidentiary value.
Recommendation: Postpone or remove these requirements until tools can reliably produce usable outputs, or provide guidance on acceptable methods and limitations.

Gap #5 – Scope of Initial Machine-Readable Submissions
Issue: CSPs need clarity on which parts of the SSP must be converted to machine-readable format. Converting the full SSP and all appendices may be unnecessarily burdensome initially.
Recommendation: Phase adoption to focus initially on security controls, Customer Responsibility Matrix (CRM), and Control Implementation Summary (CIS). Other documents (appendices, POA&M) can follow later.

Gap #6 – Risk of Duplication and GRC Vendor Burden
Issue: Allowing multiple formats introduces a significant interoperability and tooling burden for GRC vendors and agencies. Each additional format may require months of development per format, creating delays and potential errors.
Recommendation: Restrict to a single canonical format initially (OSCAL) and allow internal CSP flexibility. Any alternative formats should require separate approval and defined LOE for ingestion.

Gap #7 – Canonical Format / Format Fragmentation
Issue: The RFC allows multiple machine-readable formats, but in practice, multiple formats significantly increase tooling complexity and agency ingestion burden. Even if technically interchangeable, real-world GRC tooling cannot easily support multiple simultaneous formats at scale. Agencies may face delays, errors, and duplicated effort if CSPs submit different formats.
Recommendation: Mandate one canonical machine-readable format, ideally OSCAL, for all CSP submissions. CSPs can maintain internal representations, but submitted packages must be canonical. Human-readable outputs may be derived from the canonical package. This prevents interoperability issues, reduces tooling burden, and creates a clear target for industry adoption.

[cb-axon]

Gap 1 – I agree PMO readiness is critical, but I would go further: agency readiness is even more important. If agencies lack tooling to ingest and leverage machine-readable packages for ATO and continuous monitoring decisions, then mandating machine-readable submissions provides limited practical value. Adoption needs to be government-wide, not PMO-only.

Gap 2 – I agree the timeline is too compressed. A phased rollout makes more sense, especially if agencies are allowed to require machine-readable formats with reasonable notice (e.g., six months). Adoption should follow demonstrated demand and tooling readiness, not precede it.

Gap 3 – Strongly agree. The RFC must be explicit about 3PAO obligations. SAP and SAR outputs are assessor deliverables, and CSPs should not be penalized for format gaps that are outside their contractual control. Timelines and enforcement must apply appropriately to assessors as well.

Gap 4 – I agree these requirements should either be postponed or clearly positioned as optional and non-punitive. Deterministic illustrations and telemetry should not become a Marketplace differentiator until agencies can meaningfully consume and evaluate that data.

Gap 6 & 7 – I disagree with permanently restricting to a single format. OSCAL should absolutely be the initial canonical requirement, as it is the only mature schema today. However, modernization should not foreclose future innovation. If a consortium of CSPs develops a schema that demonstrably meets FedRAMP requirements and can be ingested consistently, the door should remain open — with clear schema requirements and PMO collaboration. Locking the ecosystem indefinitely to a single representation risks slowing future evolution.

[TBailey223]

Curious to see how the following shake up as this goes into effect:

1. What tools will agencies leverage to process these packages, especially given the likelihood of multiple frameworks for packages?
2. What tools will CSPs leverage to generate packages and how will that decision be influenced by the introduction and standardization of agency-ingest processes/procedures?
3. With Announcing a consolidated FedRAMP Community! #1 in mind, how will the implementation of these standards ensure consistency from one framework to the next?

[TrevorLowing]

Feedback: FedRAMP Rev5 Machine-Readable Packages

Thank you for RFC-0024 modernizing FedRAMP authorization packages to machine-readable format. I support automation and standardization. However, RFC-0024 creates two critical compliance gaps (NARA records management and evidence authenticity) that must be resolved before September 30, 2026 implementation deadline.

---

Summary: Implementation Readiness Assessment

✅ Standardized machine-readable format selection (e.g., OSCAL or any adopted machine-readable format): Supports standardization, interoperability, and automation across federal agencies
✅ Automation benefits: Machine-readable format enables faster, more consistent assessment
⚠️ CRITICAL GAP #1: Evidence authenticity—no cryptographic signature requirement
⚠️ CRITICAL GAP #2: Records retention—no NARA compliance guidance for machine-readable packages

Note: RFC-0024 itself is format-agnostic (machine-readable). OSCAL is the most likely standard and OMB M-24-15 mandates OSCAL by Sept 30, 2026, but RFC-0024 should apply to OSCAL or any adopted machine-readable format.

---

CRITICAL GAP #1: Evidence Authenticity & Records Integrity

The Problem

RFC-0024 requires machine-readable packages as "evidence of federal authorization" (OSCAL is the most likely standard, but guidance should cover OSCAL or any adopted machine-readable format). But OSCAL doesn't include cryptographic protection against modification. This creates liability for federal records management.

Scenario:

Year 1 (Jan 2027): 
  - Agency authorizes CSP using machine-readable assessment package
  - Format file stored in GRC tool
  - File appears to validate all AC-2 (account management) controls

Year 2 (Jan 2029):
  - IG audit: "Show me proof of AC-2 control implementation"
  - GRC tool exports format file
  - Auditor: "How do I know this file hasn't been modified since 2027?"
  - Agency: *silence* (JSON has no signature; tool audit log is only evidence)

Federal Records Challenge:
  - NARA requires that federally-retained records be "authentic and unaltered"
  - JSON file without signature cannot prove integrity
  - Tool audit log is secondary evidence (not primary source)
  - Auditor questions validity of 2-year-old evidence

Why This Matters: NARA Bulletin 2014-02 & Records Management Mandate

NARA Requirement for machine-readable records (NARA Bulletin 2014-02 and NARA General Records Schedule 3.1):

"Agencies must maintain authentic federal records.
Machine records must include provenance (creation, modification history).
If records are altered, agencies must demonstrate integrity.

This is not a security preference—it is a federal records management mandate
under NARA GRS 3.1 (Information Management Records)."

**RFC-0024 Implementation Problem (OSCAL or any adopted machine-readable format)**:
- ✓ **PROVENANCE SATISFIED**: Format provides metadata on who created the assessment, when, and modification history
- ✗ **INTEGRITY GAP (CRITICAL)**: Format does NOT provide cryptographic proof that evidence hasn't been tampered with since creation
- ✗ **VERSION INTEGRITY GAP**: Format does NOT address what happens if tool converts between versions—could alter data in conversion process
- ✓ **Audit logs available**: Tool audit logs can show modifications, but are secondary evidence and not cryptographically binding to the original evidence file

### Critical Distinction: Original vs. Derived Records

**Important Clarification**: This integrity requirement applies specifically to the **machine-readable copy shared in the FedRAMP Marketplace or leveraged by non-sponsoring agencies**, not merely the original ATO documentation retained by the authorizing agency.

**Scenario**:
- **Agency A (Sponsoring Agency)**: Authorizes CSP via full FedRAMP assessment. Agency A retains original SSP, 3PAO assessment report, and ATO memo in its records management system. ✅ Agency A has authoritative originals.
- **OSCAL Copy in Marketplace**: Derived from Agency A's assessment, published by FedRAMP PMO for federal use (OMB M-24-15 mandates OSCAL by Sept 30, 2026, but principle applies to any adopted machine-readable format). This becomes an **official federal record** for:
  - **Agency B (Non-Sponsoring)**: Adopts the same CSP without sponsoring new assessment. Agency B cites the marketplace format file as evidence of compliance. Agency B does NOT have access to Agency A's original SSP.
  - **Agency C, D, E...**: All cite the same marketplace format file as part of their authorization justification.

**Why This Distinction Matters for Integrity Protection**:
If the marketplace format file is tampered with (before or after publication), Agency B has no way to detect it because:
- Agency B doesn't possess Agency A's original SSP (that's Agency A's internal record)
- Agency B's auditor asks: "Show me evidence this CSP meets FedRAMP requirements"
- Agency B presents: "The FedRAMP-published format file assessment"
- Auditor: "How do I know this file hasn't been modified?"
- Agency B: *silence* (without cryptographic signature, no proof of integrity)

**Conclusion**: The **marketplace format file becomes a derived official federal record** that non-sponsoring agencies rely upon for authorization decisions. This shared artifact requires cryptographic integrity protection, even if Agency A retains originals.

---

### Current Gap: No Authenticity Standard Defined

**Question for FedRAMP**: 
How should agencies validate that machine-readable assessment evidence hasn't been tampered with?

**Options**:
1. **Cryptographic signature requirement** (strongest): Machine-readable format packages must be digitally signed by 3PAO (RSA-2048 or stronger) at creation; signature validated annually
2. **Hash-based integrity checking** (moderate): File hash recorded at authorization time; re-checked if evidence is challenged
3. **Tool audit log only** (weakest): Rely on GRC tool's audit log of modifications (subject to tool-specific practices; not standardized)

**Today's Standard (Narrative SSPs)**:
- SSP documents signed by ISSO
- Stored in system with access controls + audit logging
- Auditors accept document as authentic based on signature + access controls

### Recommendation to FedRAMP PMO

**Publish "Machine-Readable Format Evidence Authenticity Standard" (by April 2026)**:

REQUIREMENT: All machine-readable format assessment packages shall be cryptographically
signed at generation time by 3PAO (provider of assessment).

MECHANISM:

1. 3PAO generates format assessment results (JSON or equivalent)
2. 3PAO creates RSA-2048 digital signature of content
3. Signature attached to format file (or stored separately with hash reference)
4. CSP includes signed format file + signature file in authorization package
5. Agency ingests both into GRC tool
6. GRC tool validates signature integrity on annual basis (or when evidence is queried)

BENEFIT:

• Auditor can verify: "Assessment file has valid signature from [3PAO name]; created [date]"
• If file is modified after signature, signature fails (tampering detected)
• Provides NARA-compliant evidence of authenticity

IMPLEMENTATION:

• Require 3PAOs to implement format signing in assessment tools (by June 2026)
• Require GRC vendors to validate format signatures on import (by June 2026)
• Agencies should reject unsigned format packages (policy, not legal requirement)

COST IMPACT:

• 3PAO tool vendors: Minor implementation (standard crypto libs available)
• Agency GRC tools: Minor implementation (standard crypto validation)
• Federal agencies: Zero cost; validation automatic in tool

---

## CRITICAL GAP #2: Records Retention & Evidence Migration

### The Problem

RFC-0024 treats machine-readable packages (e.g., OSCAL) as **federal record** (justification for federal authorization). But doesn't specify:
1. How long agencies must retain OSCAL evidence (3 years? Until system decommissioned? Forever?)
2. What happens if NIST updates OSCAL format (OSCAL 3.0 released; agencies have OSCAL 2.0 packages; must tools support both?)
3. How to migrate OSCAL when GRC tools are replaced

### NARA Compliance Gaps

**NARA General Records Schedule (GRS) 3.1**:

"Information management records (IT policy, security documentation)
shall be retained per agency-specific schedules or default timeline."

**Currently Ambiguous for Machine-Readable Formats**:

Question 1: GRC tool stores format file. If an agency replaces a GRC tool in 2028,
can it export/migrate the file to a new tool?
Answer: Tool vendor-dependent; no standard for portability

Question 2: Format evolves (e.g., NIST releases updated version in 2028).
Must agencies migrate old version to new version?
Answer: Unclear; no format migration guidance from FedRAMP

Question 3: After system decommissioned, how long must an agency keep format evidence?
Answer: No FedRAMP guidance; probably 3–7 years per standard federal retention

### Recommendation to FedRAMP PMO

**Publish "Machine-Readable Format Records Management Guidance" (by April 2026)** (OSCAL or any adopted format):

1. RETENTION TIMELINE:

   □ System Authorization: Retain machine-readable format assessment package for
   duration of system + 7 years after decommissioning (standard federal retention)

   □ Continuous Monitoring Updates: Retain annual POA&M updates
   for duration + 3 years (standard IT records retention)

   □ GRC Tool Migration: Must maintain chain-of-custody (export from
   old tool, validate signatures, import to new tool; document via audit log)

2. FORMAT MIGRATION (If the adopted format version is updated):

   General Guidance: FedRAMP should specify whether agencies are required to migrate
   to new format versions or may retain original versions for backward compatibility.

   FedRAMP Position Options:

   Option A (Conservative):
   "Agencies must maintain format in original version.
   Version migration is not required but permitted if tool supports."
   Benefit: Agencies not forced to re-assess; original format stays valid
   Risk: Multiple format versions in federal systems; tool ecosystem fragmented

   Option B (Progressive):
   "Agencies must migrate to latest format version within 24 months
   of FedRAMP adoption of new version."
   Benefit: Standardization; consistent federal ecosystem
   Risk: Agencies forced to re-validate systems; resource intensive

   Recommendation: OPTION A (conservative) with guidance:
   "GRC vendors should support read/export of both format versions
   for backward compatibility. Agencies may migrate at own pace."

3. GRC TOOL CHANGE & EVIDENCE CONTINUITY:

   Requirement: If agency changes GRC tools, machine-readable format must be migrated
   with documented chain-of-custody:

   Step 1: Export format file from old tool (with metadata, signatures)
   Step 2: Validate format integrity (signature check, schema validation)
   Step 3: Import format file to new tool (creating import audit entry)
   Step 4: Document migration in metadata (tool change date, old tool name)
   Step 5: Retain old tool's audit logs for 3 years (compliance backup)

   Success Criteria: Agencies can auditors demonstrate unbroken chain
   of evidence from original authorization through tool migrations.

---

## Issue #3: Tool Readiness Crisis — June 2026 Is Too Soon

### The Reality

RFC-0024 requires GRC tools support machine-readable formats by **June 2026** (3 months away from Feb 2026). Current reality (OSCAL example):

**Tool Status (Feb 2026)**:
- ✓ Major vendors (Archer, Xacta, CSAM): Announced support for machine-readable formats in roadmap
- ⚠️ Most: Still in development (beta at best); not production-ready
- ❌ Many: No announced timeline; waiting for market clarity
- ❌ Smaller/niche vendors: No support planned

**Probable Outcome**: 
- By June 2026: Maybe 3–5 major vendors ready
- By Sept 2026: 50% of agencies still using non-compliant tools
- Sept 2026 Deadline: Agencies forced to manually convert between formats (defeats purpose)

### Recommendation to FedRAMP PMO

**Extend Tool Readiness Timeline & Provide Workarounds**:

Proposed Timeline Adjustment:

CURRENT (Unrealistic):
April 2026: Guidance published
June 2026: Tools must support adopted format (3 months from guidance)
Sept 2026: All CSPs submit machine-readable format (no exceptions)

PROPOSED (Realistic):

April 2026: Guidance + format converter tool published by NIST
June 2026: Large vendors target adopted format support (no hard requirement)
Sept 2026: New FedRAMP 20x authorizations MUST use adopted format (per OMB M-24-15 timeline)

⚠️ Rev5 Interim Period (June–Dec 2026):
- CSPs may submit adopted format or legacy format (both accepted)
- Agencies without format-ready tools use NIST-provided converter
- FedRAMP PMO provides format→legacy/legacy→format conversion service (free)

2027 Full Transition: Rev5 legacy format deprecated; adopted format required for all new/renewal authorizations

BENEFIT:

• Gives tool vendors realistic timeline to develop
• Provides federal agencies transition path (converter tool)
• Prevents authorization backlog during tool transition
• Reduces pressure for non-compliant tool implementations

**Fallback Plan (If Tool Readiness Lags)**:
- NIST should publish free open-source **format converter** (legacy SSP ↔ adopted format)
- FedRAMP should operate conversion service (CSPs submit format; FedRAMP converts)
- Agencies should procure FedRAMP vendor's format conversion/validation service

---

## Issue #4: No Standard for Linked Evidence Artifacts (Broken Link Risk)

### The Problem

Machine-readable formats (e.g., OSCAL) allow CSPs to reference evidence artifacts via URLs:
```json
{
  "control-id": "AC-2",
  "evidence": [
    {
      "location": "https://csp.example.com/policies/access-control-policy.pdf",
      "type": "documentation",
      "timestamp": "2025-01-15"
    }
  ]
}

Risk: What if URL is broken?

• CSP moves documentation to new location; doesn't update OSCAL
• Tool attempts to fetch evidence; link is dead
• Assessment appears invalid
• Agencies can't verify control implementation

Recommendation to FedRAMP PMO

Artifact Link Validation Standard:

REQUIREMENT: Machine-readable format packages must pass "artifact accessibility validation" 
before acceptance by FedRAMP.

VALIDATION PROCESS:
  1. 3PAO generates assessment in machine-readable format (includes artifact URLs)
  2. 3PAO submits to FedRAMP with format file
  3. FedRAMP validator attempts to fetch all artifact URLs
  4. If any URL fails: CSP receives list of broken links; must correct
  5. After correction: FedRAMP accepts submission for Marketplace listing
  
  6. Annual validation: FedRAMP re-validates artifact URLs annually 
     (during continuous monitoring). If URLs broken, CSP has 30 days to fix.

COST: Low (same as existing assessment tool validation)
BENEFIT: Ensures evidence artifacts remain accessible throughout authorization lifetime

---

Issue #5: Deterministic Telemetry ≠ Truthful Telemetry

The Problem

RFC-0024 requires "deterministically generated telemetry" (machine-generated, not AI). But deterministic ≠ truthful.

Bad Example:

CSP configures system to export 90 days of access logs.
Logs are "deterministically generated" (real audit data, not AI-generated).
But logs were artificially filtered: records of failed authentication attempts removed.
Telemetry is deterministic but incomplete/misleading.

Assessment result: "All access is properly logged"
Reality: Failed access attempts hidden

Recommendation to FedRAMP PMO

"Telemetry Completeness" Validation Standard:

GUIDANCE: Deterministic telemetry must include:
  ✓ Complete data set (not filtered; not sample)
  ✓ Representative timeframe (not cherry-picked dates)
  ✓ All relevant categories (if access logs, include success + failure)
  ✓ Timestamps and metadata (to verify currency and relevance)

3PAO responsibility: Validate that telemetry is not just deterministic, 
but also complete and representative.

Example validation check:
  Q: "CSP provides user provisioning logs. Are logs complete?"
  A1: "Yes, full Q4 2025 logs (Oct–Dec)" ← Good
  A2: "Yes, sample logs from Q4 2025" ← Bad (sample not complete)
  A3: "Yes, only successful provisioning" ← Bad (incomplete; excludes failed attempts)

This prevents CSPs from technically meeting "deterministic" requirement while omitting inconvenient evidence.

---

Closing

My Position: RFC-0024's machine-readable format is operationally sound and needed. However, three critical gaps must be resolved:

1. Evidence Authenticity (CRITICAL): Require cryptographic signatures on machine-readable packages (RSA-2048; validated annually)
2. Records Management (CRITICAL): Publish NARA compliance guidance for format retention, version migration, tool changes
3. Tool Readiness (HIGH): Extend timeline; provide free NIST converter tool for June–Dec 2026 transition period
4. Artifact Link Validation: Validate all evidence URLs before FedRAMP acceptance
5. Telemetry Completeness: Define standards for deterministic ≠ incomplete/misleading

Recommendation:

• By April 2026: Publish "Machine-Readable Format Evidence Authenticity Standard" + "Records Management Guidance" + tool readiness adjustment
• By June 2026: Provide NIST format converter tool for agencies
• Sept 30, 2026: Per OMB M-24-15 deadline, all new authorizations must use adopted machine-readable format
• 2027+: Full machine-readable format mandate with matured tooling ecosystem

Submitted by: Trevor Lowing (private citizen, personal capacity)
Contact: Trevor.Lowing@gmail.com
Disclaimer: The views expressed are my own.

[cb-axon]

I appreciate the depth of analysis here. I think some of these items go beyond the scope of what RFC-0024 is intended to solve.

On Evidence Authenticity:
You’re correct that OSCAL does not mandate cryptographic signatures, and that is something that the world can eventually focus on. That said, nothing prevents providers or agencies today from applying digital signatures or using storage platforms that enforce immutability. This is not a machine-readable–specific gap — the same integrity question exists today with narrative SSPs and attachments. Before layering in a cryptographic mandate, we should focus on achieving basic machine-readable adoption. Authenticity controls can be addressed separately through storage standards and agency tooling rather than baked into the schema itself.

On Records Retention and NARA:
I do not believe it is FedRAMP’s role to prescribe retention timelines or tool migration procedures to agencies. Agencies already operate under NARA and agency-specific retention policies. FedRAMP does not currently dictate retention durations for SSPs, SARs, or POA&Ms, and this RFC does not change that. Tool migration and chain-of-custody processes are agency governance issues, not FedRAMP standard-setting responsibilities.

On Tool Readiness:
I agree the current timeline is aggressive. My earlier comment stands — this should initially be incentive-based and optional until agencies have tooling capable of ingesting and operationalizing machine-readable packages. Driving compliance before there is demonstrated agency consumption will create churn without value.

On Linked Evidence (Broken URLs):
This is already a risk today in traditional authorization packages. Machine readability neither creates nor uniquely solves that problem. Agencies can and should enforce evidence accessibility requirements contractually. Elevating this into a new FedRAMP-wide validation standard seems premature unless it becomes a demonstrated systemic issue.

On Deterministic Telemetry:
I agree with the premise that deterministic ≠ complete or truthful. However, I disagree with hardening this into new mandatory validation constructs at this stage. Even 3PAO reviews do not guarantee completeness in the way described. Deterministic telemetry remains largely theoretical in practical agency use. It should remain a SHOULD (without marketplace designation) — encouraging innovation — until there are proven demonstrations that it provides measurable security value and can be reliably interpreted by agencies and assessors.

In short, machine-readable packages are the right direction. But we should be careful not to over-engineer solutions for adjacent governance concerns before we have proven that agencies can meaningfully ingest and benefit from the structured data itself.

[CurtisSlone]

@cb-axon I appreciate the thoughtful response, but I want to push back on one point specifically.

The characterization of deterministic telemetry as “largely theoretical in practical agency use” does not reflect the current state of DoD operations. The Security Content Automation Protocol (SCAP) has been in production use across DoD for years, generating deterministic evaluations of endpoint compliance against STIG benchmarks. These are machine-generated, reproducible assessments of system configuration state tied directly to specific security requirements. DISA publishes the benchmarks. Scanners evaluate against them deterministically. The results are structured, machine-readable, and operationally consumed at scale.
That is deterministic telemetry. It exists today. It is not a SHOULD waiting for innovation. It is a proven capability that DoD already relies on for authorization and continuous monitoring decisions.
The gap is not whether deterministic telemetry works. The gap is that FedRAMP has not yet required it, while DoD has been operationalizing it for years. RFC-0024 is an opportunity to close that gap rather than defer it.

I agree with the broader point that we should not over-engineer solutions ahead of adoption. But framing deterministic telemetry as theoretical understates where the federal ecosystem already is and risks anchoring the conversation below the baseline that DoD has already established.

[cb-axon]

I agree that SCAP/STIG scanning and vulnerability scanning represent deterministic telemetry in production use today. That capability is real, mature, and operationally consumed within lots of regulated environments, including existing FedRAMP CSPs.

However, that is not the specific concern I was raising.

Deterministic scan results against a defined benchmark (e.g., STIG compliance, vulnerability posture) or just vulnerability scans are very different from deterministically generating comprehensive architectural illustrations or boundary representations of complex multi-cloud environments. Heck, they're even very different from the KSI deterministic approach which goes far beyond what "scanners" available today can evaluate in systems and custom-developed code.

A STIG scan evaluates a host against a control baseline. It does not:

• Enumerate and model cloud-native service interconnections.
• Accurately represent logical boundaries across IaaS/PaaS/SaaS dependencies.
• Depict shared responsibility splits across managed services.
• Generate meaningful, abstracted illustrations of a minimum assessment scope.

In a traditional endpoint/server environment, deterministic configuration telemetry is relatively straightforward. In a modern multi-cloud architecture leveraging managed services, serverless functions, SaaS integrations, cross-region routing, and layered identity models, the tooling to automatically generate meaningful architectural representations does not currently exist at scale.

That distinction matters.

My concern is specifically around using deterministic illustrations as a Marketplace differentiator. A smaller CSP with a tightly bounded, single-cloud deployment can feasibly build deterministic diagram tooling with modest effort. A hyperscale provider operating across multiple cloud providers, regions, and service layers would require significant engineering investment—potentially millions of dollars and sustained FTE allocation—to build and maintain such capability.

That disparity or function does not correlate directly to security posture.

Deterministic telemetry for certain domains (e.g., vulnerability data, configuration drift, endpoint compliance) absolutely makes sense and is proven, and is already in use today. Extending that expectation to "a complete" architectural boundary diagrams across complex environments is a materially different technical problem.

Until tooling exists that can reliably and meaningfully generate those representations at scale—and agencies can consistently consume and interpret them—I remain cautious about elevating deterministic illustrations beyond a SHOULD, particularly as a Marketplace signal.

The goal should be measurable security value, not theoretical completeness.

[Abe205]

Microsoft Azure Comment:
What is the mapping between the machine‑readable authorization data and the package documents currently submitted by CSPs under Rev. 5, specifically the System Security Plan (SSP), Security Assessment Report (SAR), Security Assessment Plan (SAP), and the POA&M/ConMon spreadsheet? Additionally, are CSPs permitted the flexibility to convert only the SSPs and POA&M spreadsheets they are responsible for producing, while deferring the machine‑readable conversion of the SAP and SAR to the 3PAOs, who are accountable for generating those documents on behalf of CSPs?

Further, does the machine‑readable authorization data requirement apply only to the finalized SSP, SAR, SAP, and POA&M documents delivered after inspection and validation of source evidence, and not to the underlying source evidence itself, under RFC‑0024? Our understanding is that source evidence is out of scope for RFC‑0024. Evidence such as vulnerability scans, configuration screenshots, source‑code screenshots, and log data may be converted to machine‑readable formats when CSPs transition to FedRAMP 20X submissions, but CSPs are not expected to convert source evidence for Rev. 5 submissions.

[jenniferatwiz]

Wiz applauds the move toward "machine-generated deterministic telemetry." We believe true security is based on real-time visibility, not static documents and we offer the following feedback to ensure this requirement modernizes FedRAMP to improve security visibility instead of digitizing bureaucratic compliance:

1. LMR-GEN-UDT Use Deterministic Telemetry
Recommendation: While it makes sense to initially make this a ‘SHOULD,’ Wiz recommends FedRAMP include a phase in plan to require (MUST) machine-generated deterministic telemetry in place of manually or probabilistically generated narratives in authorization data wherever feasible. By maintaining ‘wherever feasible,’ this becomes much more realistic as a requirement.

2. LMR-GEN-DGI Deterministically Generated Illustrations
Recommendation: Wiz believes this policy is premature without further discussion with industry and recommends it be removed. Current automated technologies are not tailored to FedRAMP organizations alone. Without significant engineering changes catering solely to FedRAMP interested entities, current technologies would in many instances provide inaccurate information–or even potentially misleading or sensitive information on adjacent environments outside the FedRAMP boundary.

3. Access to Near-Real Time Evidence: While we understand many platforms will take time to move away from point-in-time evidence, we suggest FedRAMP add a path to incentivize more real-time data access over static snapshots.
Recommendation: The final guidance should explicitly allow read-only access to a provider’s security data to satisfy "machine-readable" requirements. If an agency can query a provider’s security data in near real-time via API, they should not also be required to generate a static machine readable file.

4. Commercial Standards
Recommendation: We ask the PMO to work with cybersecurity providers to certify widely adopted commercial JSON schemas used by modern CNAPP/CSPM tools. We appreciate the recognition by FedRAMP that OSCAL is one of many options, and often a conversion to OSCAL adds engineering overhead without improving security visibility or functionality.

5. Timelines for Platforms
Recommendation: For established platforms with large FedRAMP High boundaries, the September 2026 deadline is aggressive. We suggest a phased approach: require machine-readable formats for ConMon deliverables first, as this provides the highest immediate value to agencies, before requiring the full System Security Plan conversion.

[cpelote]

We support the long-term modernization goals behind machine-readable authorization packages and agree that structured security data can improve automation, consistency, and reuse across the FedRAMP ecosystem.

However, we have significant concerns regarding standard definition clarity and implementation feasibility under the proposed timeline.

The RFC strongly implies that OSCAL will be the required machine-readable format, yet it stops short of explicitly identifying OSCAL—or any specific format—as the definitive standard. This creates more than simple ambiguity. It places CSPs in the position of preparing for compliance without a clearly defined technical requirement.

If OSCAL is the intended standard, it should be explicitly stated. If alternative formats are envisioned, those formats and their conformance criteria must be defined by the PMO. Establishing technical standards is appropriately the responsibility of the governing authority—not of individual CSPs attempting to interpret policy intent or anticipate future expectations. Without clear ownership of the standard, the burden of determining “what qualifies” appears to shift to industry, introducing unnecessary risk, inconsistency, and cost.

Additionally, the current tooling ecosystem does not appear sufficiently mature to support mandatory adoption within the proposed timeframe. Available options (assumed as OSCAL) largely consist of open-source tools requiring substantial technical expertise to operationalize, or full GRC platform replacements that would require material cost and operational disruption. For many CSPs—particularly small and mid-sized providers—the compressed implementation window effectively creates a forced tooling transition before the ecosystem is ready.

Modernization efforts of this scale warrant both definitive technical standards and a phased, ecosystem-aware transition plan. To support successful adoption, we respectfully recommend:

• Explicitly identifying the required machine-readable standard(s) and publishing definitive conformance criteria
• Releasing detailed artifact and submission requirements well in advance of enforcement
• Implementing a phased adoption model prior to full mandate
• Extending the compliance timeline to allow tooling and vendor ecosystem maturation

We support the direction of automation and welcome continued collaboration. Clear standards and a realistic transition framework will ensure this initiative strengthens—rather than strains—the FedRAMP marketplace.

[OG-of-the-realms]

LMR-GEN-SDS
Recommendation: Change requirement to "MAY" instead of "SHOULD" - heavily based on a CSP's circumstances and operating model.

Rationale: As one of the few Cloud Service Providers that previously operated multiple Authorization Packages for distinct and specific services, we have moved towards consolidating our Authorization Packages - both within FedRAMP and DISA. This was driven by a number of factors:

1. Agency Customer feedback, we received consistent and clear feedback from our US Federal Agency Customers that were consuming multiple SaaS products, that having to leverage multiple Authorization Packages was overly burdensome for their AO Representative and Validation staff, drove frequent confusion (despite public facing documentation) and clarification calls.

2. Excessive costs, as our program matured and additional services onboarded, we were conducting five plus annual assessments for each distinct authorization package. We were facing the need to add additional new distinct services on a quarterly basis, at a volume and velocity that would be unsustainable under the previous Rev5 program for both FedRAMP PMO, Agency Partner, and CSP resources. Consolidating to a single boundary with uniform controls, allowed for the use of a streamlined SCR process.

3. Depending on how you define "specific services or sets of services" we have between 10 and 1000 SaaS services; but from a control, architecture, and customer perspective - the majority of the controls are identical, with a handful of controls or customer requirements that only have at most two or three variances of an implementation.

Requiring distinct Service-based Data Separation would result in an administrative burden to generate dozens to hundreds of authorization data sets that are effectively 99.999% identical.

An alternative requirement to achieve a similar intent, would be to require CSPs that do not implement LMR-GEN-SDS because of the above rationale, to clearly identify their CRM specific service based differentials within their Secure Configuration Guides.

[wisecryptic]

+1 on this feedback.

A key line in this section is: “Providers are expected to make their own determinations about the appropriate separation of per-service authorization data.” That creates a useful foundation, but if implemented poorly it could greatly expand documentation and review burden.

We can contextualize impacted groups into 4 broad (read: overgeneralized) categories.
1. Hyperscalers.
Oriented almost completely around offering many separate services. These services are wide ranging and can be highly similar or completely separate to the point of not even being in the main platform (edge computing, transport services etc.). In this case, breaking out services and properly structuring the documentation, security, and assessment as well as sharing information with agencies make a lot of sense IF structured correctly. The separations could get complicated and require a robust data model or it turns to documentation spaghetti fast.

2. Middle players
These companies often have a broad set of offerings, sometimes across different platforms, especially after acquisitions. Their “services” may be anything from marketing labels on features to genuinely distinct backend architectures. A clear framework is needed upfront, but once true service boundaries are defined, managing shared vs. unique security elements is comparatively straightforward.

3. Single‑Platform, Multi‑Feature Providers
Typically smaller companies built on a common technology stack. They should maintain a single service package, even when marketing multiple features.

4. The smaller niche offerings.
Most straightforward. One product. One platform. One offering. One package. Zero nuance. (a little nuance but not much)

If a company uses a uniform security model, but breaks out multiple services that have virtually identical security posture/protections, they will make a terrible mistake by multiplying a single security model over many duplicate documentation packages. Because agencies need to authorize by service offering, and each package is separate, it virtually forces agencies to review different packages with the same information, one for each service.

It is worth considering this carefully in its own right as it requires some complex work by CSPs to be effectively implemented. If moving forward with this, csps should clearly understand what is a truly different 'service' (in terms of security/compliance), and then create a data model that reflects the shared or unique nature of security controls.

• Hyperscalers have a strong grasp of their service differentiations. They will need to create a complex data model that 'shares' common documentation components while calling out the unique ones for each level (e.g. org, platform, service)
• Middle players should focus carefully on what is actually a different 'service', then follow the same pattern, albeit a much simplified one that focuses on calling out novelty more than efficient governance of shared components, as the hyperscalers
• The single platform, many offerings players should follow the same pattern in analysis (Again, more simplified than before) as the middle players, but should resist, in both technical matter and documentation, as much as possible breaking out separate services. The reason for this is that there is much more that is the same than is different so creating a whole new separated package comes at a cost and complexity to agency and CSP alike.
• The niche offerings don't need to think much about this until they expand.

[JustAnotherCyberExpert]

LMR-GEN-SDS

As companies mature their products, they typically move toward a more modular model—consolidating controls, frameworks, and architecture into reusable components that can be shared across product lines. In that context, requiring multiple separate packages to support products that are the same (or materially the same) runs counter to modernization goals. It increases duplication, creates unnecessary operational overhead, and makes it harder to maintain consistency over time.

A more forward-looking approach would treat separate packages as an option, not a default mandate. In other words, this should be framed as a “may” depending on the company’s use case—such as when there are meaningful differences in risk profile, deployment model, regulatory scope, customer commitments, or lifecycle ownership. But applying a blanket requirement across the board can force organizations to fragment what they have intentionally designed to be shared and modular. The result is often a significant step backward: more complexity, slower delivery, higher maintenance costs, and increased potential for drift between implementations that should remain aligned.

Shifting the language from “must” to “may” would preserve flexibility, support modern modular packaging practices, and still allow separation where it is justified by real technical, operational, or compliance needs.

[gregelin]

From: Garoux, LLC, a government contractor building an agentic engineering platform. We are pursuing compliance with FedRAMP High and Impact Level 4/5 for our Phase II SBIR with the USAF and other projects. We are leveraging AI and custom tooling to help manage our compliance requirements. This comment also draws on the author's prior experience founding GovReady PBC (acquired by RegScale), serving as CDO at the FCC, and contributing to the OpenControl and OSCAL communities.

What Three Generations of Machine-Readable Compliance Formats Teach Us

Our first comment on FedRAMP RFC-0024 expands the background of machine-readable compliance data to include SCAP and OpenControl, the two formats that preceded and informed OSCAL.

Three successive attempts over 20+ years to make compliance machine-readable have failed to gain the wide-scale adoption needed to keep pace with Agile, DevOps, and Infrastructure-as-Code. SCAP, OpenControl, and OSCAL each advanced the state of the art in significant ways, but each also introduced one or more "cold start" problems that raised the cost of getting started too high to justify broad adoption.

In this comment we summarize the three major machine-readable compliance data projects relevant to FedRAMP and enumerate six cold start problems that machine-readable compliance data formats need to solve.

Generation 1: SCAP (Security Content Automation Protocol)

SCAP, developed beginning in the early-mid 2000s through a collaboration of NIST, MITRE, NSA, DHS, and FIRST, with SCAP 1.0 officially released in 2009, was the first serious attempt to bring machine-readable structure to security compliance data. SCAP enabled deterministic, scanner-based evaluation of operating systems, common software platforms, and configurations. Before SCAP, software configuration verification was largely manual or driven by informal scripts with no standardized baseline. SCAP-validated scanners gave organizations a machine-enforced, repeatable way to confirm that a system was actually configured to a known standard — not just documented as if it were. Red Hat, DISA STIGs, and other major platform vendors produced SCAP content that genuinely automated configuration verification. The SCAP Validation Program created a tested ecosystem of interoperable tools.

But SCAP had two distinct cold start problems that together limited its reach:

Cold start 1 — Authoring cost. Producing SCAP content for a piece of software required coordinating across multiple interlocking XML specifications (XCCDF, OVAL, OCIL, CPE, CCE, ARF), typically generating five separate XML documents knit together via XSLT transformations and specialized toolchains. Authoring SCAP involved panels of subject matter experts spending months agreeing on an authoritative configuration for each software package. The result: SCAP content existed for a narrow set of well-resourced, high-priority targets. Most software was never covered, and benchmarks lagged years behind technology development.

Cold start 2 — Output gap. Even where SCAP worked well, its deterministic telemetry could not flow into authorization artifacts. SCAP produced scanner results. FedRAMP required control implementation statements. These two outputs lived in parallel, disconnected universes. An organization with full SCAP coverage still had to write their RMF SSP and its control implementation statments from scratch. This second cold start problem is critical context for RFC-0024's emphasis on deterministic telemetry (LMR-GEN-UDT): the vision of scanner outputs flowing into authorization packages is not new. It was SCAP's unrealized promise. The question is what will make the pipeline actually get built this time.

Generation 2: OpenControl

OpenControl, launched at All Things Open 2015 by Pivotal in collaboration with 18F, directly addressed SCAP's output gap. Its key insight was correct: map scanner results and human-authored control narratives to a common, component-based YAML format that could generate SSP documentation automatically. The format was simple enough that a developer could start with a single YAML file. The 18F cloud.gov team used it to manage their SSP through GitHub like a codebase.

OpenControl's cultural contribution was perhaps more significant than its technical one. By framing compliance as code (e.g., YAML files in GitHub, CI pipelines, component reuse) it introduced compliance automation to a generation of engineers who had never engaged with it before. That community-building effect seeded the broader compliance-as-code movement that OSCAL and subsequent tools inherited. OpenControl did not just build a format; it built an audience.

OpenControl's cold start problem was different from SCAP's but equally limiting:

Cold start 3 — Ecosystem dependency. The model depended on an ecosystem of reusable component definitions that never materialized. It assumed that AWS, Red Hat, and other platform vendors would publish and maintain OpenControl components describing how their platforms satisfied controls — an npm-like registry of compliance building blocks. The analogy is instructive: npm succeeded because publishing a package was nearly zero-cost. Publishing an OpenControl component required understanding compliance frameworks that vendors had no internal incentive to prioritize. Fewer than 20 controls were ever specified in the AWS OpenControl repository. The vendor participation the model required never arrived at scale.

Timing compounded the problem. OpenControl launched when Terraform and Infrastructure-as-Code were still early — before vendors routinely shipped machine-readable descriptions of their systems alongside their software. The cultural precedent for vendor-contributed compliance components did not yet exist. The most telling evidence: the cloud.gov compliance repository — the originating project's own SSP implementation — was dormant for four years by 2020 and archived. The project that created OpenControl could not sustain its own use of the format.

Generation 3: OSCAL

OSCAL, developed by NIST beginning in 2016 in collaboration with FedRAMP and first released in 2019, has been the most rigorous and well-resourced attempt yet. The effort established something genuinely valuable that prior efforts lacked: a standardized semantic vocabulary for compliance-relevant objects. For the first time, entities like responsible-party, system-component, implemented-requirement, inventory-item, and set-parameter had precise, machine-readable definitions. Before OSCAL, these concepts were buried in free-form SSP prose with no shared structure. OSCAL named them. That vocabulary is a lasting contribution that any successor format should build on, not discard.

OSCAL also attracted real tool development among GRC vendors as a generation of engineers sought to translate their experience in Agile, DevOps, Infrastructure-as-Code, and Containers to automating compliance.

But OSCAL's cold start problem was equally formidable, as RFC-0024 points out: in 2025, FedRAMP processed 100+ Rev5 authorizations without a single submission that used OSCAL. Three compounding factors explain this:

Cold start 4 — All-or-nothing complexity. To produce a single valid OSCAL SSP, an author must first construct a complete, interlocking set of objects: a catalog, a profile resolving that catalog, component definitions, system metadata, and the SSP itself, each cross-referencing the others via UUIDs. There is no valid partial OSCAL. A single control implementation cannot be expressed without the full system context surrounding it. This made OSCAL an all-or-nothing proposition, and most chose nothing.

Cold start 5 — Document-centric architecture. Rather than modeling compliance data as independent, queryable objects, OSCAL faithfully reproduced the RMF paper stack as machine-readable documents: catalog → profile → SSP → SAP → SAR → POA&M. The document remained the organizing unit. To participate in OSCAL, an organization had to understand and implement the entire RMF document lifecycle, not just the data they actually had to contribute.

Cold start 6 — SCAP integration perpetually deferred. The OSCAL community recognized early that SCAP was the natural source of deterministic telemetry that should feed OSCAL's control implementations. This integration was discussed and deferred repeatedly. The pipeline from scanner observation to authorization package was never built into the standard, leaving OSCAL dependent on the same human-written narratives it was designed to replace.

The Lesson for RFC-0024

The progression from SCAP to OpenControl to OSCAL charts a course of each solving important problems while introducing different cold start issues inhibiting adoption. SCAP was too expert-dependent to author. OpenControl was too dependent on voluntary vendor ecosystem contributions. OSCAL was too complex to start without implementing everything at once.

LMR-FRX-LAF. It is our position that RFC-0024 correctly prioritizes rapid adoption over further time investments in determining the correct data standard. Small kindling lights the fire faster than larger logs. The broader history of IT standards bears out the value of smaller, less-featured approaches that ignite participation. HTML was a severely limited subset of SGML. REST prevailed over the richer-featured SOAP. JSON displaced XML as the dominant format for web API data exchange. Simpler formats regularly achieve wider adoption because they are less costly to start using. A compliance data format that is easy to emit, easy to parse, and easy to validate is the best way for us to begin to automate compliance. And the same wisdom and talent that produced the richness of OSCAL over several years will similarly improve a simpler but widely adopted initial standard over several years.

LMR-FRX-LAF. RFC-0024's openness to formats beyond OSCAL, including any format that five or more CSPs agree to use, reflects a healthy recognition that the field is not settled. That provision is sensible.

LMR-FRX-AMR, LMR-GEN-ICR. Given the state of agentic AI coding in 2026, FedRAMP is correct to propose accepting multiple formats (provided each has industry support). Commenters advocating a canonical format or concerned with fragmentation need not worry. Today's agentic AI coding tools can generate reliable parsers and transformers for any well-structured format, dropping the cost of consuming a new format by orders of magnitude and effectively erasing previous time and cost concerns. The real interoperability bottleneck is no longer syntax; it is shared semantics and trustworthy identifiers, which these commenters are correct to advocate.

Our second comment proposes specific characteristics any approved format should demonstrate drawn from these lessons. The goal is to give FedRAMP evaluative criteria that test whether a format can actually achieve adoption, not just whether it can represent the compliance data.

[gregelin]

From: Garoux, LLC, a government contractor building an agentic engineering platform. We are pursuing compliance with FedRAMP High and Impact Level 4/5 for our Phase II SBIR with the USAF and other projects. We are leveraging AI and custom tooling to help manage our compliance requirements. This comment also draws on the author’s prior experience founding GovReady PBC (acquired by RegScale), serving as CDO at the FCC, and contributing to the OpenControl and OSCAL communities.

Ten Principles for Machine-Readable Compliance Data

Our previous comment traced how three iterations of machine-readable compliance data—SCAP, OpenControl, and OSCAL—pushed compliance automation forward but adoption was stymied by "cold start" problems.

LMR-FRX-LAF, LMR-FRX-AMR. This comment presents a draft "10 Principles for Machine-Readable Compliance Data", inspired by the Twelve-Factor App methodology. These principles are a starting point and need community refinement. The goal is to avoid cold start friction and facilitate rapid adoption. It is a set of questions that any proposed format for RFC-0024 should be able to answer.

The 10 Principles are format-neutral by design. OSCAL, with changes, could satisfy many of them. A future format may satisfy them differently.

---

I. Atomic Observations

Each compliance data element stands alone without requiring full system context to be valid or useful (LMR-GEN-SDS).

Consider a control implementation statement, a scan result, a configuration state. Each should be independently meaningful. An assessor examining one observation should not need to parse an entire SSP to understand it. A scanner emitting one finding should not need to construct a complete system model to report it using just a system ID or component ID. Each blind man should be able to report what they observe about the elephant independently.

OSCAL violated this by requiring every element to exist within a fully resolved document hierarchy. The result was that no one could contribute a single observation without first building the cathedral around it.

Prevents: OSCAL's all-or-nothing complexity.

II. Fast Start

A participant should be able to contribute one valid piece of compliance data using one tool without implementing the full standard.

This is the single most important principle. SCAP required a specialized XML toolchain. OpenControl required understanding compliance frameworks. OSCAL required constructing an interlocking set of cross-referenced documents. Each raised the floor of participation high enough that most potential contributors never stepped over it.

The test is concrete: can a developer with no compliance background, given a control ID and a description of what their service does, produce a valid, submittable compliance observation in under an hour using tools they already have? If the answer is no, the format will not achieve broad adoption regardless of its other merits.

Prevents: SCAP's authoring cost, OSCAL's implementation barrier.

III. Incremental Participation

A format should support partial adoption that grows over time, not require all-or-nothing commitment (LMR-GEN-SDS).

Fast start gets a participant in the door. Incremental participation keeps them there. A CSP should be able to begin with machine-readable control implementations for ten controls, expand to fifty, and eventually cover the full baseline with each intermediate state being valid and useful to FedRAMP, not a broken partial document.

This requires that the format's validation model accept incomplete coverage as a legitimate state, not an error. FedRAMP's review processes must similarly accommodate partial machine-readable submissions during a transition period.

Prevents: OSCAL's interlocking document requirement, which made partial adoption structurally impossible.

IV. Bidirectional Communication

Compliance data exchange should be a conversation, not a bulk periodic drop-off (LMR-GEN-OAR).

The current model is itself a cold start problem at the process level. CSP assembles a monolithic package, submits it, waits months for feedback. A machine-readable format enables something fundamentally different: CSPs push baseline compliance data continuously; agencies and FedRAMP pull additional detail on demand.

This is progressive disclosure applied to authorization. High-level posture data flows automatically. Detailed implementation evidence is requested and provided as needed.

Good APIs work this way. A public endpoint returns a summary; authenticated queries return detail. FHIR in healthcare distinguishes a patient summary from the full clinical record. The compliance analog is straightforward: system posture at the summary level, implementation specifics on authorized request.

Prevents: the monolithic package bottleneck that makes every authorization cycle a from-scratch effort.

V. Sensitivity Tiers

High-level descriptions must be separable from sensitive implementation details by design, not as an afterthought (LMR-GEN-HRV).

Not all compliance data carries the same sensitivity. A statement that "the system encrypts data at rest using FIPS 140-validated modules" is publishable. The specific key management architecture, rotation schedules, and HSM configurations behind that statement are not. Current SSPs commingle these tiers in a single document, forcing the entire package to the highest classification level and limiting who can review it.

A machine-readable format should enforce sensitivity boundaries structurally, making it possible to share tier-appropriate views of compliance data with different audiences without redaction. The push/pull model in Principle IV maps naturally to this: baseline data at lower sensitivity tiers flows freely; sensitive implementation details are disclosed only on authenticated, authorized request.

Prevents: the access bottleneck where reviewers cannot see data they need because it is bundled with data they cannot have.

VI. Trustworthy Identifiers

Globally persistent identifiers and document-internal references must be clearly distinguished, and global identifiers must be stable across time and context.

A compliant format should specify: which identifiers are globally persistent and where they resolve; which are document-scoped and how they relate to global identifiers; and what happens when an identifier is retired or superseded.

OSCAL uses UUIDs extensively but does not make this distinction. There is no clear regime separating identifiers that are globally meaningful (this specific AWS service, this specific control) from those that are document-internal references (this cross-link within my SSP). The result: identifiers become opaque strings that tools cannot validate and humans cannot verify.

Prevents: silent identifier collision across documents and organizations, a problem that compounds as the ecosystem scales.

VII. Public Registry of Canonical Identifiers

Well-known assets should have authoritative, shared identifiers that any tool can reference without inventing its own.

AWS EKS, Tenable Nessus, Kubernetes, RHEL, PostgreSQL appear in thousands of SSPs. Today, each CSP invents its own way to refer to them. A machine-readable ecosystem needs a shared namespace for common platforms, tools, and services: a DNS for compliance objects.

FedRAMP should maintain or designate a public registry of canonical identifiers for components that recur across authorization boundaries. This registry becomes the coordination point that enables subsequent principles. Vendors can ship compliance data tagged with identifiers that tools already understand.

Prevents: the fragmentation that made OpenControl's component reuse model impractical — every tool spoke a different dialect for the same objects.

VIII. Vendor-Contributed Components

Platform and tool vendors should be able to ship machine-readable compliance descriptions alongside their products (LMR-GEN-SDS).

OpenControl identified this need over a decade ago. The cultural moment may have arrived. Terraform, Helm, and OCI registries have normalized vendors shipping machine-readable metadata alongside software. AWS, Azure, and GCP publish shared responsibility models. Scanner vendors already produce structured output.

The format and registry infrastructure (Principle VII) should make it straightforward for a vendor to publish: "Here is what our product does, here are the controls it supports, here is the evidence it can produce — tagged with canonical identifiers, in a format any CSP can reference." This converts compliance documentation from a per-CSP cost to a shared, vendor-maintained asset.

Prevents: OpenControl's ecosystem dependency problem — but this time with the IaC cultural precedent that makes vendor participation plausible.

IX. Separation of Observation from Adjudication

Deterministic telemetry produces facts. Whether a fact represents an acceptable risk is a separate question that depends on context. These are different data types and should be treated as such (LMR-GEN-UDT, LMR-GEN-HRV).

A scanner reports that a port is open, a patch is missing, a configuration value is set to X. Whether that finding represents a vulnerability, an accepted risk, or a non-issue depends on deployment context, operational environment, compensating controls, and agency risk tolerance. A firewall rule that is a finding in one deployment may be an accepted risk with documented compensating controls in another. The observation is the same; the risk adjudication differs.

This separation also draws a clean and defensible line for AI's role in compliance. The observation layer stays deterministic and auditable. The adjudication layer is where context, judgment, and accumulated organizational knowledge live. That is exactly where AI assistance adds genuine value: tracking contextual changes, flagging when prior adjudications may no longer apply, and auditing the reasoning chain behind risk acceptance decisions without replacing human accountability. This is a far more defensible use of AI than "AI does compliance," and the format should make the boundary explicit.

Prevents: non-reusable compliance data that embeds context-specific judgments into factual observations, and the temptation to use AI where deterministic methods suffice.

X. Semantic Vocabulary Reuse

Build on OSCAL's named compliance objects rather than reinventing terminology (LMR-FRX-LAF).

OSCAL's most durable contribution is not its document architecture but its vocabulary: responsible-party, system-component, implemented-requirement, inventory-item, set-parameter. These names give the compliance community a shared language for concepts that were previously buried in free-form prose. Any successor format should adopt this vocabulary as its semantic foundation.

This is not an endorsement of OSCAL's full specification. It is recognition that naming things well is genuinely hard, that OSCAL did this work, and that discarding it would force the community to re-fight terminology battles that are already settled.

Prevents: unnecessary fragmentation from reinventing what OSCAL already got right.

---

Applying the Principles

These ten principles give FedRAMP a framework for evaluating any proposed format under RFC-0024's "five or more CSPs" provision. A candidate format that satisfies Principles I through III will achieve adoption. A format that additionally satisfies IV through VII will scale. A format that satisfies all ten will build an ecosystem.

The principles also suggest a sequencing for RFC-0024's implementation timeline:

• Phase 1 (by September 2026): Require formats to demonstrate Principles I–III. Accept atomic, fast-start, incremental submissions for the most structured SSP elements: control implementation statements, inventory, and the Customer Responsibility Matrix.
• Phase 2 (by September 2027): Require Principles IV–VII. Establish the registry, the push/pull exchange model, and sensitivity tier separation. Expand coverage to full SSP, SAP, and SAR.
• Phase 3 (by September 2028): Require Principles VIII–X. Enable the vendor ecosystem, enforce the observation/adjudication boundary, and validate semantic interoperability across tools.

This phased approach aligns RFC-0024's ambition with the lessons of history: mandate adoption only after the infrastructure exists to support it.

[CSP-AB]

The Cloud Service Providers - Advisory Board submits the following comments:

General Comments:

• FedRAMP should consider creating an accompanying "Technical Assistance" to offer guidance on available open source tools/resources that are available to help meet some of these requirements. Additionally, having example schemas for CSPs to work off of for required documentation would be beneficial in establishing a baseline level of content. Having industry work independently will not create outcomes that serve the community at large including PMO, agencies and the CSP community.

• FedRAMP is one of dozens of compliance regimes that CSPs must satisfy. The vision of a universal, machine-readable compliance data model — where a single authoritative system state can satisfy FedRAMP, StateRAMP, DoD IL4/IL5, ISO 27001, SOC 2, and others simultaneously — is achievable. FedRAMP should adopt OSCAL as its canonical format and publishes the tooling to support it. The "multiple approved formats" approach in this RFC moves in the opposite direction, increasing fragmentation and making cross-framework automation harder.

• Recommendation: FedRAMP should formally endorse OSCAL as the strategic standard, commit to maintaining it in partnership with NIST, and position RFC-0024 as the first step toward a unified compliance data model — not just a FedRAMP-specific machine-readable package requirement.

Comments on Background Section:

• Industry has been investing in OSCAL but there has been no support for receiving machine readable formats from FedRAMP or the agencies. This section should be restructured to reflect the reality of the OSCAL journey and not put the responsibility solely on the CSPs.

• There is no current location to send machine readable formatted security documents. FedRAMP should require API or other methods that are available to CSPs to send documents.

Comments on Motivation Section:

• FedRAMP should explicitly state which artifacts are required to be machine-readable (e.g., SSP, POA&M, SAR summaries) and which are expected to remain primarily narrative in nature (e.g., incident response plans, contingency plans). Not all artifacts are equally suited to structured machine representation, nor should represent the same schema of fields/information between CSPs.

• “Authorization data” must clearly include SAP and SAR where applicable. Those artifacts are produced by 3PAOs. For machine-readable timelines apply, they must explicitly apply to 3PAOs as well. CSPs should not face revocation risk for deliverables they do not directly control — particularly where assessment contracts are already in place for the current year.

Comment on Summary of Deadlines:

• The timelines for full enforcement are aggressive especially since agencies lack the tooling to consume machine readable packages. Currently industry will be expanding significant effort building artifacts that are not being consumed.

Comments on LMR-FRX-LAF List of Approved Formats:

• The core issue is not file format — it’s schema. If OSCAL is not the selected standard it is important for FedRAMP to approve the schema. Interoperability will become challenging not by the formatting but the underlying data schemas and drift between standards. FedRAMP should publish a schema for all required artifacts then the standard does not matter and creating ingestion or document transformation tools will be easier.

• Require that any new approved format must demonstrate full equivalence to the OSCAL or whatever approved schema is chosen via a published mapping, and that FedRAMP must provide or certify a validation tool before the format is accepted. The "5 CSP" threshold should be replaced with a formal standards body review process.

• Technical feasibility isn’t the issue. Industry doesn't want a dozen region/ vendor/regulation-specific formats/schemas. Most stakeholders recognize the value in a standard-based, common language for GRC and agree that it is urgently needed. OSCAL is the only such standard available today. The suggestion that format-conversion would be trivial or automatic is an oversimplification of the business, cultural and political challenges. FedRAMP is one regime of many that CSPs must satisfy. FedRAMP supporting a universal standard is exactly what we need and allows FedRAMP to continue its impact of shaping compliance and security. This is a unique opportunity for FedRAMP to participate in the larger community and arm CSPs with better standardization across all compliance regimes.

Comments on LMR-FRX-AMR Accepting Machine Readable-Packages:

• Agency Tooling Should Precede Mandates. Agencies SHOULD adopt tooling capable of ingesting approved machine-readable formats (including OSCAL). Agencies MAY require CSPs to provide machine-readable packages with no less than six (6) months’ written notice. Providers MUST comply once such notice is given. This shifts adoption to demand-driven, demonstrated value rather than speculative compliance.

• FedRAMP should be prioritizing the development or support of validations scripts and other tools to ensure that machine readable packages are well formed, in a valid format and in an acceptable state. Without this validation prior to submission, FedRAMP will most likely encounter the same challenges with package reviews they have experienced in the past - things such as common, low hanging fruit mistakes that take up valuable FedRAMP review time.

• The requirement that FedRAMP "MUST accept and review" machine-readable packages is necessary but insufficient. There is no reciprocal commitment from FedRAMP to process these submissions programmatically, provide API-based submission endpoints, return structured feedback, or publish SLAs for machine-readable vs. non-machine-readable review timelines.

• Proposed change: Add explicit requirements for:

• - A submission API (not just email or portal upload)

• - Structured, machine-readable validation responses from FedRAMP. Published SLAs distinguishing machine-readable vs. legacy submission processing. A commitment that FedRAMP's own review tooling will be machine-based, not human-manual review of OSCAL artifacts

Comment on LMR-GEN-SDS Service-based Data Separation:

• LMR-GEN-SDS is a SHOULD, but this language implies it is a MUST. FedRAMP needs to reconcile guidance.

Comments on LMR-GEN-DGI Deterministically Generated Illustrations:

• Proposed change: FedRAMP should publish reference implementations or approved tooling that can generate compliant boundary diagrams. Without this, the requirement will be met with low-quality auto-generated diagrams that satisfy the letter but not the spirit of the requirement.

• FedRAMP should shift the perspective of this note and remove the warning banner all together. A warning banner would essentially be penalizing CSPs for not meeting a SHOULD requirement. Instead, FedRAMP should focus on highlighting CSPs that have implemented this. As a result, FedRAMP should not include a warning banner. Additionally, who is to say that deterministically generated illustrations cannot also be unreliable. Being able to perform this is not a magic pill to have 100% reliable diagrams/illustrations.

Comment on LMR-GEN-HRV Human-Readable Versions:

• Proposed change: FedRAMP should publish and maintain an official OSCAL-to-human-readable rendering tool (or certify third-party tools) to ensure consistent, high-quality human-readable output. This is especially important for agency reviewers who are not yet equipped to consume raw OSCAL.

[pete-gov]

The following public comment was received via email from Crowdstrike on Wed Mar 11:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

It is very difficult to manage formatting from PDF submissions, so this was converted to Markdown and copy/pasted as-is - all text should be intact.

---

REQUEST FOR COMMENT RESPONSE

RFC-0024 FEDRAMP REV5 MACHINE-READABLE PACKAGES

March 11, 2026

I.INTRODUCTION

In response to FedRAMP’s request for comment on the FedRAMP Rev5 Machine Readable Packages (“draft standard”), CrowdStrike offers the following views.

We approach these questions from the standpoint of a leading international, US headquartered, cloud-native cybersecurity provider that defends globally distributed enterprises from globally distributed threats. CrowdStrike offers insights informed by multiple practice areas: cyber threat intelligence; proactive hunting, incident response and managed security services; and an AI-powered software-as-a-service cybersecurity platform and marketplace. Accordingly, this perspective is informed by CrowdStrike’s role in protecting organizations from data breaches and a variety of other cyber threats.

II. COMMENTS

CrowdStrike recognizes the long-term vision of machine-readable authorization packages and appreciates FedRAMP's efforts to modernize the authorization process. The request for comment correctly identifies historical challenges with manual documentation processes and the theoretical benefits of structured, machine-readable data. We acknowledge that standardized, machine-readable formats could eventually improve efficiency and enable automated consumption of authorization data by agency tools.

We welcome the opportunity to offer feedback that may be of value to FedRAMP as it considers the draft standard.

A. Misalignment with Agency Demand and Capabilities

The draft standard mandates significant investment in machine-readable package production without corresponding evidence of agency demand or readiness to consume such materials. Through direct engagement with our federal agency customers and their authorization officials who leverage our existing FedRAMP authorization for agency authorization decisions, CrowdStrike has identified minimal interest in receiving authorization packages in machine-readable formats. Agency authorization teams consistently request traditional human-readable documentation in
Word and Excel formats, which align with their existing review processes, tools, and workflows.

The requirement for dual-format maintenance (LMR-GEN-HRV) acknowledges this reality but creates an unsustainable operational burden for currently authorized cloud service providers. We would be required to:

• Invest substantial resources in developing or acquiring machine-readable authoring capabilities

• Convert our existing comprehensive authorization package to machine-readable format

• Maintain authoritative machine-readable source materials going forward • Generate human-readable versions for actual agency consumption upon request • Ensure consistency between both formats during monthly continuous monitoring updates and significant changes

• Train our security, compliance, and technical staff on both documentation paradigms

This dual-maintenance requirement effectively doubles the documentation burden for existing authorized providers while providing no demonstrated value to the agencies that are the ultimate consumers of this information. The draft standard notes that "no formal participants in the FedRAMP 20x Phase 1 pilot used [OSCAL] to structure the required machine-readable materials," which strongly suggests that even organizations participating in modernization pilots found insufficient value in machine-readable formats to justify adoption.

Specifically:

• Agency authorization officials lack tools, training, and processes to consume machine-readable packages, making them effectively unusable for authorization decisions.

• The requirement creates a "build it and they will come" approach that places the entire burden and risk on cloud service providers without corresponding agency investment.

• Existing authorized cloud service providers will invest significant resources to produce machine-readable packages that are immediately converted back to human-readable formats for actual use by agencies.

• The LMR-GEN-USC requirement for updates after significant changes within one month creates a perpetual conversion burden as our platform evolves.

The objective of highlighting this concern is to ensure FedRAMP requirements align with demonstrated agency needs and capabilities rather than theoretical future states.
B. Unrealistic Implementation Timeline for Existing Authorizations The draft standard's implementation timeline is fundamentally incompatible with the complexity and scope of the required transformation for cloud service providers with existing authorizations. For CrowdStrike, LMR-GEN-OAR requires our next annual assessment after September 30, 2026 to include a full authorization package in machine-readable format, with loss of FedRAMP Certification by September 30, 2027 if we fail to comply. This provides approximately 6-7 months to:

• Evaluate and select from approved machine-readable formats (with OSCAL being the only currently listed option despite zero adoption in 100+ Rev5 authorizations in 2025 and zero adoption among FedRAMP 20x Phase 1 pilot participants, all of whom used alternative machine-readable formats)

• Identify, evaluate, and procure or develop authoring tools and validation capabilities

• Assess the current vendor and consultant ecosystem for expertise • Convert our existing multi-hundred page System Security Plan with detailed control implementation statements

• Convert all standard Rev5 appendices referenced in LMR-FRX-LAM • Restructure our authorization package to separate service-based data per LMR GEN-SDS in alignment with procurement patterns

• Develop and implement processes for maintaining machine-readable packages during continuous monitoring

• Train our security, compliance, and technical staff on new tools and processes • Establish quality assurance and validation procedures

• Integrate machine-readable package generation into our change management workflows for LMR-GEN-USC compliance

This timeline is particularly problematic for existing authorized providers given that:

• The RFC acknowledges "no formal participants in the FedRAMP 20x Phase 1 pilot used [OSCAL]," indicating that even motivated early adopters participating in a modernization pilot specifically designed to test new approaches unanimously chose alternative machine-readable formats over OSCAL

• Commercial tooling, consulting services, and 3PAO expertise are lacking due to low market demand

• The requirement applies to our complete existing authorization package, not just incremental updates
• LMR-GEN-OAR provides no accommodation for existing authorized providers who have invested years in maintaining comprehensive authorization packages

The complete absence of a phased approach, pilot program, or beta period represents a significant departure from standard change management practices for requirements of this magnitude. Organizations implementing enterprise-wide documentation transformations typically employ multi-year phased approaches with extensive piloting, particularly when converting existing comprehensive documentation rather than creating new materials. The 20x pilot experience demonstrates that machine readable packages are achievable, but also reveals that providers gravitate toward formats other than OSCAL when given flexibility—a finding that should inform Rev5 requirements.

Specifically:

• The timeline should be extended to a minimum of 12-18 months from publication of final requirements to allow existing authorized providers proper planning, tooling acquisition, and conversion of existing materials.

• FedRAMP should establish a formal pilot program with volunteer cloud service providers who have existing authorizations to identify implementation challenges, validate tooling approaches, and develop best practices before mandatory adoption.

• A phased approach should prioritize specific document types (e.g., SSP first, then appendices, then continuous monitoring artifacts) rather than requiring simultaneous conversion of all materials in a single annual assessment.

• The marketplace prioritization outlined in LMR-FRX-GPM should be enhanced with additional tangible benefits to encourage voluntary early adoption.

The objective of these recommendations is to ensure successful adoption through realistic timelines that account for the evolving tooling ecosystem, leverage lessons learned from 20x implementations, and recognize the complexity of converting comprehensive existing authorization packages.

C. Technical Feasibility of Diagram and Illustration Automation

The draft standard's recommendation for deterministically generated illustrations and diagrams (LMR-GEN-DGI), while conceptually appealing, presents significant technical challenges that are not adequately addressed. The requirement that providers "use machine-generated deterministic telemetry to generate all necessary illustrations and diagrams, including at least the Authorization Boundary Diagram" assumes capabilities that do not currently exist in commercial tooling and may not be technically feasible for complex cloud architectures maintained by existing authorized
providers.Authorization boundary diagrams for enterprise cloud platforms like CrowdStrike's typically represent:

• Hundreds of interconnected services and components across our platform • Complex data flows across multiple security boundaries

• Shared responsibility models between provider and customer • Conditional architectures that vary based on customer configuration choices • Logical and physical network segmentation across multiple regions • Integration points with customer environments and third-party services • Inherited controls from infrastructure providers

Automatically generating accurate, comprehensible diagrams from system telemetry for architectures of this complexity requires sophisticated graph layout algorithms, semantic understanding of component relationships, and intelligent abstraction to produce diagrams that are actually useful for human review by authorization officials. The RFC provides no guidance on:

• What constitutes acceptable "machine-generated deterministic telemetry" for diagram generation

• How to handle architectural complexity that exceeds the practical limits of automated diagram generation

• Whether semi-automated approaches (human-guided automated generation) satisfy the requirement

• What validation or accuracy standards apply to automatically generated diagrams

• How to represent conditional or customer-configurable architectures in automated diagrams

The penalty for non-compliance - "a warning that illustrations and diagrams are artisanal artifacts and may be unreliable" - is particularly problematic for existing authorized providers. This warning implies that our carefully crafted diagrams, reviewed by our architects, security engineers, and 3PAO assessors, are inherently unreliable. In reality, our manually created diagrams may be significantly more accurate and useful than automatically generated diagrams that lack appropriate context, abstraction, and the semantic understanding necessary to communicate complex security architectures to authorization officials.

Specifically:
• The requirement should acknowledge that hybrid approaches (automated generation with human review and refinement) may be necessary for complex systems and should satisfy the intent of the requirement.

• Standards for diagram accuracy, completeness, and usability should be established regardless of generation method, with validation processes that ensure automated diagrams meet the same quality standards as manually created diagrams.

• The marketplace warning should be reconsidered, as it creates a false equivalence between generation method and reliability, potentially misleading agencies about the quality of authorization materials from existing authorized providers.

The objective of these recommendations is to ensure diagram requirements are technically achievable while maintaining the accuracy and utility that authorization officials require for security assessments of existing authorized cloud services.

III. CONCLUSION

We believe machine-readable authorization packages represent a valuable long-term vision for FedRAMP modernization. However, successful implementation requires alignment between provider capabilities, agency readiness, and realistic timelines that account for the significant conversion burden on existing authorized providers. As the standard moves forward and evolves, we recommend:

Phased Implementation Approach: Establish a multi-year roadmap with clear phases, beginning with voluntary pilot programs involving existing authorized providers, progressing to specific document types, and ultimately achieving comprehensive machine-readable packages as tooling matures and agencies develop consumption capabilities.

Agency Readiness Requirements: Coordinate machine-readable package requirements with corresponding agency investments in tools, training, and processes to consume such materials, ensuring existing authorized providers are not investing in capabilities that agencies cannot utilize.

Extended Timeline with Pilot Period: Extend implementation timelines to 12 - 18 months from publication of final requirements and establish formal pilot programs with volunteer providers who have existing authorizations to validate approaches, identify challenges, and develop best practices before mandatory adoption.

Realistic Technical Requirements: Ensure requirements for automated diagram generation and deterministic telemetry are technically feasible with available or near-
term tooling, or provide extended timelines for capability development and accept hybrid approaches that combine automation with human expertise.

Finally, we recommend FedRAMP consider whether the significant investment required for existing authorized providers to convert comprehensive Rev5 authorization packages to machine-readable formats might be better directed toward accelerating agency adoption of FedRAMP 20x, which was designed from first principles to support machine-readable authorization data. Requiring substantial investment in retrofitting existing Rev5 authorization packages may delay the transition to the more comprehensive modernization that 20x represents, while creating a significant burden on providers who have invested years in maintaining high-quality authorization materials under the current framework.

[pete-gov]

The following public comment was received via email from Salesforce on Wed Mar 11:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

This was converted from a table to markdown, apologies for any formatting issues. Text should all be intact.

---

Requirement_ID	Title/Section	Salesforce Comment
LMR-FRX-LAM	List of Authorization Materials	In general to RFC-0024; 1. FedRAMP-provided technical assistance and guidance Concern: The RFC places adoption on industry (“the change must begin outside the government”) and sets firm deadlines (e.g., machine-readable packages required by September 30, 2026; non-compliance leading to loss of Certification by September 30, 2027) without committing FedRAMP to publishing guidance or tools to help providers comply. Many CSPs, especially smaller ones, may lack experience with OSCAL or other approved formats. Without centralized guidance on open-source tools, conversion approaches, and implementation patterns, adoption may be uneven, costly, or delayed, and providers may see the requirement as unfunded mandate rather than supported transition. Recommendation: Publish and maintain an accompanying Technical Assistance resource (e.g., a guide, FAQ, or dedicated page) that: (1) lists or references available open-source tools and resources that can help produce, validate, or convert machine-readable authorization data in approved formats; (2) provides implementation guidance and examples (e.g., Schemas, OSCAL workflows, mapping from existing packages); and (3) is released in step with or before the April 15, 2026 publication of materials supporting industry adoption (LMR-FRX-LAM). Co-locate or link this with the List of Authorization Materials and List of Approved Formats so providers have a single place to find both requirements and practical support. 2. Confirming agency demand for machine-readable authorization data Concern: The RFC states that machine-readable packages will “allow agencies to automatically consume this data” for initial and ongoing authorization decisions, but it is unclear how much agencies today request or use machine-readable authorization data. If agencies rarely ask for machine-readable docs and procurement/authorization workflows still rely on traditional artifacts, CSPs may invest in the new format without seeing clear benefit or pull from customers, which could reduce buy-in and make the transition feel supply-driven rather than demand-aligned. Recommendation: In the RFC or in a separate communication, describe evidence of agency demand or intent for machine-readable authorization data (e.g., agency feedback, pilot usage, procurement language, or roadmap). If such evidence is limited, consider: (1) briefly acknowledging that adoption is being led by FedRAMP and that agency tooling may follow; or (2) outlining steps FedRAMP or OMB will take to encourage agency consumption (e.g., guidance, system requirements, or timelines for agency tools). Sharing this context would help CSPs understand why the investment is required and how it will be used, and would align the narrative with whether demand is current or anticipated. Summary: 1. Technical assistance: Publish and maintain a Technical Assistance resource (guide, FAQ, or page) that lists open-source tools and implementation guidance for producing/validating machine-readable packages, and release it by or with the April 15, 2026 materials so providers have one place for requirements and support. 2. Agency demand: Describe evidence of agency demand or intent for machine-readable data (or acknowledge that adoption is FedRAMP-led and agency tooling will follow), and outline how FedRAMP/OMB will encourage agency consumption so CSPs understand why the investment is required.
LMR-FRX-LAF	List of Approved Formats	1. Define required fields that all approved formats must support Concern: The policy allows multiple standardized formats (including OSCAL and formats adopted by alliances of 5+ CSPs) and states that “structured formats are machine-interchangeable,” but it does not define a core set of required data elements (fields) that every approved format must represent. Without that, formats could diverge in coverage, agencies and FedRAMP cannot assume consistent content across formats, and “machine-interchangeable” is hard to achieve. CSPs and tool vendors also lack a clear target for what any format must include. Recommendation: FedRAMP should define and publish a mandatory set of required fields (or equivalent data elements) that every approved format must support for Rev5 authorization packages. Publish this in the same place as (or linked from) the List of Approved Formats and the List of Authorization Materials (LMR-FRX-LAM). Specify that any format added to the list—whether OSCAL or an alliance-proposed format—must be able to represent these fields so that FedRAMP and agencies can rely on a common minimum and conversion between formats is well-defined. 2. How and how often the list and formats will be reviewed and updated Concern: The policy requires FedRAMP to “publish and maintain” the list and to remove formats not adopted within one year, but it does not state how or how often the list, approved formats, or required fields will be reviewed and updated. As formats evolve and new ones are proposed, CSPs and agencies need predictable review cycles and a process for changes (e.g., new fields, format versioning, deprecation). Recommendation: Define in the policy or implementing guidance (1) how often the list and any FedRAMP-defined required fields will be reviewed (e.g., annually or tied to Rev5 BIR cycles), and (2) how changes will be made—e.g., notice-and-comment, versioning of the list, and how format owners or alliances request updates. Publish this process so industry can plan and participate. 3. OSCAL coverage of full authorization package Concern: OSCAL is included as an approved format and is supported by some GRC tools (e.g., OSCAL export from tools such as Telos Xacta), but it currently addresses only a subset of typical FedRAMP package artifacts (e.g., SSP, POA&M, SAR). Other required or commonly expected documents—such as Incident Response Plan, Contingency Plan, CIS/CRN, and similar—are not explicitly covered by OSCAL. Providers using OSCAL may therefore have part of the package in machine-readable form and the rest in other formats, which complicates “full” machine-readable submission and agency consumption. Recommendation: In the List of Approved Formats or in technical guidance, clarify which authorization package artifacts each approved format (including OSCAL) is expected or able to represent. Where a format does not yet cover all materials on the List of Authorization Materials, state whether: (1) the format is approved for a defined subset and other artifacts are submitted in a specified way, or (2) format maintainers (e.g., OSCAL) are expected to extend coverage, and by when. This will align CSP and tooling investment with FedRAMP’s expectations for a complete machine-readable package. 4. Agency and FedRAMP ability to consume multiple formats Concern: Allowing multiple approved formats avoids mandating a single standard but requires FedRAMP and agencies to accept and process several formats. Agencies that authorize many CSPs may face multiple formats and need reliable parsing and validation. If FedRAMP does not provide or endorse tools to parse and validate each approved format, agencies may be unable to consume machine-readable data consistently, and the burden of supporting many formats could fall on agencies or slow adoption. Recommendation: Clarify in the policy or guidance how multi-format consumption will be supported. Options to address: (1) FedRAMP publishes or endorses validation/parsing tools or libraries for each approved format; (2) FedRAMP accepts all approved formats but converts to a single internal or exchange format and publishes that approach; or (3) format alliances or format owners commit to providing validated parsers or conversion to a common schema. Stating the intended model will clarify responsibilities and reduce risk that agencies are left unable to parse the formats CSPs use.
LMR-FRX-AMR	Accepting Machine Readable-Packages	1. Parsing tools for multiple approved formats Concern: The policy requires FedRAMP to accept and review packages in any approved machine-readable format. If multiple formats are approved (e.g., OSCAL plus formats from CSPs), FedRAMP and agencies will need reliable ways to parse and process each format. It is unclear whether FedRAMP will develop and maintain parsing tools or ETL scripts for these formats and, if so, whether those tools will be made available to the public. Without clarity, CSPs cannot assume compatible tooling exists, and agencies may struggle to consume packages in formats they do not natively support. Recommendation: State in the RFC or implementing guidance whether FedRAMP will develop, maintain, or endorse parsing/ETL tools for each approved format and whether such tools will be published (e.g., open source or as a public reference). If FedRAMP will not provide tools, clarify how format validation and ingestion will be assured (e.g., by requiring format proponents to provide validators or by specifying a single reference format for FedRAMP’s own pipeline). This will clarify expectations for CSPs and agencies and support interoperability. 2. Baseline quality and pre-submission validation Concern: The requirement that FedRAMP “MUST accept and review” packages in an approved machine-readable format could be read to mean acceptance of any submission that is syntactically in an approved format, regardless of completeness, correctness, or quality. That would leave FedRAMP obligated to accept poorly formed or incomplete packages and could recreate the same review burdens as today—e.g., common, low-effort errors consuming review time and delaying certification. A pure “accept if format-approved” approach does not establish a baseline for package quality or readiness. Recommendation: Strengthen the requirement or accompanying guidance to define a baseline level of quality for machine-readable packages (e.g., required elements present, valid against a schema, and meeting minimum completeness criteria) and to allow FedRAMP to reject or return packages that do not meet that baseline before full review. Publish these quality/schema requirements in the List of Authorization Materials (LMR-FRX-LAM) or a linked specification so CSPs know what “acceptable” means before submission. 3. Validation tools and scripts for pre-submission checks Concern: Without standardized validation tools or scripts, CSPs may submit machine-readable packages that are well-formed in format but invalid, incomplete, or inconsistent (e.g., missing required fields, schema violations, or obvious errors). FedRAMP would then discover these issues during review, repeating past inefficiencies and consuming capacity on avoidable rework. Industry adoption is also hindered if CSPs have no authoritative way to check that a package is “in an acceptable state” before submission. Recommendation: Prioritize development or support of validation scripts/tools (e.g., schema validators, completeness checks, or a FedRAMP-run pre-submission validation service) that allow CSPs to verify that machine-readable packages are well-formed, valid against the approved format, and meet FedRAMP’s baseline quality requirements before submission. Publish these tools or their specifications (and any required schemas) so CSPs and tool vendors can integrate them into their workflows. Tie use of these validators to the baseline quality requirement so that “accept and review” is understood to apply to packages that have passed (or could pass) defined validation checks, reducing review time and improving consistency. Summary: Parsing tools: Say whether FedRAMP will build/maintain (and publish) parsing or ETL tools for each approved format, or how validation and ingestion will work if it does not. Baseline quality: Define a minimum quality bar (e.g., required elements, schema validity, completeness) and allow FedRAMP to reject or return packages that don’t meet it before full review; publish this in LMR-FRX-LAM or a linked spec. Pre-submission validation: Provide or support validation tools/scripts (schema, completeness, etc.) so CSPs can check packages before submission; publish the tools/specs and tie “accept and review” to packages that meet these checks.
LMR-GEN-ICR	Initial Certification Requirements	Concern: The requirement that “providers MUST submit new authorization packages … in an approved machine-readable format” does not specify what the authorization package consists of (which documents and artifacts). The statutory definition is high-level, and the detailed list is deferred to LMR-FRX-LAM (effective April 15, 2026). Until that list is published, providers cannot be certain which materials must be included in the machine-readable package. Recommendation: In this requirement (or in LMR-FRX-LAM), explicitly list the components of the Rev5 authorization package (e.g., SSP, SAR, POA&M, and all standard Rev5 appendices by name). Summary: Explicitly list the components of the Rev5 authorization package
LMR-GEN-DGI	Deterministically Generated Illustrations	1. Remove the warning banner and use positive framing Concern: The note states that marketplace listings and authorization packages for cloud services that do not follow this recommendation “will include a warning that illustrations and diagrams are artisanal artifacts and may be unreliable.” That effectively penalizes CSPs for not meeting a SHOULD (recommendation), which is inconsistent with RFC 2119: SHOULD implies preference, not obligation. In addition, machine-generated deterministic telemetry can also be wrong or incomplete; it does not guarantee reliable diagrams. A warning that implies “artisanal = unreliable” and “deterministic = reliable” is misleading and may create a false sense of assurance for diagrams that are deterministically generated but still incorrect. Recommendation: Remove the warning banner. Do not attach a negative label or warning to CSPs that do not adopt this recommendation. Instead, use positive framing: e.g., identify or highlight in the Marketplace those CSPs that have implemented machine-generated deterministic telemetry for illustrations and diagrams (similar to LMR-FRX-GPM). That rewards adoption without punishing non-adoption and aligns enforcement with the SHOULD language. If any disclaimer is retained, apply it consistently (e.g., that all diagrams—whether artisanal or machine-generated—should be verified for accuracy) rather than only to “artisanal” artifacts. 2. Clarify required level of detail for boundary diagrams Concern: Deterministic telemetry is often at a much lower level of detail than authorization boundary diagrams require, especially for internal and cross-boundary connections. Without clearer guidance on the level of detail FedRAMP expects (e.g., which components, interfaces, and data flows must be represented), CSPs cannot consistently implement the recommendation or know when “all necessary illustrations and diagrams” are satisfied. Recommendation: Publish guidance that specifies the expected level of detail for authorization boundary diagrams (and other “necessary” illustrations) when generated from deterministic telemetry—e.g., required elements (boundary, internal/external connections, key system components), optional elements, and how to handle internal vs. cross-boundary connections. Align this with the List of Authorization Materials (LMR-FRX-LAM) where relevant. This will allow CSPs to choose tools and scope implementation without over- or under-investing. 3. Address implementation realities: cost, data access, and review burden Concern: Widespread adoption would likely require many CSPs to adopt and pay for third-party tools (e.g., discovery/visualization solutions). Some techniques also require broad, sensitive access to production or configuration data, which raises security and privacy concerns. Moreover, machine-generated outputs often need human review and correction when the tool is wrong; the policy does not address how that review burden is expected to be managed or how it affects the value and feasibility of adoption. Recommendation: In the RFC or in technical assistance materials: (1) acknowledge that adoption may involve third-party tools and reference or list example approaches (e.g., workload discovery, infrastructure-as-code visualizers) where appropriate, without mandating specific vendors; (2) provide guidance or expectations on how deterministic telemetry can be obtained without requiring excessive access to sensitive datasets (e.g., use of metadata, configuration exports, or scoped APIs); and (3) clarify that human review and correction of machine-generated illustrations is acceptable and that the recommendation is satisfied when diagrams are produced from deterministic telemetry and then validated or augmented by the CSP as needed. This would set realistic expectations and reduce uncertainty for CSPs evaluating adoption. Summary: 1. Remove the warning banner and use positive framing 2. Clarify required level of detail for boundary diagrams 3. Give guidance on getting deterministic telemetry without broad access to sensitive data; and state that human review/correction of machine-generated diagrams is acceptable and still satisfies the recommendation.

[rubrik-fedramp-team]

Thanks as always for the opportunity to comment and be a part of shaping FedRAMP's future.

1) LMR-FRX-LAF - List of Approved Formats
Rubrik strongly supports the modernization of FedRAMP through the ingestion of structured data. However, the mechanism proposed in LMR-FRX-LAF poses a risk of semantic fragmentation. While syntactical formats (e.g., JSON, XML) are easily interchangeable, reconciling disparate compliance schemas requires significant overhead. Permitting multiple schemas will force federal agencies, 3PAOs, and CSPs to maintain fragile, custom translation layers, degrading the interoperability this RFC seeks to achieve. To ensure ecosystem stability and allow CSPs to confidently invest in API-driven automation tooling, FedRAMP should designate a single canonical standard. CSPs should be granted latitude regarding their internal data persistence architectures, provided that the final artifacts submitted to the FedRAMP repository strictly conform to the canonical schema.

2) Authorization Package - 3PAO Deliverables
Rubrik respectfully requests clarification regarding the applicability of machine-readable deadlines to assessor-owned deliverables. 'Authorization data' inherently encompasses the Security Assessment Plan (SAP) and the Security Assessment Report (SAR), artifacts generated, owned, and maintained by the 3PAO. CSPs lack the contractual or technical leverage to compel 3PAO tooling upgrades within the proposed implementation window, particularly for assessment cycles already under contract. FedRAMP should establish distinct enforcement mechanisms for 3PAO readiness that legally and operationally insulate CSPs from certification revocation risks stemming from third-party ecosystem immaturity.

3) LMR-GEN-SDS - Service-based Data Separation
The requirement to separate authorization data based on distinct services or procurement models introduces significant administrative overhead and data consistency risks without a commensurate increase in security value or agency visibility. Enforcing service-based data separation fragments compliance packages, forcing CSPs to manage redundant documentation and complex cross-referencing schemes that are highly prone to version drift.

For integrated platforms, particularly SaaS, services often share the vast majority of their control inheritance (e.g., common authentication, logging, and physical security layers). Rather than physically these into distinct artifacts, a properly annotated, consolidated package is a more effective approach. By utilizing OSCAL metadata to tag controls by component or service, consumers can leverage the advanced search and filtering capabilities of modern GRC tools to "view" only the relevant data they need, without forcing the CSP to separately "author" it.

We recommend revising this clause to define service-based data separation as an optional ('MAY') capability. Separation should be reserved for CSPs whose discrete services exhibit material differences in architecture, risk profile, or regulatory scope. This adjustment supports the broader FedRAMP modernization goal of reducing unnecessary documentation overhead while maintaining effective security reviews.

4) LMR-GEN-DGI - Deterministically Generated Illustrations
While the objective of maintaining accurate and up-to-date architectural diagrams is fully understood, mandating "machine-generated deterministic telemetry" as the sole creation method introduces significant operational burdens and yields less useful artifacts. Complying with this requirement forces CSPs to procure and integrate entirely new engineering-focused visualization tools, duplicating costs and creating new integration security risks.

Second, for hyperscale SaaS platforms operating dynamic, cloud-native microservices architectures, generating a raw, deterministic topological map yields an artifact largely devoid of communicative value. AOs require deliberate, human-guided abstraction to properly comprehend logical boundaries, zero-trust enforcement points, IAM flows, and shared responsibility demarcations. Penalizing CSPs for producing legible, abstracted diagrams will perversely incentivize the submission of technically accurate but practically useless machine-generated outputs.

We request the removal of punitive Marketplace signaling associated with non-deterministic authorization boundary diagrams. The standard should focus on the accuracy and verifiability of the diagram rather than the specific mechanism used to generate it.

[badgerinspace]

Thank you for allowing public comment on this. Below are my personal thoughts:

LMR-FRX-LAM:

• This doesn't list how this information will be published, but one can assume based on the statement "...FedRAMP will no longer publish or maintain word-processor based templates for these materials" that FedRAMP will only publish machine-readable information at that point forward. While this makes sense for the way the program is headed, unless this information is also published on FedRAMP's website in a human-readable format (Markdown, HTML, etc), people newly entering the FedRAMP and NIST control space will likely struggle to understand the requirements.

LMR-FRX-LAF:

• Please ensure any approved format includes sufficient information for the public to follow and recreate, should they choose to adopt it. FedRAMP might want to explore finer detail on what's deemed acceptable when it comes to public information about a new format. Please also ensure FedRAMP's list includes links to the documentation surrounding such formats to decrease barriers to entry for adoption.

LMR-FRX-AMR:

• April 15, 2026 seems likely a very aggressive timeline for FedRAMP to adopt any approved format for machine-readable packages. While that determination is purely up to FedRAMP, a more relaxed timeline perhaps accounting for "X number of months after a format is approved" would allow an accountable, but less aggressive timeline.

LMR-GEN-USC:

• Stating that FedRAMP may track "the average number of days it takes a provider to update their primary materials after making a significant change" would likely require a detailed review by FedRAMP to confirm that stated updates to material reflect what should actually be updated. Otherwise, a CSP could simply inform FedRAMP that they've updated their machine-readable authorization package data to reflect the SCR within the established deadline, but not actually perform the entire update or any update at all.
• It seems unlikely that machine-readable authorization package data will be materially faster to update than maintaining traditional documentation. It will still require the relevant SME to provide a write up on the new service or changed service, discuss the technical implementation, and describe the security impact on the data. If this significant change is reflected across multiple systems, then there could be a small increase in speed as the code could be copied between systems, but the same logic would apply if it was a traditional SSP based on a word processor. In other words: SSP-as-code doesn't inherently make updates across all documentation faster or easier, instead it just means the code would need to be updated in multiple places rather than the document updated in multiple places.

LMR-GEN-DGI Deterministically Generated Illustrations:

• Machine-generated deterministic telemetry sounds nice, but there is no software that exists that pulls in all possible assets, services, interconnections, and platforms into some form of code that can then dynamically build a diagram, in the level of detail required for FedRAMP. Take for example the following system:
• CSP is built across Azure, AWS, and GCP, utilizing services from each and deploying VMs on each.
• Some VMs communicate with certain services at certain times of day while others wait for a trigger before they process data and then pass it along to the next service/VM
• Some VMs typically never communicate with anything but have Lambda rules setup to modify firewall rules based on an admin's IP address. In other words, dynamic firewall rules are implemented when an admin connects and needs to access those VMs.
• Extend this to containers too, which have detailed connections that would need to be mapped and such automated mapping software can't simply rely on what connections exist at the time it's run, but would need to understand complex rules spread across multiple different event-driven services like Lambda and others.

LMR-GEN-UDT Use Deterministic Telemetry:

• Leaving this as a SHOULD means CSPs can generate probabilistic telemetry which given the nature of the data type, will likely have errors in it. Allowing the possibility of probabilistic telemetry opens the door to highly inaccurate authorization data and made up narratives that a CSP might never have implemented. Highly recommend that this be changed to a "MUST".

[vmangat]

The motivation for moving to a machine readable authorization package is very sound.
The deadlines are reasonable given a lot of work has been done by the industry and OSCAL based authorization packages have been successfully submitted to FedRAMP in the past.

LMR-FRX-LAF List of Approved Formats
Developing a new standard to represent all FedRAMP authorization package requirements is not a trivial task, we have seen this historically with the initial effort from OpenControls, which had to be assumed by NIST in order to produce OSCAL. Prior FedRAMP pilots have successfully proven that OSCAL can meet all requirements to represent the authorization documentation in a machine readable format.
In order to maximize interoperability and reduce the burden for agencies to be able to consume machine readable documents we strongly recommend OSCAL be the only standard required.

LMR-GEN-OAR Ongoing Authorization Requirements
In addition to the annual assessment this requirement should also include monthly continuous monitoring deliverables that include POA&M. The monthly continuous monitoring deliverables will provide the highest ROI for automation.

LMR-GEN-DGI Deterministically Generated Illustrations
The illustrations that are provided today have very high fidelity with a lot of context being provided to the government. Migrating all of this context and maintaining the High Fidelity, to an automated process will require many iterations.
We strongly recommend making this a future requirement.

[Alliancefordigitalinnovation]

The Alliance for Digital Innovation (ADI) appreciates the opportunity to comment on RFC-0024, FedRAMP Rev. 5 Machine-Readable Packages.

We strongly support the transition to Rev5 machine-readable authorization packages using the National Institute of Standards and Technology’s (NIST) Open Security Controls Assessment Language (OSCAL) and view this as a meaningful step toward modernizing FedRAMP. The current assessment model remains heavily dependent on manual workflows, static documents, and longitudinal evidence collection across hundreds of controls under Rev. 5. Structured, machine-readable data has the potential to reduce manual paperwork, streamline annual assessments, enable automation, and accelerate reuse across agencies. If implemented effectively, this shift can improve assessment quality while shortening authorization timelines and reducing friction for cloud service providers (CSPs), agencies, and third-party assessment organizations (3PAOs) alike. As this effort progresses, we encourage FedRAMP to ensure the transition delivers measurable efficiencies and cost savings in practice, particularly by avoiding prolonged parallel requirements for fully duplicative paper-based and machine-readable submissions, and by ensuring that assessment effort and associated costs decrease over time as automation and deterministic telemetry mature.

At the same time, successful implementation will require careful management of stakeholder impacts. CSPs, 3PAOs, and agencies will need to invest in tooling, telemetry integration, and training to operationalize machine-readable workflows, and these transition costs should be acknowledged and planned for. While this transition may disrupt legacy processes, it also creates an opportunity for forward-leaning assessors to differentiate themselves through faster, more consistent, and automation-enabled assessments.

In addition, modernization must extend beyond the requirement that FedRAMP “MUST accept and review” machine-readable packages. Agency readiness will be a critical determinant of success. Some customer agencies may be unable to accept machine readable formats at this point. Close coordination with the Office of Management and Budget (including the Resource Management Organization) and with customer agencies to assess their readiness to ingest and operationalize machine-readable authorization packages is critical. To ensure a credible and effective transition, FedRAMP should establish the necessary operational infrastructure to support machine-readable workflows, including: (1) publishing API-based submission endpoints, (2) providing structured, machine-readable feedback, and (3) establishing SLAs that distinguish review timelines for machine-readable versus non-machine-readable submissions. If additional resources are required to support agency adoption, FedRAMP should proactively identify those needs and work with agencies and OMB to outline a clear path to address them.

With clear guidance, phased implementation support, cross-agency coordination, and a focus on measurable outcomes, RFC-0024 can save significant time and resources while strengthening agencies’ security posture through real continuous monitoring.

Thank you for your consideration on this matter.

[pete-gov]

The following public comment was received via email from Coalfire on Wed Mar 11:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

---

Motivation:
Coalfire is supportive of the movement away from document and spreadsheet submissions as a general concept.

Deadline
Considering the timelines only allows for 6 months between standard development and initial enforcement, this seems like a very short timeline to ensure deliverables, which are still undefined, can be submitted in the required formats from CSPs and 3PAOs and would recommend at least a 12-month adoption period from the date of standard finalization.

LRM-GEN-SDS
This should be removed from the standard and moved to a guidance document as the "SHOULD" language makes this guidance not a requirement. If you make this a requirement, more definition is required around how the separation is determined. For larger CSPs, the intent is always to offer as many of its services to every customer as possible and limited change will exist in the larger packages.

LMR-GEN-ICR and OAR
Referring back to timelines, many initial and annual assessment start 3-6 months before submission. The RFC notes that this is a "9+ month advance warning" but if published on April 1 it will be 5 month notice when some projects are already underway with no definition, specific deliverables or formats have been provided in the RFC to begin transforming CSP and 3PAO processes to meet the requirement delaying submissions and slowing down the process that FedRAMP has said they are trying to accelerate and remove barriers to entry.

LRM-GEN-USC
There is no specificity of the deliverables in the package that require updates after a significant change. If any package elements are updated it should be limited to the overall understanding of the environment such as the SSP. Requiring updates to assessment package elements such as SAR, SAP, etc would not align with normal audit standards and SAP and SAR are provided as part of the SCR packages that should help reduce confusion of validation of the change. Maybe provided more clarification where the confusion is created for agencies and focus updates on those specific deliverables.

LRM-GEN-DGI and UDT
These both over assume the technology and capabilities in the market are advanced enough to fully meet the FedRAMP requirements for machine generated illustrations and narratives. FedRAMP should explore CSP capabilities to generate these with any level of accuracy and completeness before putting labels on all packages. The final standard should not include any recommendations/requirements in a standard such as "Use Deterministic Telemetry" that is deliberately vague and making that a factor or note in the certification of a package.

LMR-GEN-HRV
This requirements lends itself to an understanding that the agencies and FedRAMP may not be ready to consume machine-readable submissions and doing duplicate work in submissions is a burden on both CSP and 3PAO and Coalfire recommends publishing standards in the near term and enforcing delivery when agencies and FedRAMP PMO are ready to accept the machine-readable formats to reduce the additional burden of producing deliverables in multiple formats.

[pete-gov]

The following public comment was received via email from Darktrace on Wed Mar 11:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

Note, this comment used colors to differentiate original text vs response which will not come through in a copy/paste.

---

LMR-FRX-LAM List of Authorization Materials

FedRAMP MUST publish and maintain a list of required information for a Rev5 authorization package, including security controls from the NIST SP 800-53 and FedRAMP-specific assignments and guidance for these controls; once published, FedRAMP will no longer publish or maintain word-processor based templates for these materials.

Note: This will include all standard Rev5 Appendices.

Effective Date: 2PM ET on April 15, 2026 (tentative)

Feedback: Although these templates are labor intensive, it is important for the government to provide examples and context so that existing CSPs can develop materials and keep in line with latest FedRAMP requirements and requisite information. Just the controls and basic guidance may not be sufficient for risk and compliance people to develop appropriate materials. Typically technology folks deal in requirements, not just controls and suggested coverage. This continues to be an issue for many CSP organizations. Perhaps the date can be extend to April 2027, where the government offers current materials as baseline /past experience references, and then publishes a compendium of changes/advances.

Overall, the templates have served as examples. For the new FedRAMP 20x standards and utilizing other methods to measure, having examples of types of measurement and reporting mechanisms will accelerate adoption vs. leave CSPs with their GRC and Dev teams mis-aligned.

LMR-FRX-LAF List of Approved Formats

FedRAMP MUST publish and maintain a list of approved standardized formats for the submission of machine-readable authorization data. Any approved standardized format that has not been adopted by any cloud service providers within 1 year of its inclusion will be removed from the list. This list will include:

Feedback: CSPs/Providers should have multiple formats to choose from as it allows their business to better innovate, support multiple frameworks, and better align their SecDevOps functions, tools, and compliance to suit their business.

LMR-FRX-GPM General Prioritization of Machine-Readable Packages

FedRAMP MUST publicly identify FedRAMP Certified cloud service offerings with machine-readable authorization packages, prioritize their listing in search results, and coordinate additional support for agency adoption of such; this MUST include additional identification, prioritization, and support for services that leverage machine-generated deterministic telemetry or have adopted Rev5 Balance Improvement Releases.

Note: This demonstrates FedRAMP’s strong support for prioritizing and supporting cloud service providers that adopt changing requirements that benefit the federal government and ensures cloud service providers who prioritize security-based improvements to meet changing FedRAMP requirements will benefit from doing so when agencies consider their use.

Effective Date: 2PM ET on April 15, 2026 (tentative)

Feedback: Although rapid adoption of new requirements seems like an initial win, the government should also recognize the millions of dollars of investment that industry has placed in developing and maintaining these systems, as well is training and development of people and processes, and not just technology. Like the government, organizations and their people shouldn’t be forced to re-invest rapidly just to maintain their current systems with new tools and formats forced upon them. This is likely to disrupt other improvement priorities. Refactoring the same compliance shouldn’t override delivering innovation and system improvements.

LMR-GEN-OAR Ongoing Authorization Requirements

Providers MUST submit a full authorization package in an approved machine-readable format for each annual assessment to maintain FedRAMP Certification.

Notes:

This requirement applies to all cloud service providers with a current Rev5 FedRAMP Certification.
This requirement applies to the next annual assessment that is completed after the Effective Date.
Effective Date: 2PM ET on September 30, 2026

Feedback: Putting a full package into machine readable format, although inevitable, still has a few unanswered questions:

How will provenance be maintained for the package contents once moved to some third party machine/software?
How will security of the machine-readable packages be ensured, that they aren’t shared or incorporated via machines into other tools/data sets?
How can the providers ensure that their package is properly interpreted, especially where innovative approaches have been deployed around security functions (i.e., alleviating the risk/use of passwords), when the machine may only look for certain standard features?
How will the entire package be evaluated when it’s unknown if parts are parsed off and evaluated without/with limited context?
FedRAMP should consider digital signing / other guidance for agencies /FedRAMP handling these machine-readable files.
LMR-GEN-USC Updates after Significant Changes

Providers MUST update their machine-readable authorization package after completing significant changes to accurately reflect the current state of their cloud service by 2PM ET at the end of the following month.

Notes:

This addresses a significant problem with legacy authorization packages when cloud service providers make significant changes such as adding or integrating additional services in a way that creates confusion for agencies reviewing their authorization package for potential use because these changes are not documented in the primary materials.
The “end of the following month” is used to simplify setting deadlines; for example, if a significant change is completed on February 12 then the deadline is 2PM on March 31.
Providers are encouraged to exceed this deadline; where relevant, the average number of days it takes a provider to update their primary materials after making a significant change may be tracked and published by FedRAMP.
This only applies to providers after they have submitted their first machine-readable authorization package in alignment with other requirements and effective dates in this document.
Effective Date: 2PM ET on September 30, 2026

Corrective Actions: This requirement will be enforced over a rolling 1 year period as follows:

First action: Public notification and a 3 month grace period to address the requirement; failure or a new occurrence that is not addressed by the end of the grace period will lead to Strike 2.
Second action: Revocation of FedRAMP Certification (including revocation of any legacy exceptions based on FedRAMP Certification status), requiring a completely new initial authorization that meets all FedRAMP requirements for new assessments and authorizations at that time, with a 3 month resubmission penalty.

Feedback: Where will these updated changes (essentially the entire updated package) be stored – that keeps them secure? Today, government systems only house MODERATE or below packages. Is the requirement to have available upon request or submit the updated package to FedRAMP? It is unclear How/where will these updates will be secured while stored.

LMR-GEN-DGI Deterministically Generated Illustrations

Providers SHOULD use machine-generated deterministic telemetry to generate all necessary illustrations and diagrams, including at least the Authorization Boundary Diagram.

Effective Date: 2PM ET on September 30, 2026

Note: The marketplace listing and authorization package for cloud services that do not follow this recommendation will include a warning that illustrations and diagrams are artisanal artifacts and may be unreliable.

LMR-GEN-UDT Use Deterministic Telemetry

Providers SHOULD use machine-generated deterministic telemetry in place of manually or probabilistically generated narratives in authorization data where feasible.

Note: FedRAMP is deliberately leaving this vague and up to the cloud service provider; use of machine-generated deterministic telemetry will be a factor in both initial and ongoing FedRAMP Certification.

Effective Date: 2PM ET on September 30, 2026

Feedback: Although this should be included, for services that utilize multiple IaaS/PaaS services, machine-generated telemetry may not clearly depict the service and boundaries. This should be optional, with better descriptive and data along with vendor generated diagrams where appropriate to support clarity and transparency.

LMR-GEN-HRV Human-Readable Versions

Providers MUST also make human-readable versions of all materials in the machine-readable authorization package available in standard formats, such as Word and Excel, if requested by FedRAMP or an agency.

Notes:
Generation of human-readable versions from structured machine data should be a default capability of any approved format and a relatively trivial task.
This will be necessary for some period of time as industry and agencies adopt machine-readable formats for Rev5 authorization packages.
The grace period for this requirement is co-terminus with the grace period for providing a machine-readable package; that is, once a provider begins sharing machine-readable materials then any grace period expires.
Effective Date: 2PM ET on September 30, 2026

Feedback: Although rapid adoption of new requirements seems like an initial win, the government should also recognize the millions of dollars of investment that industry has placed in developing and maintaining these systems, as well is training and development of people and processes, and not just technology. Like the government, organizations and their people shouldn’t be forced to re-invest rapidly just to maintain their current systems with new tools and formats forced upon them. This is likely to disrupt other improvement priorities. Refactoring the same compliance shouldn’t override delivering innovation and system improvements.