AWS data security risks expose IAM and secrets gaps at scale

At a glance

What this is: This is a Cyera Research Labs analysis of recurring AWS data security risks, with the central finding that misconfiguration and visibility gaps, not platform weakness, drive most exposure.

Why it matters: It matters because AWS data protection failures often begin as IAM, secrets, and logging problems that IAM and NHI teams can still prevent before they become audit or breach issues.

By the numbers:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, and organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.

👉 Read Cyera's research on the top data security risks in AWS environments

Context

AWS data security risk is usually a governance problem before it is a technology problem. When storage, identity, and secrets are configured separately, organisations can end up with public exposure, over-broad roles, and weak audit trails even when the platform itself is operating as designed. For IAM and NHI practitioners, the real issue is how quickly service identities, secrets, and data paths drift away from intended policy.

Cyera’s 2025 telemetry-based analysis points to the operational layer where cloud security breaks down: unencrypted data, misconfigured access, plaintext secrets, and incomplete logging. That pattern is typical in large AWS estates, where scale creates blind spots and teams assume preventive controls will catch what runtime visibility does not. The article is best read as an argument for tightening identity and data governance together, not separately.

Key questions

Q: How should security teams reduce AWS data security risk without slowing cloud operations?

A: Focus on the identities that move, read, or export data rather than reviewing every control equally. Start with roles that cross service boundaries, remove unnecessary privileges, enforce encryption for sensitive stores, and make logging complete enough to reconstruct access. The goal is to reduce blast radius while preserving legitimate automation.

Q: Why do plaintext secrets create such a large AWS security problem?

A: A plaintext secret is a live identity that can be reused instantly by anyone who finds it. In AWS, that can turn one exposed file or volume into access to multiple services, datasets, or accounts. Rotation matters, but scope, storage, and detection matter just as much because exposed secrets often bypass normal control layers.

Q: What is the difference between encryption and access control in AWS data protection?

A: Encryption protects data at rest or in transit, but it does not decide who is allowed to reach the data. Access control governs the identities and roles that can open, copy, modify, or export it. Mature AWS governance needs both, because encrypted data with broad entitlements can still be exposed through legitimate credentials.

Q: When does logging become a governance issue in cloud security?

A: Logging becomes a governance issue when teams cannot prove who accessed sensitive data, which role was used, or whether an external flow violated policy. At that point, monitoring is not just an operations function. It is part of the evidence chain for compliance, incident response, and control effectiveness.

Technical breakdown

Why AWS data security failures start with identity and access

In AWS, data exposure often follows identity decisions. An IAM role can grant broad service access, and once that role is attached to workloads, applications, or automation, the permissions can fan out across S3, RDS, EC2, and Secrets Manager. The technical failure is rarely one control in isolation. It is the combination of coarse entitlements, missing condition checks, and weak review of who can read, modify, or export data. When that happens, public exposure or unintended access becomes an entitlement problem, not just a storage problem. Practical implication: review roles, trust policies, and service-to-service permissions as one control plane.

Practical implication: review roles, trust policies, and service-to-service permissions as one control plane.

Secrets exposure in AWS environments

Secrets become a non-human identity problem when credentials are stored in plaintext, left in unprotected volumes, or reused across workloads. In AWS environments, that can include usernames, passwords, API keys, and tokens that are readable by more principals than intended. Once a secret is exposed, an attacker does not need to defeat the application layer first. They can authenticate as the workload, move into adjacent services, and inherit whatever access the secret grants. This is why secret storage and secret scope are inseparable from NHI governance. Practical implication: treat secrets as live identities with lifecycle, access, and rotation requirements.

Practical implication: treat secrets as live identities with lifecycle, access, and rotation requirements.

Logging, monitoring, and data-flow controls in cloud estates

Logging and monitoring are the difference between a contained policy exception and an invisible breach path. In AWS, incomplete telemetry can hide external access to sensitive storage, obscure who touched a dataset, and make it hard to prove whether a control failed or was simply never applied. Data-flow controls matter as much as asset controls because policy violations often happen when data moves between accounts, roles, regions, or external organisations. Without consistent audit evidence, response teams cannot distinguish benign automation from unauthorised access. Practical implication: map data movement, access events, and retention of audit logs to a single review process.

Practical implication: map data movement, access events, and retention of audit logs to a single review process.

Threat narrative

Attacker objective: The attacker objective is to reach sensitive cloud data and use legitimate AWS access paths to exfiltrate it or alter it without immediate detection.

1. Entry occurs through a misconfigured AWS role, exposed secret, or overly broad service permission that grants access to sensitive data services.
2. Escalation follows when the same identity can read, export, or modify data across S3, RDS, EC2, or Secrets Manager without additional checks.
3. Impact is data exposure, policy violation, or loss of auditability when logging does not capture the full access path.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AWS data security is now an identity problem disguised as a storage problem. The article’s risk list spans IAM, secrets, logging, and data movement because those controls determine who can reach data and how far that access can spread. That is the right mental model for NHI governance: a service identity with broad entitlements is functionally a data exposure mechanism. Practitioners should manage AWS data risk through identity scope, not only through data classification.

Plaintext secrets create trust debt that cloud teams eventually pay in incident response. If passwords, tokens, or keys are left in unprotected locations, the environment has already converted convenience into persistent access risk. The issue is not just secrecy, but the absence of lifecycle controls that make those credentials short-lived, attributable, and reviewable. Practitioners should treat every plaintext secret as a remediation queue item, not a configuration detail.

Weak logging turns policy into a claim instead of an enforceable control. AWS estates often look compliant until a team tries to reconstruct who accessed what, from where, and under which role. If the evidence is incomplete, the control was not effective enough for governance purposes. Practitioners should validate that audit logs, access records, and data flow evidence are retained together and reviewed together.

Static configuration is the wrong baseline for AWS data protection at enterprise scale. The report’s core message is that modern cloud estates drift faster than periodic review cycles can absorb. That makes continuous visibility, policy testing, and entitlement review a governance requirement, not an operational enhancement. Practitioners should re-evaluate any AWS security model that depends on configuration staying unchanged between audits.

Identity blast radius is the most useful concept for cloud data governance. The decisive question is no longer whether a control exists, but how far a compromised role or secret can reach before detection. That lens aligns AWS data protection with NHI governance and PAM discipline. Practitioners should measure blast radius across roles, secrets, and data paths, then reduce it with tighter scope and shorter credential lifetime.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• For a practical control lens, review the NHI Lifecycle Management Guide alongside the NIST Cybersecurity Framework 2.0 to tighten access review and response discipline.

What this signals

Identity-first cloud governance is becoming the only durable model for AWS data protection. The article reinforces a pattern security leaders already see in practice: data exposure follows entitlement sprawl, not isolated storage mistakes. With 52% of security leaders expecting AI decision-making power to shift toward platform and infrastructure teams, per the 2026 Infrastructure Identity Survey, cloud security programmes will increasingly be judged on how well they control access paths, not just asset settings.

Permission drift is now an operational indicator, not a periodic audit finding. If teams cannot continuously explain who can access data, the control plane is already lagging the environment. That is where NHI and IAM programmes need to converge with data security posture management, because unmanaged service identities are often the shortest route to policy failure.

Identity blast radius should become the central metric for AWS data risk. The practical question is how far a compromised role, token, or secret can reach before detection, and which datasets it can touch along the way. Teams that can measure that blast radius will be better placed to prioritise remediation and prove control effectiveness to auditors and leadership.

For practitioners

• Tighten IAM role scope across data services Review which roles can reach S3, RDS, EC2, and Secrets Manager together, then remove cross-service privileges that are not required for the workload’s function.
• Inventory and rotate plaintext secrets immediately Search unprotected volumes, configuration files, and deployment artifacts for usernames, passwords, API keys, and tokens, then rotate every exposed credential on discovery.
• Require encryption for sensitive cloud data stores Verify that sensitive datasets in RDS and adjacent storage layers are encrypted by default and that exceptions have explicit approval, expiry, and owner assignment.
• Unify logging for access and data movement Correlate audit logs, role assumption events, and data transfer records so teams can reconstruct who accessed data, when, and through which service path.
• Rebuild access review around identity blast radius Prioritise the roles and secrets that can reach the most sensitive datasets first, and shorten the review cycle where a single credential can touch multiple environments.

Key takeaways

• AWS data security failures usually begin with mis-scoped identity and access, not with the cloud platform itself.
• Plaintext secrets, incomplete logging, and overly broad roles create the conditions for fast policy bypass and weak forensic visibility.
• Practitioners should manage AWS data risk as a combined IAM, NHI, and data governance problem with shorter access lifecycles and tighter blast-radius limits.

Key terms

• Identity Blast Radius: Identity blast radius is the amount of data, systems, and services a single credential or role can reach if it is misused or compromised. In cloud environments, the goal is to make that reach as small, short-lived, and observable as possible.
• Plaintext Secret: A plaintext secret is a credential, token, or key stored in readable form instead of protected by encryption or a secret manager. In practice, it behaves like a live identity with immediate misuse potential, which is why discovery and rotation must be treated as urgent controls.
• Data Flow Governance: Data flow governance is the discipline of controlling where sensitive data can move, who can move it, and how that movement is recorded. It links access policy to runtime evidence so teams can spot policy violations across accounts, regions, and third-party access paths.
• Service Identity: A service identity is a non-human identity used by applications, workloads, or automation to authenticate and access resources. It may be a role, token, key, or certificate, and it needs the same lifecycle discipline as any privileged identity because it can directly expose data.

Deepen your knowledge

AWS data security risk and identity blast radius are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are tightening cloud governance around service identities and secrets, it is worth exploring.

This post draws on content published by Cyera: Assessing the Top Data Security Risks in AWS Environments. Read the original.