This is the first cluster of the 124 CSP requirements behind FedRAMP 20X — three requirement sets that together define what FedRAMP is actually evaluating, and against what baseline:
- Minimum Assessment Scope (MAS) — 5 CSP requirements
- Secure Configuration Guide (SCG) — 9 CSP requirements
- Using Cryptographic Modules (UCM) — 3 CSP requirements
17 CSP requirements total. It's the smallest cluster, but it shapes every other piece of work in your 20X program. Get these wrong and most of your KSI evidence has to be rebuilt.
For the full breakdown of the 124, start with the pillar post: FedRAMP 20X: Why 60 KSIs Actually Mean 124 Requirements for Cloud Service Providers.
Minimum Assessment Scope (MAS): 5 CSP requirements
MAS defines what is in scope for FedRAMP 20X assessment. It's the single most consequential decision in any 20X package because it determines what every other piece of work has to cover.
Three things make MAS distinctive under 20X:
It must be addressed persistently, not once
FedRAMP defines "persistently" as an activity that occurs in a steady, repeated way over a long period — with intentional, documented responsible parties, cycles, and actions. MAS isn't a one-time scoping memo at the start of the authorization; it's an ongoing artifact that has to be reviewed and updated as your service evolves.
It expects machine-readable representation
MAS isn't satisfied by a static PDF describing your boundary. It expects authorization data to be expressible in a format an automated reviewer can consume.
It's coupled to your KSI evidence
Every KSI applies to "all aspects of the cloud service offering within the FedRAMP Minimum Assessment Scope." Any boundary ambiguity flows directly into evidence ambiguity. A vague MAS produces vague KSI proof.
Practical guidance: MAS should be one of the first artifacts your team produces, owned by engineering (usually security architecture or platform engineering) with compliance reviewing rather than authoring. A MAS that's owned outside engineering tends to drift from the actual system within a quarter.
Secure Configuration Guide (SCG): 9 CSP requirements
SCG is the document — and the maintenance commitment — that tells your federal agency customers how to configure your service securely on their end.
Tenant-side admin choices around SSO providers, IP allow-lists, retention settings, integrations, and encryption-key management can either preserve or undermine the security posture you've validated at the platform level. Under 20X, that configuration guidance becomes a formal deliverable.
The SCG must:
- Document the customer-side settings that materially affect security
- Recommend the secure baseline for each
- Be maintained alongside the service as features change
- Be discoverable by any agency reviewing the authorization
Practical guidance: For CSPs that already publish hardening guides or "secure deployment" documentation for enterprise customers, the SCG often starts as a structured pull from those existing sources. The harder commitment is keeping it accurate as the product evolves — not just being true on the day of authorization.
Using Cryptographic Modules (UCM): 3 CSP requirements
UCM explicitly documents the cryptographic modules your cloud service offering relies on, and how they're being used. Reviewers expect to see:
- Which validated modules are in use
- Where they're used in the architecture (data at rest, data in transit, key management, signing operations, etc.)
- Which validation certificates apply
- How module updates are managed without breaking the validation chain
UCM has only 3 CSP requirements, but it intersects with several KSI themes — particularly Service Configuration (SVC) for transit encryption and Cloud-Native Architecture (CNA) for component integrity.
Practical guidance: Pin the cryptographic baseline early. UCM decisions ripple into procurement, engineering, and operations. Pinning the baseline early gives the rest of the team something stable to build against.
How the three fit together
Each requirement set answers a different question about your authorization surface:
A final pattern worth flagging: version everything. All three artifacts will change as the service changes. Keeping them in version control — alongside the rest of the system — keeps them honest and makes the persistent-review requirement much easier to satisfy.
What's next
The next cluster is where most of the engineering investment in a 20X program actually lands: Persistent Validation and Assessment (PVA) and Vulnerability Detection and Response (VDR) — 41 CSP requirements that build the engine continuously proving your KSIs are working.