Cloud Security Statistics on Access and Misconfiguration
Cloud security statistics can reveal conditions worth investigating, but an observed condition is not the same as a successful attack. An old access key may create an avoidable exposure. Its age alone does not prove that someone stole it, used it, or obtained protected information.
That distinction matters when a security team turns telemetry into a budget request. Findings about credentials and configuration can support a focused control review. They should not be rewritten as breach rates or as evidence that a particular percentage of all cloud customers has been compromised.
Datadog’s 2025 cloud-security research offers two useful observations about long-lived credentials. Read with their own denominators, they provide a starting point for reviewing ownership, access, and replacement processes. Broader breach research supplies a different form of context and should remain separate.
Key Statistics and Data
- AWS identities: In Datadog’s observed population, 59% of AWS IAM users with at least one active access key had an oldest active key more than one year old.
- Google Cloud identities: Among active Google Cloud service accounts with an active key in the analyzed population, 55% had an oldest active key more than one year old.
- Scope limits: The Google Cloud measure excludes Google-managed and disabled accounts. The report reflects telemetry from thousands of Datadog customers, not every cloud user.
- Interpretation: Credential age is a configuration and access-management observation. It is not an observed breach probability or proof that the credential was misused.
Read Each Credential Finding on Its Own Terms
Datadog’s observed cloud security findings describe a September 2025 snapshot. The AWS and Google Cloud measures both concern key age, but their identity types and inclusion rules differ. That prevents a simple four-percentage-point comparison from becoming a provider-security ranking.
Chart
Read Each Credential Finding on Its Own Terms
- Finding
- 59%AWS oldest active key older than one yearDenominator: IAM users with at least one active access key in the observed population
- 55%Google Cloud oldest active key older than one yearDenominator: Active service accounts with an active key, excluding Google-managed and disabled accounts
| Platform Measure | Finding | Denominator |
|---|---|---|
| AWS oldest active key older than one year | 59% | IAM users with at least one active access key in the observed population |
| Google Cloud oldest active key older than one year | 55% | Active service accounts with an active key, excluding Google-managed and disabled accounts |
The phrase “oldest active key” also matters. It identifies whether a qualifying identity has a key beyond the stated age threshold. It does not describe the percentage of all keys that are old, the percentage used during a particular period, or the percentage exposed outside the organization.
The customer-telemetry population creates another boundary. Organizations using the relevant monitoring services may differ from organizations outside that population. The findings are useful observations within the report, but they should not be generalized into a census of all AWS or Google Cloud environments.
Keep those definitions beside the figures in management reporting. A chart labeled simply “59% have insecure credentials” would add a conclusion the measure does not establish. A precise label makes it possible to discuss the actual control question: why does the identity retain a long-lived key, and is that arrangement still justified?
Distinguish a Risky Condition From a Breach
A security review can identify an unnecessary permission, a broadly reachable resource, or an old credential without finding evidence of misuse. Those are still valid reasons to investigate and improve controls. They simply belong to a different evidence category from a confirmed incident or disclosure.
Verizon’s contributed breach data concerns reported events under its research definitions. It cannot be combined with Datadog’s configuration observations to calculate the probability that an old key causes a breach. The sources do not follow the same population through a documented sequence of exposure and outcome.
The distinction becomes important in sector and company-size comparisons. A sector event count may help frame a discussion about operational exposure, while a credential inventory identifies work within your own estate. Neither should be used to imply that a particular local configuration has already produced the losses reported in another dataset.
Use an evidence ladder in the investigation itself. First establish the condition: which key, identity, permission, or resource is involved? Then establish the exposure path and relevant activity. Finally, determine whether there is evidence of unauthorized use or information access. Each step needs its own records.
Cloud security statistics are most useful when they support this sequence rather than collapse it. They can explain why a control deserves attention while leaving the incident determination to the evidence from the affected environment.
Build an Identity and Credential Inventory
An inventory should connect each credential to an accountable owner and a business purpose. A list of key identifiers and creation dates is insufficient if nobody can explain which workload depends on them or what would happen if access changed.
Record the identity type, associated application or process, owner, permissions, environments, and available activity evidence. Keep human identities separate from workload identities so the review does not assume that an employee lifecycle process controls every automated integration.
For a long-lived key, ask why the credential exists and what alternative access method the workload supports. The answer may involve application constraints, integration design, or an unfinished migration. The review should produce a specific plan and acceptance test rather than a blanket instruction that ignores dependencies.
Avoid using key age as the only priority score. A credential’s permissions, reachable resources, exposure, and business criticality affect the practical risk. A newer key with excessive privilege can deserve urgent attention, while an older key may require a carefully coordinated replacement to avoid interrupting a critical service.
The inventory should also record uncertainty. If the owner is unknown or activity cannot be established, assign that gap to someone who can investigate. An unresolved credential should not disappear from the review simply because it is difficult to classify.
Turn Findings Into Testable Control Work
The following control map is an editorial review framework. It translates an observation into a question, an owner, and evidence of completion without pretending that one action fits every environment.
| Observation | Review Question | Evidence to Retain |
|---|---|---|
| Long-lived active key | Is the credential necessary, owned, and appropriately scoped? | Owner confirmation, dependency record, and approved access design |
| Unclear credential use | Which workload uses it, and what activity supports that conclusion? | Relevant activity records and a documented dependency assessment |
| Excessive permission | Which required action needs each permission? | Allowed and denied test results under the revised access model |
| Broad resource exposure | Which traffic or identity path makes the resource reachable? | Reachability assessment, policy evidence, and verification after change |
| Unowned exception | Who accepts the remaining condition and when is it reviewed? | Named owner, rationale, review trigger, and compensating measures |
The completion test should match the change. Removing a credential from a list is not enough if the workload silently fails or recreates another unmanaged credential. Reducing a permission is not enough if the required task can no longer complete and the team restores broad access without review.
For an important workload, include normal operation and failure handling in the test. Confirm that permitted work still succeeds, prohibited work is denied, and failures are visible to an owner. Keep a controlled route for resolving unexpected operational impact.
This process turns a high-level finding into evidence the business can use. It also helps distinguish completed remediation from an administrative status change in a ticket.
Review Human Access and Workload Access Together
Employee movement can affect cloud access through groups, roles, application assignments, and locally managed credentials. The appropriate review connects the authoritative personnel change to the downstream entitlement rather than assuming that a single account status settles every access path.
The handling of employee access changes illustrates the need for downstream confirmation. A central identity action may trigger deprovisioning, but individual applications, sessions, tokens, and exceptions still need to be understood. The same principle applies when a departing employee originally created or maintained an automated integration.
Ask who owns the workload after the employee leaves. A service credential should not become ownerless because its creator is no longer available. Transfer operational responsibility, review the permissions, and preserve the information needed to maintain or replace the integration.
Movers deserve attention as well as leavers. A person can accumulate access as responsibilities change, particularly where old assignments are retained. Define the access expected for the new role and test whether prior privileges remain unnecessarily available.
Cloud security statistics about key age do not capture every one of these lifecycle issues. They provide a signal that access management needs ongoing attention. The internal review must still cover the actual identity paths that exist in the organization.
Keep Deployment Scope Visible
Different cloud deployment models can create different ownership and evidence boundaries. A company may operate services across several environments, with identity and monitoring responsibilities divided between internal teams and suppliers. A control review needs to follow the service across those boundaries.
Define the population before reporting a completion percentage. Does the inventory include every account, project, subscription, and integration in scope? Are newly acquired environments included? Are supplier-managed services assessed through a different process? A percentage without that boundary can overstate coverage.
Report inventory coverage separately from remediation progress. The team may have resolved a high share of known findings while still lacking visibility into an important environment. Both facts matter, and combining them into one score hides the remaining uncertainty.
Use consistent review periods for internal trends. If the monitored population expands, a rise in findings may reflect improved visibility rather than worsening configuration. Preserve the scope change in the report so the team does not mistake better detection for a deterioration in control quality.
Measure Improvement With Operational Evidence
A useful management view includes owned identities, verified dependencies, reviewed permissions, resolved exposures, and aged exceptions. Select measures that reflect the work the team is trying to complete, and define what counts as verified.
For example, an ownership measure should require an accountable person or team who has accepted responsibility, not merely a populated text field. A remediation measure should require evidence that the intended control works and the supported workload remains usable. An exception measure should show age and review status, not only the number of open records.
The strongest use of cloud security statistics is to motivate this kind of review. The external figures explain why long-lived access deserves attention. Internal evidence establishes whether your organization has identified the relevant credentials, understood their purpose, and improved the associated controls.
That produces a more defensible result than claiming a lower breach probability from a reduced count of old keys. The team can state exactly what changed and what remains uncertain.
A credential review meeting can use one unresolved integration as a concrete case. Ask the application owner to identify the work it performs, the cloud owner to explain its permissions, and the operational team to confirm how failure would be detected. If nobody can answer those questions, ownership and dependency discovery are the immediate tasks. If the answers are clear, the team can evaluate a replacement or permission change with an appropriate test. This avoids both indefinite acceptance of an unexplained key and a disruptive removal made solely to improve an age metric.
Frequently Asked Questions
Does an Old Access Key Mean an Account Was Breached?
No. Key age is an observed credential characteristic. A breach determination requires evidence of unauthorized activity or disclosure under the applicable definition. An old key can justify a control review without proving that misuse occurred.
Is the AWS Figure Directly Comparable With the Google Cloud Figure?
Only with care. The measures concern different identity populations and exclusions. They can be shown side by side with those definitions, but the difference should not be presented as a ranking of provider security or a comparative breach rate.
Should Every Long-Lived Key Be Removed Immediately?
A review should establish ownership, purpose, permissions, and dependencies before making a change. The appropriate replacement or removal process depends on the workload. Completion should include evidence that authorized work still functions and unnecessary access has been addressed.
What Should a Cloud Access Dashboard Show?
Show the inventory scope, accountable ownership, verified control work, and unresolved exceptions. Keep coverage separate from remediation. Use these figures as external context, while reporting internal improvements through evidence that the intended access behavior has changed.
Resources
Datadog’s State of Cloud Security 2025 supplies the credential-age observations and population limits. Verizon’s 2026 DBIR supplies broader event-based research context. Both are linked where their different evidence types are explained.