GSA CUI Compliance Guide: NIST 800-171 Requirements & 9 Authorization Showstoppers to Avoid

What Changed in Revision 1

Revision 1 represents a technical update rather than a fundamental policy shift. GSA has aligned its procedural guide with NIST’s latest publications while streamlining its presentation of critical requirements.

Updated NIST Baselines

The most significant change is the update from NIST SP 800-171 Revision 2 to Revision 3. While many core requirements remain conceptually similar, Revision 3 introduces refined language and updated assessment procedures documented in NIST SP 800-171A Revision 3.

The revision also incorporates the draft NIST SP 800-172 Revision 3, which provides enhanced security requirements for organizations protecting high-value assets. While not all 800-172 requirements apply to every system, organizations should review the enhanced controls to determine applicability based on their CUI categorization and threat environment.

Streamlined Showstopper Requirements

Perhaps the most practitioner-focused change is the revision of Appendix C. The original guide included broader security and privacy requirements. Revision 1 refocuses Appendix C exclusively on the 9 showstopper requirements—those security controls that, if not fully implemented, will preclude system authorization.

This clarity is significant. Organizations can now immediately identify which requirements are non-negotiable versus those that may be addressed through compensating controls or risk acceptance mechanisms.

Reorganized Reference Materials

References have been consolidated into a dedicated appendix, improving document usability. This organizational change doesn’t alter requirements but makes it easier for compliance teams to locate authoritative sources when documenting control implementations.

Who Is Impacted by This Revision

Systems That Must Comply

Revision 1 applies to nonfederal systems that process, store, or transmit CUI on behalf of GSA. Specifically, this includes systems where:

• CUI resides in a nonfederal system or organization
• The organization is not collecting or maintaining information on behalf of a federal agency or operating a system on behalf of an agency (such systems fall under FISMA requirements)
• No specific safeguarding requirements for the CUI category exist in the CUI Registry beyond those in NIST SP 800-171

The system’s FIPS 199 confidentiality categorization must be Moderate based on the presence of CUI. Only systems meeting this threshold follow the process outlined in this guide.

Organizations Requiring Action

Three categories of organizations are directly impacted:

1. Systems Undergoing Initial Authorization

New systems entering the GSA authorization process must align with NIST SP 800-171 Revision 3 from the outset. SSPPs submitted under the previous revision may require updates before proceeding to assessment.

2. Systems Due for Reauthorization

Systems approaching their three-year reauthorization cycle must update documentation to reflect Revision 3 requirements. The independent assessment will validate against the updated baseline.

3. Systems with Continuous Monitoring Obligations

Authorized systems must update their SSPPs during the next annual update cycle to incorporate Revision 3 language and assessment criteria. While immediate re-assessment is not required, organizations should proactively identify any gaps between current implementations and the updated requirements.

Who Is Not Materially Impacted

Several categories of systems and organizations face minimal impact:

• Systems categorized as FIPS 199 Low (no CUI present)
• FISMA-governed systems operated on behalf of a federal agency
• Systems processing CUI categories with specific safeguarding requirements that supersede NIST SP 800-171
• FedRAMP-authorized cloud services (which follow the FedRAMP process)
• Systems not processing GSA CUI or not under GSA contract

It’s important to note that while Revision 1 updates the baseline, organizations that had already fully implemented NIST SP 800-171 Revision 2 controls will find most requirements conceptually similar. The changes are largely taxonomic and procedural rather than requiring wholesale architectural redesign.

The 9 Showstopper Requirements

Revision 1 clarifies that 9 specific security requirements are showstoppers, meaning they must be fully implemented before GSA will authorize a system. Partial implementation or plans to implement are not sufficient for these controls. Organizations should prioritize assessment and remediation of these requirements above all others.

The following table identifies each showstopper, its control family, and the specific failure condition that blocks authorization. All nine requirements stem from NIST 800-171.

Requirement	Control Family	Showstopper Trigger
03.01.02	Access Control	Access enforcement not aligned with approved authorization policies
03.01.12	Access Control	Remote access lacks usage restrictions, configuration controls, or authorization requirements
03.05.03	Identification and Authentication	Multi-factor authentication absent for any privileged or non-privileged account
03.11.02	Risk Assessment	Vulnerabilities not scanned at required frequency or not remediated within timeframes
03.13.01	System and Communications Protection	Boundary communications unmonitored, network segmentation absent, or external connections unmanaged
03.13.08	System and Communications Protection	CUI transmitted or stored without cryptographic protection
03.13.11	System and Communications Protection	Cryptography protecting CUI confidentiality not properly implemented or documented
03.14.01	System and Information Integrity	System flaws not identified, reported, or corrected; security updates not installed timely
03.16.02	System and Services Acquisition	End-of-life or unsupported system components in production without vendor support

Why These Nine?

These requirements represent authorization-blocking failures, not maturity gaps. Key distinctions:

• Each one can invalidate authorization regardless of how sophisticated your other controls are
• GSA reviewers and independent assessors flag these first, before deeper testing begins
• No compensating controls, risk acceptance, or POA&M entries are permitted for these requirements

Practical Implications: What Organizations Often Overlook

While the showstopper requirements are clearly defined, organizations frequently encounter implementation challenges that are not immediately obvious from the requirement text. Here are the areas where preparation often falls short:

The MFA Implementation Gap

Requirement 03.05.03 mandates MFA for both privileged and non-privileged accounts. Organizations often implement MFA for user-facing applications but overlook:

• Administrative access to cloud management consoles (AWS, Azure, GCP)
• Jump servers and bastion hosts used for infrastructure access
• Service accounts and API access credentials
• VPN connections to development or staging environments that also handle CUI

Additionally, not all MFA methods meet GSA’s phishing-resistance expectations. SMS-based one-time passwords and email-delivered codes are increasingly viewed as insufficient. Organizations should implement FIPS 140-2 validated authenticators, hardware tokens, or PKI-based authentication where possible.

Encryption: It’s Not Just About TLS

Requirements 03.13.08 and 03.13.11 mandate encryption of CUI during transmission and storage. Organizations typically implement TLS for web traffic and consider this sufficient. However, assessors will validate

• Encryption of database storage (not just encrypted connections to the database)
• Encryption of backups, including offsite and cloud-based backups
• Encryption of CUI in transit between internal system components, not just at the external boundary
• Use of FIPS 140-2 validated cryptographic modules with documented certificate numbers

The requirement to document certificate numbers for FIPS-validated modules is frequently overlooked. Organizations must maintain a current inventory of cryptographic implementations and their validation status.

Vulnerability Scanning Beyond Weekly OS Scans

Requirement 03.11.02 requires vulnerability scanning and timely remediation. Organizations often focus exclusively on operating system vulnerabilities while neglecting:

• Container image vulnerabilities (both base images and application layers)
• Web application vulnerabilities (which require different scanning tools and methodologies)
• Database-specific vulnerabilities and configuration weaknesses
• Third-party libraries and open-source components embedded in custom applications

GSA expects authenticated scanning where possible, meaning scan tools must have valid credentials to thoroughly inspect system configurations. Unauthenticated scans provide incomplete results and will not satisfy assessment requirements.

The End-of-Life Software Problem

Requirement 03.16.02 prohibits unsupported system components. Organizations frequently discover during assessment that they have:

• Legacy operating systems still in use (Windows Server 2012, CentOS 7, etc.)
• Databases running versions no longer receiving security updates
• Web servers or middleware platforms past their end-of-life dates
• Vendor appliances or proprietary software that the vendor no longer supports

This is a showstopper requirement—you cannot accept the risk of unsupported software and proceed to authorization. The software must be upgraded, replaced, or removed from the system boundary. If replacement is not technically feasible, the organization must provide detailed documentation of compensating controls, but GSA retains final determination of acceptability.

Assessment and Authorization Process Changes

Revision 1 maintains the five-phase Risk Management Framework process (Prepare, Document, Assess, Authorize, Monitor) but introduces updated assessment procedures aligned with NIST SP 800-171A Revision 3.

Independent Assessor Requirements

Independent assessments must be conducted by either:

• An assessment organization approved by GSA OCISO prior to selection, or
• A FedRAMP-accredited Third Party Assessment Organization (3PAO)

GSA will not accept assessments from organizations lacking appropriate independence or technical qualifications. Organizations should engage assessors early in the authorization process to avoid delays during the assessment phase.

What Gets Assessed

The Security Assessment Report (SAR) must include evidence from:

• Security and privacy requirements validation using the GSA CUI Nonfederal Test Case Workbook
• Authenticated vulnerability scans for operating systems, databases, and containers
• Configuration compliance scans against NIST guidelines or CIS benchmarks (minimum 85% compliance threshold)
• Web application vulnerability scans (authenticated where applicable)
• Penetration testing (recommended for internet-accessible systems)

All Critical and High vulnerabilities must be remediated or mitigated before authorization. Organizations cannot simply acknowledge these findings in a Plan of Action and Milestones (POA&M) and proceed—the risk must be addressed.

Common Assessment Failures

Based on experience with the authorization process, organizations most frequently fail assessment due to:

1. Incomplete System Boundary Definition

System boundary diagrams that omit administrative access paths, third-party integrations, or shared services. The authorization boundary must include all components that process, store, or transmit CUI—including jump servers, monitoring systems, and log aggregation infrastructure.

2. Inadequate Security Control Narratives

System Security and Privacy Plans that restate the requirement without describing the actual implementation. Control narratives must explain who, what, where, when, why, and how the control is implemented, with specific references to tools, configurations, and procedures.

3. Missing Evidence

Inability to produce configuration exports, scan results, or documentation to validate control implementations. Organizations should maintain a curated evidence library aligned with assessment objectives before the assessor arrives.

4. Scan Scope Deficiencies

Vulnerability or configuration scans that cover only a subset of in-scope assets. While representative sampling may be acceptable for large homogeneous environments, the rationale and methodology must be clearly documented and approved in the Security Assessment Plan.

Continuous Monitoring Obligations

Authorization is not a one-time event. Revision 1 maintains continuous monitoring requirements that obligate organizations to demonstrate ongoing compliance through regular deliverables.

Quarterly Deliverables

Organizations must provide the following every quarter (due dates: November, February, May, August):

• Current vulnerability scan reports for web applications and operating systems
• Updated POA&M reflecting remediation progress and newly identified findings
• Confirmation of shared drive access review completion (with GSA ISSO)

Failure to provide quarterly deliverables on time signals to GSA that the organization may not be maintaining the security posture on which authorization was granted. Persistent delays can trigger reassessment or suspension of authorization.

Annual Updates

By July 31 each year, organizations must update and resubmit:

• System Security and Privacy Plan reflecting current architecture and control implementations
• Privacy Threshold Assessment and Privacy Impact Assessment (if applicable)
• Penetration test results (if penetration testing is performed)

Triennial Reauthorization

Every three years, systems require full independent reassessment. This is not simply a documentation update—it is a complete re-validation of security controls equivalent to the initial authorization assessment.

Organizations should begin preparing for reauthorization at least six months in advance by:

• Conducting an internal gap assessment against current requirements
• Remediating known vulnerabilities and POA&M items
• Updating all documentation to reflect current system state
• Engaging the independent assessor to develop a Security Assessment Plan

After Authorization: Managing Changes Without Losing Your ATO

Once you’ve achieved authorization, maintaining it requires careful change management.

Many contractors mistakenly believe they have full autonomy once authorized, but certain changes can trigger reassessment or even authorization suspension.

Revision 1 clarifies which system changes require pre-notification to GSA before implementation.

Major Changes Requiring Pre-Notification

The following changes may require reassessment and must be coordinated with the GSA ISSO, ISSM, and Contracting Officer before implementation:

• Changes to CUI data types or retention periods
• Changes to encryption protecting CUI at rest or in transit
• Re-hosting or re-platforming (including cloud migrations)
• Addition of external services that process or store CUI
• Removal of security components used to protect or monitor the system
• Removal of MFA for administrative or user access

Organizations that proceed with these changes without GSA concurrence risk having their authorization suspended pending reassessment.

Changes Requiring Documentation Updates

Other changes should be documented in quarterly continuous monitoring deliverables:

• New features or capabilities provided to GSA users
• Replacement of security components (scanning tools, SIEM, firewalls, etc.)
• New authentication mechanisms or changes to existing ones
• Implementation of new monitoring capabilities

Next Steps for Your Organization

The path forward depends on your current authorization status and timeline.

For Organizations Pursuing Initial Authorization

Step 1: Validate System Scope and Categorization

Complete the FIPS 199 security categorization using NIST SP 800-60 to identify information types. Confirm your system meets the criteria for using this process (FIPS 199 Moderate confidentiality based on CUI, not operating on behalf of GSA, no specific safeguarding requirements in the CUI Registry).

Step 2: Conduct Self-Assessment Against Showstoppers

Before investing in full SSPP documentation, assess your current implementation of the 9 showstopper requirements. Gaps in these areas will preclude authorization regardless of how well other requirements are addressed. Prioritize remediation of showstopper gaps before proceeding.

Step 3: Engage GSA Early

Schedule the NIST 800-171 Engagement Kick-Off Meeting with GSA OCISO. This meeting clarifies process expectations, establishes points of contact, and identifies any organization-specific considerations that may affect timeline or approach.

Step 4: Document Architecture and Initial SSPP

Develop comprehensive system boundary diagrams, complete the system inventory workbook, and document implementations for the showstopper requirements. GSA must approve your architecture and initial SSPP before you proceed to full assessment. Investing in independent assessment before achieving this approval wastes resources if the architecture requires revision.

For Organizations with Existing Authorization

Step 1: Gap Analysis

Compare your current SSPP control implementations against NIST SP 800-171 Revision 3 requirements. Most changes are taxonomic, but some requirements have updated assessment procedures that may reveal implementation gaps.

Step 2: Update Documentation

Plan to update your SSPP during the next annual update cycle. If your system is approaching triennial reauthorization, coordinate with your assessor to ensure all documentation reflects Revision 3 requirements before assessment begins.

Step 3: Proactive Remediation

Don’t wait until reauthorization to address known vulnerabilities or POA&M items. Continuous monitoring quarterly deliverables provide opportunities to demonstrate progress. Organizations that maintain strong security postures between authorizations experience smoother reauthorization processes.

GSA CUI Compliance Services: How TestPros Helps Contractors Get Authorized

TestPros brings years of NIST SP 800-171 and 800-53 assessment experience across federal contractors and agencies, covering the same control families, evidence standards, and assessment rigor that GSA’s CUI authorization process demands.

CUI Readiness & Gap Assessment

We assess your environment against the 9 showstopper requirements first, identifying authorization-blocking gaps when they’re least expensive to fix. You get a prioritized remediation roadmap with level-of-effort estimates before investing in full SSPP development.

SSPP Development & Documentation Support

A weak SSPP is the most common reason authorizations stall. We help your team document actual implementations with the specificity assessors require, not boilerplate restatements that get sent back for revision.

Independent NIST 800-171 Assessment

TestPros conducts independent assessments built on years of evaluating federal systems against rigorous control sets. We know what evidence quality federal assessors expect, so there are no surprises at submission.

CUI Remediation & POA&M Support

When assessments uncover gaps, we provide prioritized remediation guidance that addresses root causes and help build POA&Ms with realistic milestones that authorizing officials will accept.

Continuous Monitoring & Reauthorization Support

GSA requires ongoing quarterly and annual deliverables, and missed deadlines put your authorization at risk. TestPros keeps your submissions complete, accurate, and on time so your team stays focused on mission-critical work.

Need GSA CUI Compliance Consulting? Talk to TestPros

TestPros provides end-to-end GSA CUI compliance consulting at every stage of the authorization process. Our team has the technical depth to help you get authorized and stay authorized.

Contact our team and schedule a free consultation today.

Additional Resources

Primary Source Documents:

• CIO-IT Security-21-112 Revision 1 (January 2026) – The complete procedural guide

• NIST SP 800-171 Revision 3 – Security requirements for CUI

• NIST SP 800-171A Revision 3 – Assessment procedures

• NIST SP 800-172 Revision 3 (Draft) – Enhanced security requirements

• CUI Registry – NARA controlled unclassified information categories

• GSA CUI Program – GSA-specific CUI guidance and resources

NIST Supporting Publications:

• NIST SP 800-53 Revision 5 – Security and privacy controls

• NIST SP 800-60 – Information type mapping for security categorization

• FIPS 199 – Security categorization standards

• FIPS 140-2 – Cryptographic module validation