NIST 800-171 in cloud environments: what the shared responsibility model does not cover
Amara OkaforApril 29, 2026
Key takeaways
FedRAMP Moderate authorization covers the cloud provider's infrastructure. Of the 110 NIST 800-171 requirements, roughly 63 have partial or full inherited controls from a FedRAMP Moderate CSP. The remaining 47 are entirely the customer's responsibility and the most commonly misconfigured.
The shared responsibility boundary differs across AWS, Azure, and GCP for the same 800-171 control family. What Azure Government inherits for AU controls is not what AWS GovCloud inherits. Using one CSP's SSP to guide configuration on another is a documented source of audit gaps.
S3 bucket misconfiguration, overpermissioned IAM roles, and disabled CloudTrail logging in CUI workloads are the three most consistent cloud findings in 800-171 assessments. All three are customer-side controls. All three are excluded from FedRAMP authorization scope.
GCC High provides a higher isolation boundary than commercial cloud tiers for Microsoft 365 workloads. Contractors using commercial M365 tenants to store or transmit CUI are operating outside the acceptable CSP tier for 800-171, regardless of configuration choices on the customer side.
Encryption key management is one of the most misunderstood inherited control boundaries. CSPs provide key management services, but whether customer-managed keys are required for CUI workloads versus provider-managed keys is a customer configuration decision with direct 800-171 compliance implications.
Cloud-native compliance tools (AWS Security Hub, Azure Policy, GCP Security Command Center) report against CIS benchmarks and cloud-native best practices. They do not natively report against NIST 800-171 control families without custom policy mapping. Tool output that shows no findings is not the same as 800-171 compliance.
TL;DR
The most common NIST 800-171 cloud compliance failure is not a missing control. It is a boundary misunderstanding: contractors believe FedRAMP authorization covers more of their 800-171 obligations than it does. The 47 controls that remain fully customer-managed are where misconfigurations live, and cloud-native security tooling does not map to 800-171 control families by default. You have to build that mapping yourself or discover the gap during an assessment.
The cloud environment that inherited nothing it thought it did
A federal contractor running CUI workloads on AWS had documented their 800-171 compliance posture using the AWS Shared Responsibility Model whitepaper and the AWS FedRAMP SSP. Their internal assessment showed 74 of 110 controls as fully or partially met through inherited CSP controls. During our assessment, we found that their AWS environment was a commercial tier account, not GovCloud. The FedRAMP authorization they were relying on applied to AWS GovCloud US. Their commercial account inherited none of those controls. Their CUI data was stored in S3 buckets in us-east-1 with server-side encryption enabled using AWS-managed keys. CloudTrail was configured but not forwarding to a centralized log archive. IAM roles attached to EC2 instances processing CUI had AdministratorAccess policies attached from an initial setup that was never scoped down.
The SSP they had built was accurate for a GovCloud deployment. It described an environment that did not exist. The commercial account they were actually running had no inherited controls, no FedRAMP coverage, and three customer-side misconfigurations that would have been findings in the first ten minutes of a C3PAO technical review.
What FedRAMP authorization actually covers for 800-171 purposes
FedRAMP authorizes a CSP to operate federal workloads by validating that the provider's infrastructure meets a defined control baseline. For FedRAMP Moderate, that baseline maps to a subset of 800-53 Rev 4 controls. NIST published a mapping between FedRAMP Moderate and 800-171, which identifies the controls a customer can treat as inherited when using a FedRAMP Moderate authorized CSP. The keyword is authorized. The authorization applies to specific service offerings in specific regions on specific account tiers. AWS GovCloud US-East has FedRAMP High authorization. AWS commercial regions do not. An organization using AWS commercial east-1 cannot inherit any FedRAMP controls regardless of what the AWS SSP says, because that SSP describes the authorized environment, not the one they are using. The inherited control model only functions when the workload runs inside the authorized service boundary. This is documented in each CSP's Customer Responsibility Matrix (CRM), but the CRM assumes you are reading it in the context of the authorized environment it was written for.
Example
The AU control family for audit logging illustrates the boundary clearly. For a GovCloud workload, AWS inherits AU-2 event identification and AU-3 content of audit records at the infrastructure level. The customer still owns CloudTrail configuration, log archive destination, log integrity validation, and alerting configuration. AU.L2-3.3.1 and AU.L2-3.3.2 in 800-171 require that specific audit events are generated and that audit record content meets defined criteria. AWS's infrastructure-level inheritance covers the underlying capability. Whether it is configured to capture the right events with the right content for CUI workloads is entirely the customer's implementation decision.
Each CSP publishes a Customer Responsibility Matrix that maps 800-53 controls to three categories: inherited (CSP implements, customer does nothing), shared (CSP provides the capability, customer configures it), and customer-owned (customer implements entirely). For 800-171, the shared category is where most misconfigurations occur. The CSP has enabled the feature. The customer has not configured it correctly for CUI workloads. The inherited column in the CRM does not tell you what the shared column requires. Most compliance teams read the inherited column and stop.
Specific misconfigurations found across cloud CUI environments
Assessment base: Technical findings from NIST 800-171 cloud assessments conducted by Vulnox across AWS, Azure, and GCP environments used by federal contractors.
S3 buckets storing CUI using AWS-managed keys instead of customer-managed KMS keys
SC.L2-3.13.10 requires that the organization establishes and manages cryptographic keys for required cryptography employed within the system. AWS S3 server-side encryption with SSE-S3 uses AWS-managed keys. The customer does not control key rotation, key access policies, or the ability to independently revoke key access. SSE-KMS with a customer-managed KMS key gives the organization control over those functions. The difference between SSE-S3 and SSE-KMS with CMK is not visible in a standard AWS Security Hub finding. Both configurations show as encrypted. The control requirement is about key management, not just encryption state. Contractors who implement SSE-S3 and document SC.L2-3.13.10 as met have a finding waiting for them at the first technical assessment.
This is one of the shared responsibility controls where the CSP provides the encryption capability and the customer makes the implementation decision. The CRM marks encryption as shared. It does not specify that SSE-S3 is insufficient for 800-171 SC.L2-3.13.10. Reading the control requirement directly, rather than inferring from the CRM category, is the only way to catch this.
Azure AD conditional access policies with MFA gaps for privileged CUI access
IA.L2-3.5.3 requires multi-factor authentication for local and network access to privileged accounts and network access to non-privileged accounts. In Azure Government environments, Conditional Access policies are customer-configured. The default state after tenant provisioning does not enforce MFA for all privileged accounts. We consistently find Azure environments where MFA is enforced for standard user accounts through Conditional Access but where break-glass administrator accounts and service principals with privileged roles are excluded from MFA policies. The exclusion is intentional for operational reasons. The 800-171 control does not permit exceptions for operational convenience.
Azure AD Conditional Access is a shared-category control. Microsoft provides the capability. The customer configures the policies. A configuration review that checks whether Conditional Access is enabled answers the wrong question. The question that matters for IA.L2-3.5.3 is whether every privileged account, including service accounts and emergency access accounts, is covered by a policy that enforces MFA. The answer is almost always no.
GCP Assured Workloads enabled but data residency controls not configured for CUI project
GCP Assured Workloads provides an organizational policy framework for compliance-controlled environments, including FedRAMP Moderate and IL2 configurations. Enabling Assured Workloads on a folder does not automatically restrict data processing to compliant regions or prevent services outside the compliance boundary from being used within that folder. Organizations that enable Assured Workloads, review the initial policy set, and treat the environment as compliant are missing the second layer: verifying that the specific GCP services in use within that folder are in scope for the Assured Workloads configuration, and that no service APIs have been enabled that operate outside the regional boundary. BigQuery datasets in non-US regions within an Assured Workloads folder for a FedRAMP Moderate workload represent exactly this pattern.
SC.L2-3.13.6 requires controlling the flow of CUI in accordance with approved authorizations. Data residency is a component of that control in cloud environments. Assured Workloads reduces the effort of implementing data residency controls but does not eliminate the need to validate that all services handling CUI are inside the compliant boundary. The validation requires reviewing each enabled API and each data store within the folder, not just confirming that Assured Workloads is active.
CloudTrail enabled but not configured to capture data-plane events for S3 and Lambda
AWS CloudTrail management events are enabled by default in most environments and capture API calls at the control plane: who created a bucket, who modified an IAM policy, who launched an EC2 instance. AU.L2-3.3.1 requires audit logging of events including read and write access to CUI. For S3, those are data events, specifically GetObject and PutObject calls. Data events are not captured by CloudTrail management events. They require separate configuration with associated cost. In every AWS environment we assess, CloudTrail is enabled. In most, data events for S3 buckets holding CUI are not configured. The audit log shows bucket creation and policy changes. It does not show who accessed or modified the files inside.
This is the gap between having a logging capability and having the logging configuration that satisfies 800-171 audit requirements. A C3PAO assessor reviewing AU.L2-3.3.1 will ask for evidence of audit records for read access to CUI. CloudTrail without data events cannot produce that evidence. The configuration change to enable S3 data events takes minutes. The discovery that it was missing typically happens during an assessment, not before.
AWS GovCloud vs Azure Government vs GCP Assured Workloads: where the compliance boundaries differ
AWS GovCloud US
FedRAMP High authorized for GovCloud US-East and US-West. Separate account type from commercial AWS, requires US person screening for access. Customer Responsibility Matrix specifies inherited, shared, and customer-owned controls against 800-53 Rev 4 baseline. CloudTrail, Config, and Security Hub available for compliance monitoring. Data events require separate configuration. IAM is entirely customer-managed.
GovCloud provides the highest 800-171 inherited control coverage of the three major CSPs. The compliance gap is in customer-managed controls: IAM scoping, CloudTrail data events, S3 bucket policies, KMS key management. Organizations that have GovCloud accounts and have not reviewed their CRM against 800-171 requirements are carrying gaps in the shared-category controls.
Azure Government / GCC High
GCC High is the M365 Government offering with ITAR/CUI compliance controls. Azure Government is the IaaS/PaaS offering. FedRAMP High authorized. Conditional Access, Azure Policy, and Defender for Cloud provide compliance monitoring. Conditional Access is customer-configured. Service principal and managed identity permissions are customer-owned. GCC High required for CUI in M365 workloads; commercial M365 is not an acceptable CSP tier.
The most consistent Azure Government finding is Conditional Access policy gaps for privileged accounts and service principals. The most consistent GCC High finding is CUI stored in commercial M365 tenants by users who have both commercial and GCC High licenses. When both tenant types exist, data flows to the path of least resistance, which is usually commercial.
GCP Assured Workloads
FedRAMP Moderate authorized for specific service set within Assured Workloads folders. Does not require separate GCP account type like GovCloud. Organizational Policy Service provides guardrails but requires customer configuration per folder. Not all GCP services are in scope for Assured Workloads. Service-level compliance scope must be verified per API.
The lowest inherited control coverage of the three for 800-171 purposes. Assured Workloads reduces the configuration burden but does not substitute for a per-service review. Organizations that move CUI workloads to GCP without verifying that each service API in use is within the Assured Workloads compliance boundary have gaps that are invisible to standard GCP Security Command Center findings.
Where 800-171 cloud assessments consistently find undocumented gaps
Infrastructure-as-code templates that provision out-of-compliant defaults
Terraform modules and CloudFormation templates written before 800-171 compliance requirements were established provision resources with default configurations. An S3 module written in 2021 may provision buckets with SSE-S3 encryption because that was the accepted default at the time. When that module is reused for a CUI workload in 2024, it provisions a non-compliant bucket configuration without any warning. The IaC pipeline deploys successfully. Compliance scanning against the resulting infrastructure finds the encryption gap. The fix requires updating the module, not just the deployed resource, or every future deployment recreates the finding.
Cross-account trust relationships that extend CUI access outside the compliant boundary
AWS organizations commonly use cross-account IAM roles to allow a central security or operations account to access workload accounts. If the central account is a commercial account and the workload account is GovCloud, the cross-account trust relationship may extend access from outside the FedRAMP authorized boundary into the CUI environment. The workload account's controls are configured correctly. The trust relationship bypasses the boundary. AC.L2-3.1.3 requires controlling the flow of CUI. A cross-account role that allows a non-GovCloud account to assume a role in a GovCloud environment is a flow control failure that does not appear in workload-account-only assessments.
Log forwarding architectures that route CUI audit logs through commercial regions
Centralized log management commonly aggregates logs from multiple environments into a single SIEM or log archive. If GovCloud CloudTrail logs are forwarded to a commercial S3 bucket or a SIEM running in a commercial region, the audit logs themselves have left the FedRAMP boundary. AU.L2-3.3.1 requires protecting audit information from unauthorized access. Storing audit logs about CUI access in a non-FedRAMP environment creates a new scope boundary question: are those logs in scope for 800-171? The answer is probably yes, because they contain access records for CUI. The commercial log archive then needs to meet 800-171 requirements it was never configured for.
Cloud-native security tool compliance scores have no relationship to 800-171 assessment outcomes
Common belief
Organizations that run AWS Security Hub, Azure Defender for Cloud, or GCP Security Command Center with a clean findings report assume their cloud environment will pass an 800-171 technical assessment. The tools show a compliance score. A high score means the environment is compliant.
What we found
In cloud assessments where the customer presents a clean Security Hub or Defender for Cloud report before we begin, we consistently find 800-171 gaps in the shared-category controls that cloud-native tools do not evaluate. The tool report is accurate for what it measures. It does not measure 800-171 compliance. Organizations that use cloud-native tool scores as proxy compliance evidence are producing documentation that will not survive a C3PAO technical review.
Cloud-native security tools report against their own rule sets, which map primarily to CIS Benchmarks and cloud provider best practices. AWS Security Hub does not natively have a 800-171 rule set. It has an AWS Foundational Security Best Practices standard and a CIS AWS Foundations Benchmark. Azure Defender for Cloud has a Regulatory Compliance blade that includes NIST SP 800-53 Rev 5. It does not have an 800-171 blade. The mapping between these standards and 800-171 control families is partial and inconsistent. A Security Hub finding cleared against a CIS benchmark rule does not mean the underlying 800-171 control is satisfied. More specifically, the four findings described above: SSE-S3 versus CMK, Conditional Access policy gaps, Assured Workloads service boundary verification, and CloudTrail data events: none of them appear as findings in default cloud-native security tool configurations.
Where cloud CUI compliance enforcement is heading
Within 18 months, C3PAO assessments will begin requiring cloud environment technical testing, not just documentation review, as a standard component of CMMC Level 2 assessment methodology for contractors with cloud CUI workloads.
The current CMMC assessment methodology allows C3PAOs to rely on examination and interview evidence for many controls. For cloud environments, the gap between what documentation says and what configuration shows is large enough that C3PAO organizations are developing internal technical testing procedures. As more assessments expose the pattern of documented compliance over misconfigured environments, the assessment methodology will evolve to require configuration-level evidence rather than accepting SSP descriptions at face value.
Confidence: mediumIf the CMMC Assessment Process (CAP) documentation published by the Cyber AB before the end of 2026 does not include technical configuration testing requirements for cloud environments, the prediction was wrong on timing.A significant CUI breach traced to a commercial M365 tenant used by a contractor who also held a GCC High license will produce the first enforcement action specifically citing CSP tier selection as the primary compliance failure within 24 months.
The pattern of contractors holding both commercial and GCC High M365 licenses, with CUI flowing to commercial tenants through collaboration features, is structurally present across multiple contractor environments. The breach will be traced through forensic analysis to commercial tenant audit logs. The enforcement finding will cite the failure to confine CUI to the compliant CSP tier as distinct from and prior to any configuration failures within that tier.
Confidence: highIf no enforcement action citing CSP tier selection as a primary DFARS or CMMC finding appears in public reporting before the end of 2027, the prediction was wrong.
The Customer Responsibility Matrix is the most misread document in cloud compliance
Every major CSP publishes a CRM that maps 800-53 or 800-171 controls to inherited, shared, and customer-owned categories. These documents are detailed, technically accurate, and almost universally misread. The mistake is treating the inherited column as a list of controls you do not need to implement, and stopping there. The shared column is the important one. Shared means the CSP has provided the capability and the customer must configure it correctly. For 800-171 in cloud environments, most of the security-relevant controls are in the shared column. Reading the CRM means understanding what correct configuration looks like for each shared control in the context of your specific workload, not just confirming the feature is available. Most compliance teams read CRMs to understand what they do not have to do. The controls that produce breaches are in the column they skipped.
Counterargument
The counterargument is that CSPs should publish more prescriptive guidance on what correct shared-control configuration looks like for 800-171 specifically, rather than leaving it to customers to interpret. AWS, Azure, and Google have each published compliance guides that go some way toward this. They are incomplete and not updated on the same timeline as the standard. Until they are, interpreting the shared column requires reading the 800-171 control requirement directly and validating configuration against the 800-171A assessment objectives, not against the CSP's compliance guide.
One configuration check this week
Pull the list of S3 buckets, Azure Storage accounts, or GCP Cloud Storage buckets in your CUI workload and check two things: whether encryption uses customer-managed keys, and whether object-level access logging is enabled. These are the two most common gaps in cloud CUI environments and both are customer-side configurations that FedRAMP does not cover. In AWS, run: aws s3api get-bucket-encryption --bucket <bucket-name> to check key type, and aws s3api get-bucket-logging --bucket <bucket-name> to check access logging. In Azure, check Storage account diagnostics settings for blob read and write logging. In GCP, check Cloud Audit Logs data access configuration per bucket. Both gaps will surface in a C3PAO assessment. Neither surfaces in default cloud-native security tool scans.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNIST security and privacy framework group: all 34 publications mapped
NIST 800-171 cloud compliance gaps across AWS, Azure, and GCP environmentsNational Vulnerability Database NIST
NIST National Vulnerability DatabaseNIST Cybersecurity Framework 2.0
NIST Cybersecurity FrameworkShadow IT Discovery
Shadow IT discovery
Frequently Asked Questions
Does FedRAMP Moderate authorization mean a cloud environment is NIST 800-171 compliant?
No. FedRAMP Moderate authorization covers the CSP's infrastructure controls. Of the 110 NIST 800-171 requirements, roughly 63 have partial or full inherited controls from a FedRAMP Moderate authorized CSP. The remaining 47 are entirely the customer's responsibility. FedRAMP authorization also only applies to specific service tiers in specific regions. AWS commercial accounts have no FedRAMP inherited controls. Only AWS GovCloud US accounts inherit FedRAMP controls.
What is the difference between AWS GovCloud and commercial AWS for NIST 800-171 compliance?
AWS GovCloud US-East and US-West hold FedRAMP High authorization. AWS commercial regions do not. A workload running in a commercial AWS account inherits no FedRAMP controls regardless of how it is configured. The Customer Responsibility Matrix that AWS publishes for FedRAMP compliance describes the GovCloud environment. Applying that CRM to a commercial account produces a false compliance picture. CUI workloads must run in GovCloud to inherit any FedRAMP controls toward 800-171 compliance.
What cloud configurations most commonly cause NIST 800-171 assessment failures?
The four most consistent findings across cloud 800-171 assessments are: S3 buckets using AWS-managed keys instead of customer-managed KMS keys (SC.L2-3.13.10); Conditional Access policy gaps for privileged accounts and service principals in Azure (IA.L2-3.5.3); CloudTrail management events enabled without data events for S3 buckets holding CUI (AU.L2-3.3.1); and GCP Assured Workloads enabled at the folder level without verification that each service API in use is within the compliant service boundary (SC.L2-3.13.6). All four are in the shared-responsibility category and none surface as findings in default cloud-native security tool configurations.
Can Microsoft 365 commercial be used to store or transmit CUI?
No. Microsoft's acceptable use guidance for CUI specifies that CUI must be handled in GCC High, not commercial M365 or standard GCC. GCC High provides the ITAR boundary and isolation level required for CUI under DFARS obligations. Contractors who hold both commercial and GCC High licenses frequently allow CUI to flow to commercial tenants through collaboration features. This is a CSP tier selection failure that precedes any configuration issue within either tenant.
What does the Customer Responsibility Matrix cover for cloud 800-171 compliance?
The CRM maps 800-53 controls to three categories: inherited (CSP implements fully), shared (CSP provides capability, customer configures), and customer-owned (customer implements entirely). For 800-171, the shared category contains most of the security-relevant controls. The CRM documents what capability the CSP provides. It does not specify what correct customer configuration looks like for a CUI workload. Determining that requires reading the 800-171 control requirement and the 800-171A assessment objectives directly and verifying that the CSP capability is configured to meet those objectives.
Do AWS Security Hub or Azure Defender for Cloud findings map to NIST 800-171 controls?
Not natively. AWS Security Hub reports against AWS Foundational Security Best Practices and CIS AWS Foundations Benchmark. Azure Defender for Cloud has a NIST SP 800-53 Rev 5 regulatory compliance view but not an 800-171 view. The mapping between these standards and 800-171 control families is partial. Specific 800-171 gaps like CloudTrail data event configuration, customer-managed KMS key requirements, and Conditional Access policy coverage for all privileged accounts do not appear as findings in default cloud-native security tool scans.
How does GCP Assured Workloads compare to AWS GovCloud for NIST 800-171 purposes?
GCP Assured Workloads provides a FedRAMP Moderate compliant environment within standard GCP accounts using organizational policy constraints, without requiring a separate account type. The trade-off is lower inherited control coverage compared to AWS GovCloud and a requirement to verify per-service API compliance scope. Not all GCP services are included in Assured Workloads compliance scope. BigQuery, Cloud Run, and other services require per-service verification that data processing stays within the compliant regional boundary. AWS GovCloud provides higher inherited control coverage but requires separate account provisioning and US person access screening.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.