AWS data security risks expose IAM and secrets gaps at scale

At a glance

What this is: This research summary draws on Cyera’s AWS telemetry to show that the biggest data security failures are configuration, identity, and logging gaps rather than flaws in AWS itself.

Why it matters: It matters because IAM, secrets, and data protection teams need a shared view of how control drift across cloud services turns routine misconfiguration into enterprise-scale exposure.

Context

AWS data security risk is rarely caused by a single broken control. It usually emerges when identity permissions, data placement, and logging are managed as separate tasks instead of one operating model.

Cyera Research Labs frames the issue as an operational one: enterprise AWS environments accumulate unencrypted data, exposed roles, plaintext secrets, and weak auditability when preventive controls do not match how services are actually used. That makes this an identity and data governance problem as much as a cloud configuration problem.

Key questions

Q: What breaks when AWS data security controls are managed separately from IAM?

A: The main failure is that permissions can expand the real attack surface faster than data owners realise. When IAM, secrets, and storage controls are governed in isolation, a role may expose more data than intended and a misconfiguration can remain invisible until access is already broad. Organisations need one view of effective access, not separate views of policy and data.

Q: Why do plaintext secrets and unencrypted cloud data create so much risk?

A: Because they preserve value for an attacker even when other controls hold. A plaintext password, API secret, or unencrypted database can be used directly if discovered, which makes the original boundary easy to bypass. The risk is greatest when those assets sit in shared cloud environments where many identities and workloads can reach them.

Q: How do security teams know if cloud logging is actually working?

A: Cloud logging is working when teams can reconstruct who accessed critical assets, when the access happened, and what was touched across the full environment. If investigations depend on gaps, manual correlation, or missing records from key systems, logging is not yet operationally effective. Coverage and usability matter more than the presence of log collection alone.

Q: Should organisations prioritise IAM cleanup or data encryption first in AWS?

A: If sensitive data is already exposed through broad permissions, IAM cleanup usually comes first because it reduces who can reach the asset at all. If data is sitting unencrypted in a high-value store, encryption becomes urgent because it reduces the value of any successful access. In practice, the right order depends on which exposure path is currently widest.

Technical breakdown

Why AWS data security fails when IAM and data controls diverge

Cloud security breaks down when the identity layer authorises broad access but the data layer still assumes a narrower exposure model. In AWS, an IAM policy can expose S3 objects, RDS instances, or Secrets Manager values long before anyone notices the effective access path. That is why misconfiguration is so often the first real control failure, not a secondary symptom. The practical issue is not AWS scale alone, but control drift across services that were configured at different times for different owners and never revalidated together.

Practical implication: review IAM permissions alongside data classification and service exposure, not as separate governance tracks.

What plaintext secrets and unencrypted RDS data reveal

Plaintext secrets and unencrypted databases show that data security in AWS is still often treated as a storage problem instead of a lifecycle problem. A password left in an unprotected volume, or an RDS instance left unencrypted, means the data remains usable even if perimeter controls hold. The real weakness is that secrets, credentials, and sensitive records are being stored in ways that outlive the intent of the original deployment. Once that happens, preventive controls cannot compensate for the absence of baseline data protection discipline.

Practical implication: enforce encryption and secrets handling at creation time, before workloads and teams accumulate technical debt.

Why logging gaps make AWS exposure harder to contain

Weak logging and monitoring turn configuration mistakes into unresolved exposure because teams lose the ability to prove what was accessed, by whom, and when. In AWS, auditability is part of the security control, not a post-incident convenience. If data flows are non-compliant or roles are overbroad, the absence of trustworthy logs prevents containment decisions from being precise. The issue is not only detection delay. It is that poor telemetry removes the evidence needed to separate benign access from actual compromise.

Practical implication: treat logging coverage and retention as core data protection controls for AWS, especially for high-value services.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Control drift, not cloud complexity, is the dominant AWS data security failure mode. The article’s central pattern is that identity permissions, secrets handling, and data placement are being managed independently even though attackers and accidental exposure exploit their overlap. Cyera’s telemetry points to the operational gap: organisations secure the service, but not the effective access path. The practitioner conclusion is that AWS risk is governed by how controls drift together, not by any single service defect.

Plaintext secrets are a governance failure, not just a hygiene issue. When usernames, passwords, or credentials are stored in unprotected volumes, the organisation has already lost the security boundary that those secrets were supposed to enforce. That is especially serious in cloud estates where workload access, automation, and human access intersect. The implication is that secret handling must be treated as lifecycle governance, not as an after-the-fact hardening task.

Identity blast radius is the right lens for public or unintended AWS exposure. The report’s recurring IAM misconfiguration theme shows how one role can turn a limited data issue into broad service access. That makes overbroad access and poor policy segmentation the real multiplier. The practitioner takeaway is to measure how far a single role can reach across storage, compute, and secret surfaces, then reduce that reach before exposure is discovered externally.

Inconsistent logging creates an evidence gap that weakens both response and accountability. If access to data services cannot be reconstructed, then response teams cannot prove containment, and governance teams cannot show control effectiveness. Cyera’s research makes auditability part of the control plane, not an auxiliary capability. The practitioner conclusion is that without dependable telemetry, AWS data security programmes cannot demonstrate that exposure is limited, detected, or investigated with confidence.

AWS data risk is increasingly a policy enforcement problem across data, IAM, and secrets management. The article shows that policy gaps surface when external access, plaintext storage, and service-level permissions are not continuously aligned. That is where preventive models fail in practice: they assume the environment remains static. The practitioner conclusion is to govern AWS as one interdependent system, not as separate security silos.

From our research library:

• Business leaders plan to spend $124 million on average on AI in 2026, and 91% say data security and risk will shape their AI strategy.

What this signals

AWS security programmes should treat identity reach and data placement as one control problem. When permissions, secrets, and storage drift apart, the environment becomes harder to govern even if each individual service looks configured correctly.

A useful named concept here is identity blast radius. It describes how far a single AWS role or credential can move across storage, compute, and secret surfaces before a control owner notices, and it is the metric practitioners should narrow first.

For practitioners

• Map effective AWS access paths Inventory which IAM roles, service accounts, and federated users can reach each sensitive data store, then compare those paths to the data classification of each asset.
• Eliminate plaintext secret storage Search workloads, attached volumes, and deployment artefacts for embedded usernames, passwords, and credentials, then replace them with managed secret retrieval patterns.
• Require encryption for sensitive RDS instances Make encryption a baseline creation control for databases that store regulated or high-value data, and verify that exceptions are formally approved and time-bound.
• Validate logging coverage against data sensitivity Confirm that S3, RDS, EC2, IAM, and Secrets Manager events are captured in a way that supports forensic review and policy enforcement for the data classes you hold.
• Reconcile policy with real data flows Review where external organisations or unintended roles can access cloud storage, then remove access paths that are inconsistent with stated sharing and residency policy.

Key takeaways

• The core AWS risk in this research is control drift across IAM, secrets, logging, and data placement rather than an inherent flaw in the platform.
• Cyera’s telemetry highlights recurring exposure patterns including unencrypted RDS data, plaintext secrets, and misconfigurations that widen access beyond intended roles.
• Teams should govern AWS by effective access and auditability, because prevention alone does not close gaps once data and identity controls diverge.

Key terms

• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.