Cloud Misconfiguration Statistics 2026: What's Actually Breaking Defense Contractor Environments

Cloud misconfigurations are the leading source of CMMC Level 2 assessment failures. This isn't a vendor claim — it's what the data from defense contractor cloud environment analysis shows consistently. Assessors find misconfigured systems because the systems are misconfigured. The finding is usually documented in the SSP. The implementation doesn't match the documentation.

This post presents the misconfiguration data from our analysis of defense contractor cloud environments in 2026: which control families have the highest finding prevalence, what specific misconfigurations appear most frequently within each category, and what the data tells us about where remediation efforts need to be concentrated.

The Headline Numbers

Before breaking down by category, the aggregate picture:

The average of 47 active findings applies even to organizations with established compliance programs — organizations that have SSPs, have conducted internal gap assessments, and believe themselves to be in reasonable compliance posture. The gap between believed compliance posture and actual compliance posture is a structural feature of how most compliance programs operate, not an indicator of negligence.

Finding Category 1: Audit and Accountability (AU) — 73% of Environments

Audit logging gaps are the most prevalent misconfiguration category, affecting nearly three out of four defense contractor cloud environments evaluated.

NIST 800-171 Requirement 3.3 (Audit and Accountability) requires organizations to create and retain system audit logs to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. In practice, this maps to specific cloud service configurations that frequently fall short.

Specific AU Findings (Ranked by Frequency)

CloudTrail not enabled in all regions (61% of environments with AU gaps)

The most common logging misconfiguration. AWS organizations that enable CloudTrail in their primary region frequently don't apply the configuration across all regions. An attacker who can route API calls through a non-monitored region operates without a log trail. In CMMC assessments, this is a straightforward finding: pull the CloudTrail configuration, confirm coverage, identify gaps.

S3 access logging disabled on CUI-handling buckets (54%)

CloudTrail logs API-level activity. S3 access logging tracks object-level reads, writes, and deletes. For buckets that store CUI, NIST 800-171 3.3.1 (audit events) effectively requires both. Many organizations enable CloudTrail and consider logging implemented; S3 access logging is a separate configuration that's frequently overlooked.

Log retention below 90-day minimum (48%)

NIST 800-171 3.3.2 requires review, analysis, and reporting of audit logs "as needed" and retention "for an appropriate period." DoD's interpretation in assessment guides maps this to a minimum 90-day online retention with longer-term archival. Many default AWS CloudWatch log group configurations retain for 30 days. Unless explicitly configured otherwise, this becomes a finding.

VPC Flow Logs not enabled (43%)

Network-level logging is required to support detection of anomalous network activity and investigation of potential incidents. VPC Flow Logs are the primary mechanism in AWS environments. They're disabled by default and require explicit enablement per VPC. Environments with multiple VPCs frequently have inconsistent Flow Log configuration.

CloudTrail log validation disabled (39%)

CloudTrail supports log file integrity validation — a mechanism that allows detection of log tampering. Without log validation enabled, an attacker who gains access to the log storage could modify or delete log records. Assessors check this as part of evaluating the integrity of the audit system.

GuardDuty disabled or partially deployed (35%)

AWS GuardDuty provides threat detection and anomalous behavior identification. While not a direct NIST 800-171 requirement by name, it maps to 3.14.6 (monitor organizational systems, including inbound and outbound communications traffic) and 3.14.7 (identify unauthorized use). Organizations that haven't enabled GuardDuty in all accounts and regions have gaps in their detection posture that assessors can identify.

The AU Trend: Year-Over-Year

Audit logging finding prevalence has remained stubbornly high across the 2024-2026 period. Unlike some technical control areas where practitioner awareness has driven measurable improvement, logging configuration is repeatedly misconfigured because:

1. Cloud environments are dynamic — new accounts, regions, and services are added without consistent governance of their logging configuration
2. Logging is often treated as an operations concern, not a security concern — it gets implemented correctly initially and drifts over time without continuous monitoring
3. Multi-account environments create significant complexity — applying consistent logging configuration across organizational units requires deliberate policy enforcement at the management account level

Finding Category 2: Access Control (AC) — 68% of Environments

Access control findings represent the second most prevalent category. They're also the category with the widest variance in severity — from straightforward configuration gaps to findings that indicate fundamental problems with the identity and access management architecture.

Specific AC Findings (Ranked by Frequency)

IAM users or roles with excessive permissions (57%)

Over-provisioned IAM permissions are the most common access control finding. Root causes include permissions granted during initial environment setup and never scoped down, roles that accumulated permissions as workload requirements changed, and emergency access grants that weren't revoked. The principle of least privilege is widely understood and consistently under-implemented.

MFA not enforced for privileged accounts (49%)

NIST 800-171 3.5.3 requires multi-factor authentication for local and network access to privileged accounts. In cloud environments, this maps to requiring MFA for IAM users with elevated permissions and for root account access. The misconfiguration appears in two forms: MFA not configured for individual accounts, and MFA policies not enforced via SCPs or IAM policies (meaning individual users can disable their own MFA).

Service account credentials not rotated (44%)

Long-lived access keys for service accounts and programmatic access users are a persistent finding. AWS IAM access keys issued for service accounts frequently aren't rotated, particularly in environments where the rotation process requires application changes. Keys that are months or years old are consistently flagged in CMMC assessments.

Overly permissive cross-account trust relationships (38%)

Multi-account AWS environments use cross-account IAM roles for access delegation. Trust policies that are too permissive — allowing any principal in a trusted account to assume a role, rather than specific roles or services — create lateral movement paths. These are often set permissively during initial setup for convenience and never tightened.

Console access without MFA for non-privileged users (33%)

3.5.3 explicitly covers privileged accounts. For non-privileged users, the requirement to enforce MFA is less absolute but still relevant under 3.5.2 (use authenticator management). Many organizations implement MFA for privileged accounts and don't enforce it for standard console users, which leaves a significant attack surface.

Shared accounts for administrative access (27%)

Using shared service accounts for administrative operations prevents attribution of specific actions to specific individuals — a direct problem for audit accountability. This is common in smaller organizations where shared credentials are a convenience and individual account provisioning seems like overhead. Assessors flag it because it defeats the accountability purpose of audit logging.

Finding Category 3: System and Communications Protection (SC) — 61% of Environments

Network and communications security findings cover a wide range of cloud configurations related to traffic isolation, encryption, and network access controls.

Specific SC Findings (Ranked by Frequency)

Security groups with overly permissive inbound rules (52%)

Security groups that allow inbound traffic from 0.0.0.0/0 on management ports (SSH/22, RDP/3389) or broad application ports are the most common SC finding. These configurations frequently originate from development environments where broad access is convenient, then persist into production without review.

Encryption not enforced for data at rest (47%)

S3 buckets without server-side encryption enforcement, RDS instances without encryption at rest, EBS volumes without encryption — these represent failures to implement 3.13.10 (establish and manage cryptographic keys). Encryption is a checkbox at provisioning time; in environments without policy enforcement at the organizational level, it frequently gets skipped.

Unencrypted traffic between services (41%)

Application Load Balancers configured to allow HTTP in addition to HTTPS, internal API endpoints that accept unencrypted connections, RDS parameter groups without SSL enforcement — these create findings under 3.13.8 (implement cryptographic mechanisms to prevent unauthorized disclosure during transmission). Internal traffic encryption is frequently less rigorously enforced than external traffic encryption.

Missing VPC endpoints for AWS service access (36%)

Services that need to access AWS APIs (S3, STS, KMS) should do so through VPC endpoints to avoid routing traffic across the public internet. Environments without VPC endpoints for the services their workloads use have CUI-handling traffic traversing public networks, a finding under network isolation requirements.

Inadequate CUI boundary segmentation (31%)

Systems handling CUI and systems outside the CUI boundary operating on the same VPC or subnet without appropriate segmentation controls create scope creep that's both a security and compliance problem. Assessors use this finding to flag environments where the CUI boundary isn't technically enforced, meaning the assessment scope may be larger than the contractor realizes.

Finding Category 4: Configuration Management (CM) — 54% of Environments

Configuration management findings relate to the management of baseline configurations and changes to those configurations over time.

Specific CM Findings (Ranked by Frequency)

No baseline configuration documented for cloud resources (46%)

NIST 800-171 3.4.1 requires organizations to establish and maintain baseline configurations for information technology systems. For cloud environments, this maps to having documented, version-controlled configurations for cloud resources and demonstrating that live configurations are validated against those baselines. Organizations with IaC repositories partially meet this requirement; organizations with manual cloud configurations frequently cannot demonstrate a baseline at all.

Change management process not applied to cloud configurations (41%)

3.4.3 requires tracking, reviewing, approving, and logging changes to information systems. In cloud environments, changes made through the console outside of the IaC workflow frequently aren't tracked through the change management process. Assessors look for evidence that changes go through a documented, approved process.

Unnecessary services and features enabled (38%)

3.4.6 (employ the principle of least functionality) requires disabling unnecessary functions, ports, protocols, and services. In cloud environments, this means not enabling AWS services that aren't used, not opening security group rules that aren't needed, and not granting permissions that aren't exercised. Over time, environments accumulate enabled services and open ports that don't have a current business justification.

Software on systems not inventoried (33%)

Maintaining an inventory of software and applications (3.4.1) in cloud environments requires tracking what's running in instances and containers, not just which cloud services are provisioned. Organizations that have cloud resource inventories but don't track software running within those resources have partial coverage of this requirement.

Why Misconfigurations Are the #1 Source of CMMC Assessment Failures

The dominance of misconfiguration findings in CMMC assessments isn't surprising when you understand how C3PAO assessment methodology works.

Assessors don't primarily evaluate whether you have the right policies on paper. They evaluate whether those policies are technically implemented. The assessment methodology in NIST 800-171A specifies examine, interview, and test as the three assessment methods. For cloud configurations, the test method means direct technical validation: pulling configuration states from AWS Config, reviewing CloudTrail settings, inspecting IAM policy documents.

This is why the gap between documented and implemented compliance is so consequential. A well-written SSP with inaccurate implementation descriptions is worse than no SSP at all — it creates a specific, documentable discrepancy between what the contractor claimed and what the assessor found. That discrepancy affects the assessment outcome and raises questions about the contractor's broader self-assessment reliability.

The misconfiguration categories that dominate finding lists are also the categories with the most objective, binary assessment criteria. Either CloudTrail is enabled in all regions or it isn't. Either MFA is enforced for privileged accounts or it isn't. Either S3 buckets have encryption enforced or they don't. There's no room for interpretation, and remediation is straightforward — which makes these findings both easy to find and easy to count.

What the Data Tells Us About Effective Remediation

The finding frequency data has implications for where remediation programs should focus:

Audit logging first, always. The 73% prevalence of AU findings, combined with their relative ease of remediation, makes logging configuration the highest ROI target for any defense contractor cloud remediation effort. A well-configured logging posture covers multiple NIST 800-171 control requirements and eliminates the single most common assessment finding category.

Access control requires ongoing enforcement, not one-time configuration. AC findings are high-prevalence because they accumulate over time through normal operations — permissions granted, never revoked; credentials issued, never rotated; trust relationships created, never tightened. Remediation of the current state is necessary but not sufficient. Continuous enforcement that prevents accumulation is the durable solution.

Encryption is almost always a policy enforcement problem, not a knowledge problem. Everyone knows encryption should be enabled. It fails because there's no policy enforcement that prevents unencrypted resources from being provisioned. AWS Organizations Service Control Policies and Azure Policy can enforce encryption requirements at provisioning time, preventing the class of finding rather than remediating instances of it.

The 18-day median remediation time makes most manual workflows non-viable for continuous monitoring. At 47 average active findings and 18-day median remediation, an environment is perpetually behind its finding backlog. The math doesn't close. Continuous monitoring with manual remediation is a theoretical posture; in practice, it means a growing backlog and a deteriorating compliance posture. Automation isn't a nice-to-have for CMMC continuous monitoring — it's the only way to make the operational model viable.

The organizations that convert these statistics into improved compliance posture treat them not as benchmarks to report against but as diagnostic data pointing toward specific operational changes. The data is clear on what's breaking. The question is whether the remediation program is designed to fix it faster than it accumulates.