RFC-0027 FedRAMP Rev5 Security Controls Baseline Update for AC, AT, AU, CA, and CM Control Families

[rhoesing]

RFC-0027 FedRAMP Rev5 Security Controls Baseline Update for AC, AT, AU, CA, and CM Control Families

❓ 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 and Q&A for RFCs related to Rev5 Updates (RFCs 0026, 0027, 0028, 0029, & 0030) thread. Thank you!

Status: Open
Start Date: March 19, 2026
Closing Date: April 22, 2026

Summary

This is a technical RFC that proposes updates to the Additional FedRAMP Security Technical Controls Requirements and Guidance for FedRAMP Rev5 baselines.

To save space and to limit the breadth of a single RFC, this technical document shows only the proposed changes to the current baseline document and is restricted to a few control families. If verbiage is being updated, only the specific wording that is to be changed is identified in the old verbiage section. If the verbiage to be added is not replacing previous verbiage, but being added, it will be identified as “NEW” in the old verbiage section.

Since this spreadsheet covers hundreds of controls across multiple tabs and sections, only those specific controls, sections, and tabs identified are being proposed for updates. If it is not mentioned below, changes are NOT being proposed.

Commenters are advised to please mention specific controls in their comments!

This RFC addresses controls in the following families:

• Access Control (AC)
• Awareness and Training (AT)
• Audit and Accountability (AU)
• Assessment, Authorization and Monitoring (CA)
• Configuration Management (CM)

Motivation

Many Rev5 FedRAMP Requirements and Guidance statements are based on outdated approaches that predated the release of the FedRAMP Authorization Act and M-24-15. This set of Requirements and Guidance needs a refresh to match FedRAMP’s current rules and approach.

The updates formalized after this RFC will be included in the FedRAMP Consolidated Rules for 2026. That set of rules will be valid until December 31, 2028. FedRAMP will provide a transition plan for adopting any new guidance that will enable cloud service providers to update their approach as part of their annual assessment as appropriate.

These changes are designed to lower the burden for cloud service providers and eliminate previous pain points.

Additionally, NIST released 800-53 Rev 5.2.0 in August of 2025. While this update was minor, control updates from NIST will require updates to FedRAMP Security Control Baseline in order to reflect this update. These changes will happen without public comment through FedRAMP since these are direct reflections of NIST changes. As subsequent iterations of the FedRAMP Security Control Baseline are published, it is FedRAMP’s intent only to carry over the following information from NIST 800-53; Control Family, Control Name, and Control ID. Following this will be FedRAMP-Defined Assignment / Selection Parameters and additional FedRAMP Requirements and Guidance.

Proposed Changes to Access Control Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

AC-02: Account Management

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: NEW
Proposed Change: a. Accounts types should align to those accounts identified within the FedRAMP Secure Configuration Guidance where applicable.
Rationale: Alignment with the FedRAMP Secure Configuration Guidance (SCG).

AC-10: Concurrent Session Control

Tabs Affected: High Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: AC-10-2 [three (3) sessions for privileged access and two (2) sessions for non-privileged access]
Proposed Change: AC-10-2 [one (1) session for Top-level administrative, three (3) sessions for privileged access, and two (2) sessions for non-privileged access]
Rationale: Alignment with the FedRAMP Secure Configuration Guidance (SCG).

Proposed Changes to Awareness and Training Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

AT-03 Role-based Training:

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: NEW
Proposed Change: a. Top-Level Administrative and Privileged Accounts Secure Configuration Guidance must be included as part of role based training where applicable.
Rationale: Alignment with the FedRAMP Secure Configuration Guidance (SCG).

Proposed Changes to Audit and Accountability Family

No changes are being proposed

Proposed Changes to Assessment, Authorization, and Monitoring Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

CA-05: Plan of Action and Milestones

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: CA-5 (b) [at least monthly]
Proposed Change: CA-5 (b) [at least monthly for traditional FedRAMP Processes] [every three months if opting into Collaborative Continuous Monitoring BIR] [Monthly Activity Report in lieu is due every month if opting into Vulnerability and Detection Response BIR]
Rationale: Updated based on BIRs

CA-05: Plan of Action and Milestones

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: CA-5 Requirement: POA&Ms must be provided at least monthly. CA-5 Guidance: Reference FedRAMP-POAM-Template
Proposed Change: CA-5 Requirement: POA&Ms must be provided at least monthly for traditional FedRAMP processes. For those opting into Collaborative Continuous Monitoring BIR, Ongoing Authorization Reports must be provided every three months. For those opting into Vulnerability Detection and Response BIR, a Monthly Activity Report is also required.
CA-5 Guidance: Reference FedRAMP-POAM-Template [traditional], CCM-OAR-AVL for those opting into Collaborative Continuous Monitoring BIR, and VDR-TFR-MHR for those opting into Vulnerability Detection and Response BIR
Rationale: Updated based on BIRs

CA-05: Plan of Action and Milestones

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: Continuous Monitoring Periodicity
Current Verbiage: CA-5 (b) [at least monthly]
Proposed Change: CA-5 (b) [at least monthly for traditional FedRAMP Processes] [Ongoing Activity Report in lieu is due every three months if opting into Collaborative Continuous Monitoring BIR] [Monthly Activity Report in lieu is due every month if opting into Vulnerability and Detection Response BIR]
Rationale: Updated based on BIRs

CA-06: Authorization

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: CA-6 (e) [in accordance with OMB A-130 requirements or when a significant change occurs]
Proposed Change: CA-6 (e) [in accordance with OMB A-130 requirements or when a significant change occurs for those NOT participating in the SCN BIR]
Rationale: Updated based on BIRs

CA-07: Continuous Monitoring

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: CA-7 Requirement: Operating System, Database, Web Application, Container, and Service Configuration Scans: at least monthly. All scans performed by Independent Assessor: at least annually.
CA-7 Requirement: CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (ConMon) approach described in the FedRAMP Continuous Monitoring Playbook. This requirement applies to CSOs authorized via the Agency path as each agency customer is responsible for performing ConMon oversight.
CA-7 Guidance: FedRAMP does not provide a template for the Continuous Monitoring Plan. CSPs should reference the continuous monitoring guidance provided in the FedRAMP Continuous Monitoring Playbook when developing the Continuous Monitoring Plan.
Proposed Change: Changes to CA-7 are being proposed in RFC-0026 Clarifying CA-7 Continuous Monitoring Expectations for Rev5 Providers, under the “CA-7 Additional FedRAMP Requirements and Guidance” section. Any comments associated with CA-7 should be submitted under RFC-0026.
Rationale: Updated based on BIRs and implementation issues within agencies.

Proposed Changes to Configuration Management Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

CM-06: Configuration Settings

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: CM-6 (a) Requirement 1: The service provider shall use the DoD STIGs or Center for Internet Security guidelines to establish configuration settings;
CM-6 (a) Requirement 2: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).
Proposed Change: CM-6 (a) Requirement 1: The service provider shall use Security Configuration Guidelines (See CM-6) to establish instructions on how to securely access, configure, operate, and decommission top-level administrative accounts within the cloud service offering. This MUST include explanations of security-related settings that can be operated only by top-level administrative accounts and their security implications. This SHOULD include explanations of security-related settings that can be operated only by privileged accounts and their security implications.
CM-6 (a) Requirement 2: The service provider shall use the DoD STIGs or Center for Internet Security guidelines to establish configuration settings;
CM-6 (a) Requirement 3: The service provider shall ensure that checklists for configuration settings are Security Content Automation Protocol (SCAP) validated or SCAP compatible (if validated checklists are not available).
Rationale: Updated based on SCG BIR

CM-07: Least Functionality

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: CM-7 (b) Requirement: The service provider shall use Security guidelines (See CM-6) to establish list of prohibited or restricted functions, ports, protocols, and/or services or establishes its own list of prohibited or restricted functions, ports, protocols, and/or services if STIGs or CIS is not available.
Proposed Change: CM-7 (b) Requirement: The service provider shall use Security Configuration Guidelines (See CM-6) to establish instructions on how to securely access, configure, operate, and decommission top-level administrative accounts within the cloud service offering as well as provide a list of prohibited or restricted functions, ports, protocols, and/or services or establishes its own list of prohibited or restricted functions, ports, protocols, and/or services if STIGs or CIS is not available.
Rationale: Updated based on SCG BIR

CM-08: System Component Inventory

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: CM-8 (b) [at least monthly]
Proposed Change: CM-8 (b) [at least monthly for those CSPs following traditional Rev 5 processes]. Those CSPs participating in VDR and CCM BIRs are exempt from this formal reporting requirement.
Rationale: Updated based on BIRs

CM-08: System Component Inventory

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: CM-8 Requirement: must be provided at least monthly or when there is a change.
Proposed Change: CM-8 Requirement: must be provided at least monthly or when there is a change for those CSPs following traditional Rev 5 processes. Those CSPs participating in VDR and CCM BIRs are exempt from this formal reporting requirement.
Rationale: Updated based on BIRs

CM-12: Information Location

Tabs Affected: Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: CM-12 Requirement: According to FedRAMP Authorization Boundary Guidance
Proposed Change: CM-12 Requirement: According to FedRAMP Boundary Guidance for those following traditional FedRAMP processes and the Minimum Assessment Scope (MAS) for those who are voluntarily participating in the Rev 5 MAS BIR.
Rationale: Updated based on BIRs

CM-12(1): Information Location | Automated Tools to Support Information Location

Tabs Affected: Moderate Baseline, High Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: NEW
Proposed Change: CP-2 (8) - [essential]
Rationale: Parameter previously undefined

[jtb-p]

Please clarify CM-12(1) parameters. CP-2(8) does not refer to an information type, but rather essential mission functions. Is this possibly a copy/paste error from the new CP 2(8) parameters?

[jtpickering]

For those less familiar, I suggest spelling out acronyms the first time they are used in a document and providing permalinks to referenced documents.

CA-05, Sections affected: FedRAMP-Defined Assignment / Selection Parameters. I suggest scrapping this update and instead using the standard established in the -01 controls. Suggestion:

• b. Update existing plan of action and milestones (POAM or POA&M) [Select one: at least monthly for traditional FedRAMP Processes; if opting into the Collaborative Continuous Monitoring Balance Improvement Release (BIR), submit the Ongoing Activity Report in lieu of the POAM every three months; if opting into the Vulnerability and Detection Response BIR, substitute the Monthly Activity Report in lieu of the POAM every month] based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.
  In this way, the Continuous Monitoring Periodicity section for CA-5 can be eliminated.

[Dn606]

CA-05: Plan of Action and Milestones
Current Verbiage: CA-5 (b) [at least monthly]
Proposed Change: CA-5 (b) [at least monthly for traditional FedRAMP Processes][every three months if opting into Collaborative Continuous Monitoring BIR] [Monthly Activity Report in lieu is due every month if opting into Vulnerability and Detection Response BIR]

Could we please clarify what "traditional FedRAMP Processes", "opting into Collaborative Continuous Monitoring BIR", "if opting into Vulnerability and Detection Response BIR" means? Thank you

[BClev]

CM-6 Moderate and High baselines currently have: CM-6 (a) Requirement 1: The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available.
Only low has the "Current verbiage" noted: "The service provider shall use the DoD STIGs or Center for Internet Security guidelines to establish configuration settings;"

Unless the update is both meant to enforce the SCG AND means that the PMO going to permit High and Moderate CSPs to use STIGs or CIS (versus currently where it's CIS only if there's no STIG) - which I think CSPs would welcome due to the questionable applicability of an existing STIG in all cases, but that's another topic - then it should be made clearer that the this is just to enforce the SCG reqs.

[wisecryptic]

CM-06/CM-07

In short: I recommend finding a different home for the SCGs because they do not follow the spirit of configuration management under those controls. If they must reside in a control, AC‑2 or AC‑6 are a better fit( My parameter choices would be AC-2d3 or AC-2(7)add'l requirement). This may sound like a small distinction, but getting this right will save a lot of headache in the future for agencies implementing the control, assessors keeping scope of the control, and CSPs tracking the control.

The longer rationale
theoretical discussion
This proposal represents a significant shift in how these controls are conceptualized. The CM family—Configuration Management—was designed to address baseline configuration control. CM begins with the initial configuration baseline(CM-2), continues with change control (CM-3), and then breaks into more detailed expectations around the state and management of those changes.

CM‑06 is about standardized system configuration settings—establishing what standard configurations are and determining how an organization adheres to them. NIST specifically calls out USGCB, STIGS, etc as examples.
In contrast, “instructions” that describe the “how to” of accessing, configuring, operating, and decommissioning top‑level accounts are typically part of what most CSPs refer to as implementations. If this material must live in a configuration setting control, we should be looking for recommended configurations, not operational instructions.

CM-07, least function is slightly more nuanced but follows the same basic reasoning. parameters should focus on limiting functionality. "accessing, configuring, operating, and decommissioning" is information far beyond the scope of what CM-07 should be.

Practical implementation
CM‑06
CM‑06 Looking at the big picture, I believe that CM-06 could benefit from more flexibility. While STIG implementation should remain an acceptable standalone response, it should also fit into a broader configuration schema that contributes to the configuration baseline (if we are focusing on security practice, not security theatre, that is).
However, the SCG should not live here unless the customer is providing machine‑implementable artifacts or tools that directly configure elements referenced in the SCG. CM‑06 is not the place for instructions or walkthroughs.
CM‑07
CM‑07 Again, thinking big picture, I would change the STIG requirement from “shall” to “may” because:

• STIGs are already required in CM‑06, making the CM‑07 inclusion redundant.
• NIST’s discussion and intent for CM‑07 do not include STIG expectations.
• While STIGs can help satisfy the control, they are not the sole or even primary focus here; the enhancements to CM‑07 clearly point toward a more composite, multi‑layered approach.

Regardless, the SCG should not be inserted in CM-07 either. It distracts from the core intent of least functionality. The SCG is about secure implementation—not least functionality. While the two can overlap, instructions and detailed how‑tos are not examples of least functionality.

So where should the SCG go?
For this particular requirement, I would place it under the AC family, where responsibility for customer‑administered accounts is already delegated. AC‑2 or AC‑6 remain the most logical fits.
However, if FedRAMP anticipates future SCG‑type requirements that fall outside the AC scope but still require explicit assessment, there are two possible approaches:

Approach 1: Align each SCG requirement with its corresponding NIST control complement.

• This preserves alignment with NIST’s structure and the community’s shared mental model.
• The downside is fragmentation—SCG content would be distributed across multiple controls.
• A separate guide would be needed to identify where SCG‑related parameters live.

Approach 2: Add the SCG requirement to PL‑2 or attach it as a required appendix in the SSP template.

• This keeps related material in one place.
• It also aligns with existing FedRAMP patterns, for better or worse.

This may feel like a small placement issue, but I strongly believe we should not distort the original NIST intent of CM‑06 and CM‑07 with requirements of this nature. While occasionally forcing a “square peg into a round hole” helps expose the need for a new square hole, in this case I think existing compliance scaffolding already provides the right home for this content without bending the CM controls out of shape.

[vedigaurav]

Gap #1: Fragmented Control Update Visibility
Issue: The RFC presents changes across multiple control families in a spreadsheet-style, partial update format, making it difficult to understand cumulative impact across the baseline.
Recommendation: Provide a consolidated “redlined baseline view” or diff summary showing all updates in context to improve traceability and review efficiency.

Gap #2: Insufficient Rationale Depth for Control Changes
Issue: Many updates cite “alignment with Secure Configuration Guidance (SCG)” or BIRs without explaining risk-based justification or expected security outcomes.
Recommendation: Include risk rationale and intended security impact for each control change to help CSPs and assessors interpret intent consistently.

Gap #3: Ambiguity in BIR vs Traditional Path Equivalence
Issue: The RFC introduces alternative requirements for BIR participants (e.g., reduced reporting frequency) without clarifying equivalence in assurance levels.
Recommendation: Define equivalency criteria or assurance benchmarks to demonstrate that BIR-based approaches meet or exceed traditional control objectives.

Gap #4: Lack of Implementation Examples
Issue: Updated requirements (e.g., account types alignment, role-based training enhancements) lack practical implementation examples, increasing interpretation variability.
Recommendation: Provide reference implementations or sample evidence artifacts for selected controls to standardize adoption.

Gap #5: No Explicit Impact on Assessment Procedures
Issue: While control requirements are updated, there is limited guidance on how these changes affect 3PAO assessment methods, test cases, or evidence expectations.
Recommendation: Include assessment guidance updates or mappings to ensure consistent evaluation across assessors.

Gap #6: Incomplete Coverage of Inter-Control Dependencies
Issue: Changes to controls (e.g., AC, CM, CA families) may introduce dependencies or conflicts across control implementations, but these are not addressed.
Recommendation: Document key inter-control relationships and dependency considerations to avoid inconsistent implementations.

Gap #7: Limited Guidance on Automation Alignment
Issue: The RFC aligns with modernization goals but does not explicitly address how updated controls should support automation or machine-readable compliance (e.g., OSCAL).
Recommendation: Include guidance on automation-ready control implementation and reporting, aligning with broader FedRAMP modernization efforts.

Gap #8: Transition Timing and Phasing Ambiguity
Issue: While a transition plan is mentioned, there is no clarity on prioritization, sequencing, or phased adoption of control updates.
Recommendation: Provide a phased adoption roadmap (e.g., control families by priority or impact level) to reduce implementation risk.

[rhoesing]

Comment from Raj P.

Please find below my public comments on RFC-0027: FedRAMP Rev5 Security Controls Baseline Update for AC, AT, AU, CA, and CM Control Families.

Comment 1
AC-02 — Account Management
No comment. Matching account types defined in account management to those referenced in FedRAMP Secure Configuration Guidance will increase consistency during assessments and minimize ambiguity during authorization review.
AC-10 — Concurrent Session Control
Limiting top level administrative accounts to single session is fair. FedRAMP needs to provide guidance if this control is meant to be enforced at the OS/network layer, application layer, or both. Additionally, FedRAMP should provide guidance as to how this control is implemented/enforced for IaaS, PaaS, and SaaS models.
AT-03 — Role-Based Training
FedRAMP should specify if this applies to all users with privileged account access or if this only applies to dedicated administrators. Along those lines, FedRAMP needs to provide a standard that better defines "where applicable" so that organizations can apply it consistently and in a manner that is proportionate.

Comment 2
AU — Audit and Accountability
No change suggested. No comment. Future Recommendation: Provide guidance around acceptable automated audit analysis capabilities and their effects on ConMon reporting requirements.
CA-05 — Plan of Action and Milestones
Separate tracks for traditional, CCM BIR, and VDR BIR reporting is greatly appreciated. FedRAMP should specify the mapping of traditional POA&M components to the newly developed reporting standards for adequate oversight.
CM-06 — Configuration Settings
Requirement 1 is required and supported. FedRAMP needs to specify what SHOULD be included in Security Configuration Guidance. Is the Security Configuration Guidance a standalone document, or is it part of the SSP? Does the language of SHOULD allow assessors to elevate findings if guidance is not present?

Comment 3
CM-07 — Least Functionality
Clear, concise. No additional comment. Matches CM-06.
CM-08 — System Component Inventory
Allows vendors to opt-out of inventory for VDR/BIR which lessens burden. Need FedRAMP to define minimum acceptable automated inventory standards to meet this requirement. This would include minimum discovery cycles, ephemeral/container components, and tie into CM workflow.
CM-12 — Information Location
Revision ties CM-12 control to MAS BIR boundary framework. No additional comment.
CM-12(1) — Automated Tools to Support Information Location
This special parameter has already been defined in CP-2(8). Consider revising the language to "CM-12(1) — [essential]"
IA-8 — Identification and Authentication Through Mobile Devices
Requiring an OTP is in-line with industry best practices. FedRAMP needs to allow for compliance of legacy applications that do not support OTP without major rewrites.

[OG-of-the-realms]

AC-02 a.- there are use cases where account types would be customer defined & not defined by the CSP. Also uses cases where AC-02(a) account types might be defined by the CSP for internal account types that would not be enumerated in the SCG.
RECOMMEND: Adding for CSP and Customer defined parameter.

AT-03: CSPs do not provide Role-Based Training for customers. Since the SCG is intended for consumption by customers, this control addition doesn't make sense, except to force a control inheritance pass-through from the CSP to an Agency - which already has an obligation to provide holistic role-based training separately under FISMA.
RECOMMEND: Strike or further clarify

All other proposed changes: Concur with all other changes and alignment on intent.