Data-aware IAM for AWS shows why access and sensitivity must align

At a glance

What this is: This is a Cyera analysis of how AWS IAM Access Analyzer and data classification can be combined to map who can access sensitive data and at what level.

Why it matters: It matters because IAM, NHI, and data security teams need a shared view of identity, privilege, and sensitivity before they can enforce least privilege or prove governance.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Cyera's analysis of data-aware governance for sensitive AWS data

Context

Data-aware governance means linking identity entitlements to the sensitivity of the data they can reach. In AWS, that becomes difficult quickly because users, roles, and federated identities can span accounts, inherited permissions, and resource-specific policies, which makes the primary keyword problem of data-aware IAM much harder than a simple permissions review.

The governance gap is not a lack of security policy in the abstract. It is the absence of a reliable, operational map between sensitive datasets, the identities that can reach them, and the level of access each identity actually has, which is why existing IAM reviews often miss overexposure until after damage has already occurred.

Key questions

Q: How should teams govern AWS access when sensitive data is spread across multiple accounts?

A: Teams should correlate IAM entitlements with data classification so they can see who can reach each sensitive datastore and at what privilege level. A role-only review is not enough because cross-account trust, inherited permissions, and federated identities can hide real exposure. The practical outcome is a permissions matrix that supports remediation, recertification, and audit evidence.

Q: Why do identity reviews often miss the real risk in cloud data access?

A: Because identity reviews usually stop at the principal, not the data it can reach. A role may look acceptable until it is linked to a restrictive datastore that contains regulated or business-critical information. Without sensitivity context, teams overestimate control maturity and understate the true blast radius of each entitlement.

Q: What breaks when access findings are not paired with data sensitivity?

A: Without sensitivity labels, access findings become a list of permissions instead of a risk picture. Teams cannot reliably decide which entitlements to remove first, and auditors cannot tell whether access aligns to business need. The result is slower remediation and a false sense of least privilege.

Q: How do you know if cloud least privilege is actually working?

A: You know it is working when every high-sensitivity datastore has a short, explainable list of identities with clearly bounded access and documented business need. If cross-account roles, inherited trust, or federated permissions reach sensitive data without a strong justification, least privilege is only partially implemented.

Technical breakdown

Identity-data visibility in multi-account AWS

AWS access analysis gets difficult when identity is distributed across users, roles, federated principals, and cross-account trust. A single datastore can inherit permissions from several policy layers, so a team may know that access exists without knowing whether it is read-only, write, delete, or administrative. That ambiguity is the real architectural problem: policy evaluation happens across identities and resources, while data sensitivity usually lives in a separate control plane. Data-aware governance closes that gap by correlating those two views.

Practical implication: build a permissions matrix that ties every sensitive datastore to the identities and privilege levels that can reach it.

Why IAM Access Analyzer needs data classification

IAM Access Analyzer can surface who can reach AWS resources, but access findings alone do not tell you whether the target contains customer records, operational data, or low-risk content. Data classification adds the missing context by ranking exposure according to sensitivity. That turns a raw entitlement finding into an actionable governance signal. In practice, the value is not just discovery but prioritisation: teams can focus on the combinations of identity and data that create the most material risk.

Practical implication: pair entitlement findings with data sensitivity labels before triage so high-risk exposures are reviewed first.

Least privilege becomes measurable when access and sensitivity are linked

Least privilege is often stated as a policy goal but enforced inconsistently because teams lack a way to test whether a principal’s access is actually aligned to the data it needs. When access is mapped to sensitivity, privilege can be measured against business context rather than abstract roles. That makes review, remediation, and audit evidence much stronger. It also exposes inherited access and overly broad trust relationships that would otherwise sit unnoticed inside cloud policy sprawl.

Practical implication: use the access and sensitivity map as the evidence base for entitlement cleanup, recertification, and audit response.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

Data-aware IAM is now the difference between policy and proof. Cloud teams can write least-privilege policies all day and still fail to answer the operational question of who can reach which sensitive datastore. The article shows that the missing layer is not another IAM control in isolation, but the correlation of identity, access, and sensitivity at scale. Practitioners should treat data-aware visibility as the proof layer for governance, not a reporting enhancement.

Visibility gaps in AWS are really NHI governance gaps. Roles, service identities, and federated entities can all accumulate access across accounts and resources, which makes overexposure easy to miss. That is especially relevant where non-human identities outnumber people and are reviewed less often than human accounts. The control failure is not merely incomplete inventory, but the inability to see how non-human access translates into data reach. Practitioners should reframe AWS access review around exposed data, not just exposed principals.

Access review without sensitivity context overstates control maturity. A clean entitlement list can still hide dangerous access if the underlying datastore contains regulated or highly sensitive information. This is where frameworks such as OWASP-NHI and the NIST Cybersecurity Framework matter together, because the problem spans discovery, protection, and governance. The implication for teams is clear: reviews that ignore data classification produce audit comfort, not risk reduction.

Identity blast radius expands when inherited permissions are invisible. The practical concept here is the blast radius created when one role or federated identity can touch multiple datastores across account boundaries. That blast radius becomes measurable only when access findings are joined to sensitivity labels. For practitioners, the governance task is to shrink reachable sensitive surface area before it becomes an incident path.

Cross-account access is a lifecycle problem as much as a policy problem. When permissions persist across changing account structures, teams often lose track of whether access still matches business need. The article’s core lesson is that governance fails when entitlements are not continuously reconciled against data criticality. Practitioners should treat entitlement drift and data drift as the same control issue.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For the broader lifecycle context, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how entitlement review, rotation, and offboarding fit together.

What this signals

Identity-data correlation is becoming the practical control plane for cloud governance. Teams that can only see IAM policy will keep missing the exposure created when a sensitive datastore is reachable through inherited or federated access. The next maturity step is not more inventory, but clearer linkage between entitlement, data classification, and review action, especially where non-human identities are involved.

Data-aware visibility will increasingly separate audit theatre from real reduction in exposure. When only 5.7% of organisations have full visibility into their service accounts, per the Ultimate Guide to NHIs, cloud governance programmes cannot rely on principal lists alone. The teams that win will be the ones that can explain every high-risk access path in business terms, then show the remediation trail.

Identity blast radius is the right named concept for this control problem. It describes the amount of sensitive data a single identity can reach across accounts, resources, and trust boundaries, and it is the metric practitioners should watch as AWS estates expand. That lens aligns naturally with the NIST Cybersecurity Framework 2.0 because the point is to make exposure visible, not merely documented.

For practitioners

• Map sensitive datastores to all reachable identities Build a permissions matrix that joins AWS IAM findings to sensitivity labels for S3, RDS, DynamoDB, and snapshots, then review cross-account access first.
• Prioritise cleanup by sensitivity level Triage the highest-risk combinations of privileged access and restrictive data classifications before you spend time on low-impact entitlements.
• Re-run access reviews against actual data exposure Use the correlated access view as the evidence pack for recertification, audit, and least-privilege remediation, rather than reviewing roles in isolation.
• Treat inherited trust as a separate risk class Flag trust relationships and federated permissions that span multiple accounts, because those paths often create the largest unreviewed exposure to sensitive data.

Key takeaways

• The core risk is not just excess IAM access, but the inability to connect that access to the sensitivity of the data it can reach.
• When organisations cannot map identities to sensitive datastores at scale, least privilege becomes a policy statement rather than an enforceable control.
• Practitioners should use correlated access and classification data as the basis for cleanup, recertification, and audit evidence.

Key terms

• Data-aware governance: Data-aware governance is the practice of tying access decisions to the sensitivity of the data being protected. In cloud environments, it means combining identity entitlements with data classification so teams can judge not just whether access exists, but whether that access is justified and proportionate.
• Identity-data correlation: Identity-data correlation is the process of linking IAM principals, roles, and trust relationships to specific datasets and their sensitivity labels. It turns raw access findings into a governance view that supports least privilege, audit evidence, and remediation prioritisation across complex cloud estates.
• Identity blast radius: Identity blast radius is the amount of sensitive data, systems, or accounts a single identity can reach if it is over-permissioned or misconfigured. It is a practical measure of exposure, especially in multi-account cloud environments where inherited access can quietly widen the impact of one compromised principal.

Deepen your knowledge

Data-aware IAM for AWS is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to turn cloud access review into measurable governance, this is a useful place to start.

This post draws on content published by Cyera: Know Your Data, Control Your Access: How Cyera and AWS IAM Access Analyzer Deliver Data-Aware Governance for Sensitive Data in AWS. Read the original.