FedRAMP 20x: Review Customer Settings Against Secure Defaults

An agency’s current settings can differ from a provider’s recommended defaults because the customer changed its configuration, the provider changed its recommendation, or both. A useful review makes those differences understandable before anyone changes the live service.

For 20x Class B and C teams, the Secure Configuration Guide enhanced capabilities support that comparison. Each uses SHOULD. They recommend capabilities that help customers make decisions; they do not prescribe a mandatory auto-remediation platform.

Preserve the scope of each recommended capability

The account definitions include corresponding roles and similar capabilities used to assign those privileges. Avoid narrowing a review to accounts whose display names happen to contain “admin.”

SHOULD has a defined meaning: valid reasons for departure may exist in particular circumstances, but their implications are understood and carefully weighed, and handling decisions are documented in security documentation. Preserve that treatment instead of silently turning the recommendations into either universal MUSTs or ignorable suggestions.

Compare a settings snapshot with a named default version

The following is editorial review practice, not an official record format. Start with the actual customer environment, a current settings export and the relevant version of the provider’s recommended defaults. Record the export time, guide version and scope so the agency can understand what was compared.

Then distinguish three situations:

• Customer setting changed: the recommendation stayed the same, but the live value changed. Identify the change and its stated purpose with the agency owner.
• Provider default changed: the live value stayed the same, but the recommendation changed. Use the release history to explain the new recommendation and its security implication.
• Both changed: preserve the earlier and current values on both sides before deciding whether the apparent difference represents a new issue.

For example, an agency setting may still match default version 2 while the provider now recommends a different value in version 3. Label the comparison against version 3 and explain the recommendation’s rationale. Calling the setting an unauthorized change would assume facts the comparison alone does not establish.

Link each difference to the relevant guidance and identify the agency decision owner. Keep unavailable settings or unclear mappings visible as review questions instead of presenting an incomplete comparison as a complete match.

Hand the configuration decision to the agency owner

Ongoing agency authorization guidance tells agencies to review provider Secure Configuration Guides and keep agency-managed settings aligned with the agency’s authorization. FedRAMP evidence supports that work; it does not replace the agency’s monitoring of its configurations and risk tolerance.

A comparison result therefore supports a decision about the agency’s use. It is not automatically a violation finding or permission for the provider to reset customer settings. Record the agency’s chosen action or rationale, the owner and any follow-up needed. Where a change is agreed, retain enough context to compare the resulting state with the intended outcome.

SCG-CSO-SDF separately says providers SHOULD set recommended secure defaults for top-level administrative and privileged accounts when initially provisioned. Keep that initial-provisioning recommendation distinct from an ongoing instruction to overwrite existing settings.

Apply the existing SCG dates

SCG lists March 1, 2026 for both obtaining initial certification and maintaining ongoing certification, with grace ending July 1, 2026. It does not use a next-assessment grace period. These are existing ruleset dates; clearer date labels do not create a new customer-settings reset deadline.

Questions to resolve during a review

Is an API the only acceptable comparison approach?

SCG-ENH-API recommends an API or similar capability for viewing and adjusting settings. Comparison, exports, machine-readable guidance and version history have their own SHOULD provisions.

Should customer settings exports be public?

The enhanced-capability rules describe customer comparison and export capabilities, not a direction to publish customer configurations. Keep review artifacts within the customer’s appropriate access arrangements.

For related work, see authoring the Secure Configuration Guide and documenting recommended-rule decisions.