The top eight cloud misconfigurations in 2026 are nearly identical to 2025's.
The top eight cloud misconfigurations in Tamnoon's State of Cloud Remediation 2026 look nearly identical to 2025's, and they make up roughly 20% of all alerts. A finding that is closed at runtime and reintroduced by the next deploy was never fixed. The finding drifted. This post is about the gap between what your infrastructure code declares and what runs, and how to fix a finding so the next apply keeps the fix.
Configuration drift is the gap between what your infrastructure code declares and what is actually running. Terraform, CloudFormation, Pulumi and the other stack tools hold the intended state. The cloud account holds the real one. The two separate in both directions.
In one direction, someone changes a resource in the console or with a CLI command. The stack no longer matches reality, and the next plan shows a diff nobody expected. In the other direction, a security team fixes a misconfiguration directly on the resource. The next deploy of the stack puts the old configuration back, and the scanner raises the same alert again.
That second direction is the one that refills a CNAPP backlog. Most drift guides stop at detection. The report did not measure drift itself, but the symptom is in the data: the same findings, two years running.
The report measured 14.86 million CNAPP detections, and 53% of them were still open as of May 2026. Closing alerts faster did not eliminate the categories that produce them. The top eight misconfigurations are almost the same list as last year:
| Misconfiguration | Share of all alerts |
| Read-only container root filesystems not enforced | 4.1% |
| Vulnerability Management (Critical and High) | 3.9% |
| Compute instances missing SSH key pair | 2.4% |
| Unencrypted block storage volumes | 2.3% |
| Unmanaged compute instances | 2.0% |
| Metadata service v2 not enforced | 1.9% |
| Missing vulnerability assessment | 1.8% |
| Container health checks not enabled | 1.8% |
Six of the eight are configuration settings, by our reading of the list. On the container gaps, the report's own words: the technical fix is simple, and the organizational coordination required to deploy fixes at scale across multiple environments and cloud providers is not. Scanners find problems, but without a closure-and-prevention loop, that is all they do.
The report's self-assessment asks a question every team should be able to answer in under five minutes: where is shift-left preventing new alerts, and where is the same misconfiguration being introduced repeatedly? If you cannot answer, you have drift and no measurement of it.
Our recommended order, cheapest signal first.
Plan diffs on a schedule. Run a plan against every stack on a schedule, not only on a pull request, and treat any unexpected diff as a drift event. Terraform and CloudFormation both expose this. The output tells you which resources moved and in which direction.
Re-detections from the CNAPP. When the same finding on the same resource opens, closes and opens again, that is drift measured by its symptom. Count re-detections per resource and per stack. The stacks with the highest counts are where the loop is open.
Resources outside any stack. Nothing declares their intended state, so they drift by definition. The dataset has a related row, unmanaged compute instances at 2.0% of all alerts, whatever your scanner's rule counts as unmanaged. Tag or import these first.
The rule is short. If a stack manages the resource, the fix goes into the stack and ships in one deploy window. If no stack manages the resource, fix the resource, then put the resource under a stack so the next fix has somewhere to live.
An example from Tamnoon's own decision record. A queue and its dead-letter queue were encrypted with the provider's default key rather than a customer-managed one. The engine read the encryption setting, every key in the account, the three roles that touch the queues, and the stacks that manage both queues. Its note on the stacks: a console change would drift them. What would change the verdict, in the record's own words: the key created, the three roles granted, both stack templates updated, and then it is one change. By hand: key, grants, both templates, one deploy window. The verdict was RISKY and the change was left to a person, on the by-hand route the record lays out. The point for drift: the route the record lays out goes through the templates, so a fix made that way survives the next deploy instead of being removed by it.
Two habits make this hold at scale.
Four numbers, reported monthly. Re-detections per stack. Re-detections per finding type. Resources outside any stack. Days between a fix at runtime and the matching template change. When the first three fall and the last goes to zero, drift is closed, and the backlog stops refilling from the same eight sources.
In the record entry above, before any action, the engine read whether a stack managed the resource and which roles depended on the change. That read produced a refusal and a template route for a person to follow. That is the behavior drift needs: a fix that knows which template owns the resource, and a public note when the fix has to go through a person. What was declined, and why, stays on the record.
A remediation layer on top of your CNAPP, one that reads the stack managing the resource before any action, so the fix lands where the next deploy keeps it. Tamnoon publishes those reads, finding by finding, on its decision record.
A misconfiguration is a setting that is wrong. Drift is the gap between the setting your code declares and the setting that is running. Drift is why a fixed misconfiguration comes back.
Run a plan on a schedule and treat unexpected diffs as drift events. Pair that with re-detection counts from your scanner, which show drift by its symptom.
In the template, whenever a stack manages the resource. A console fix on a managed resource is undone by the next apply.
No. The scanner shows the symptom, a finding that reopens. Drift detection shows the cause, a template and a resource that disagree. You need both, and one owner for the step between them.
The category close times and the top misconfigurations are in the State of Cloud Remediation 2026. The drift method above is our recommendation.
Teardowns, CTF write-ups and field notes from the people who close cloud findings for a living.
You're subscribed.
That did not go through. Try again in a minute.
At most one email a month. Unsubscribe from any of them.
