In March 2023, AWS added "unused access" analysis to IAM Access Analyzer, turning a tool that used to only flag resources shared outside your account into something closer to a full-time permissions auditor. That matters because most AWS environments accumulate excess entitlements silently: a contractor's role that should have been deleted eighteen months ago, an S3 bucket policy that quietly grants a partner account read access nobody remembers approving, an EC2 instance role with s3:* because someone was in a hurry during a migration in 2021. AWS IAM Access Analyzer is the native service built to surface exactly these problems — external access paths and unused permissions — without agents, third-party scanning, or manual policy review. This post walks through how it actually finds external access, what unused access findings look like in practice, how its policy generation feature helps you tighten permissions, and where the tool's native limits mean you still need something more.
What Is AWS IAM Access Analyzer?
AWS IAM Access Analyzer is a free, native AWS service that uses automated reasoning (a form of mathematical logic-based analysis, not simple pattern matching) to determine which resources in your account or organization are accessible from outside a defined "zone of trust." You enable it per-region by creating an analyzer scoped to either an AWS account or an entire AWS Organization, and it continuously evaluates resource-based policies — for S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, Secrets Manager secrets, and SNS topics — against that trust boundary. Since 2023, it also evaluates identity-based policies for unused permissions. Unlike a config rule that runs on a schedule, Access Analyzer re-evaluates continuously as policies change, so a new finding typically appears within about 30 minutes of a policy modification that introduces external or excessive access.
How Does IAM Access Analyzer Find External Access?
It finds external access by mathematically evaluating every resource policy against your declared zone of trust and flagging any statement that grants access to a principal outside it. The underlying technique, called automated reasoning, doesn't simulate individual requests — it proves, for the full space of possible inputs, whether a policy permits access from outside the trust zone. This is why the external access analyzer catches conditions and wildcards that a human reviewer or a simple string-match tool would miss, such as a bucket policy that allows Principal: "*" but is actually locked down by a aws:SourceVpce condition (a false positive Access Analyzer correctly suppresses) versus one locked down by a condition key that doesn't actually restrict the principal (a true positive it correctly flags). In practice, teams running this for the first time across a multi-account AWS Organization commonly find 5-20 previously unknown cross-account or public findings in the first scan — old S3 buckets shared during a proof-of-concept, KMS keys granted to a vendor account that was later offboarded, or Lambda function policies left open from a testing phase.
What Are Unused Access Findings and Why Do They Matter?
Unused access findings identify IAM roles, users, permissions, and access keys that have gone unused for 90 days or more, and they matter because unused privilege is pure downside risk with zero operational upside. Access Analyzer breaks this into four finding types: unused IAM user credentials (passwords or access keys not used in 90+ days), unused IAM roles (roles with no activity in 90+ days), unused permissions (individual actions granted but never invoked, determined by comparing granted permissions against IAM Access Advisor's service-level last-accessed data), and unused access keys. This is the finding type most directly tied to blast-radius reduction: if an attacker compromises a role, the damage they can do is bounded by what that role can actually do, not what it was originally provisioned to do. A role created for a Q3 2022 data migration that still holds dynamodb:* and s3:* permissions two years later, but has only actually called s3:GetObject in that window, is a textbook unused access finding — and a textbook example of the gap between granted and used permissions that most organizations can't quantify without tooling like this.
How Does IAM Access Analyzer Policy Generation Work?
IAM Access Analyzer policy generation works by analyzing a role or user's actual CloudTrail activity over a chosen time window (up to the trailing 90 days) and generating a least-privilege IAM policy containing only the actions that were genuinely used. Instead of manually reverse-engineering what a role "should" be allowed to do, you point policy generation at 90 days of CloudTrail logs for that principal, and it produces a ready-to-review JSON policy scoped to observed service and action usage. This is the practical remediation counterpart to unused access findings: the analyzer tells you a role has excess permissions, and policy generation drafts the fix. Teams typically use it in a review-then-apply workflow rather than blind automation, since CloudTrail-based generation can miss legitimately-used-but-rare actions (an annual disaster-recovery failover permission, for instance, won't show up in a 90-day window), so the generated policy needs a human check against known exceptions before replacing the original.
What Are the Limits of AWS IAM Access Analyzer's Native Console?
The main limits are scope, retention, and workflow: Access Analyzer is regional and per-account by default (Organization-level analyzers help but require setup), unused access findings depend on IAM Access Advisor data that only tracks service-level usage for the past 400 days, and the console gives you a findings list, not a prioritized remediation program. There's no native severity scoring that weighs an unused-permission finding on a production payments role against the same finding on a sandbox test role, no built-in ticketing integration, no historical trend view showing whether your external-access exposure is improving quarter over quarter, and no cross-account correlation that ties an Access Analyzer finding to the actual software supply chain risk it represents — for example, whether the over-permissioned role belongs to a CI/CD pipeline with access to your build artifacts. For a single account, this is manageable in the console. Across dozens or hundreds of accounts in an Organization, findings triage becomes a full-time job unless you layer additional tooling on top.
How Safeguard Helps
Safeguard extends what native AWS IAM Access Analyzer findings can do by putting them in context with the rest of your software supply chain. Raw findings — an unused role here, an external access analyzer flag there — are hard to prioritize on their own; Safeguard correlates them against what each identity actually touches in your build and deployment pipeline, so an unused-access finding on a role tied to your artifact registry or signing keys gets surfaced ahead of the same finding on a low-impact internal tool. We ingest Access Analyzer findings across every account in your Organization, deduplicate and score them against real exploitability and blast radius, and track remediation over time instead of leaving you with a point-in-time console snapshot. Where AWS gives you the raw signal, Safeguard gives you the prioritized, supply-chain-aware view of which findings actually need attention this week — and a record you can hand to an auditor showing the finding was found, triaged, and closed, not just detected.