Learn how AWS IAM Access Analyzer identifies external access, internal access paths, unused permissions, and policy issues — and how security researchers should interpret its findings.

============================================================ INTRODUCTION: A POLICY CAN LOOK REASONABLE AND STILL EXPOSE ACCESS

AWS permissions are spread across identity policies, resource-based policies, role trust policies, organization controls, permissions boundaries, and other authorization settings. Reviewing one JSON statement at a time can miss the bigger picture: a resource may be shared outside the organization, a role may trust an unexpected account, or a policy may grant more access than an application needs.

AWS IAM Access Analyzer helps answer several of these questions. Depending on which analyzer and feature you configure, it can identify access granted to principals outside a defined zone of trust, identify possible internal access to selected resources, highlight unused access, validate policy documents, and generate policy suggestions from observed activity.

It is not a universal vulnerability scanner. A finding describes a particular access condition or policy concern. It does not automatically prove that sensitive data was read, that an external party used the access, or that an attacker can compromise an AWS account. The finding must be understood in the context of the resource, principal, permissions, conditions, and business requirement.

This article explains the major capabilities and how to use them during an authorized AWS security review.

============================================================

WHAT IS AWS IAM ACCESS ANALYZER? ============================================================

IAM Access Analyzer is an AWS Identity and Access Management capability that analyzes access policies and helps teams understand and refine access. Its features cover different questions, so it is important not to treat every finding as the same kind of alert.

The main capabilities include:

External access analysis: identifies supported resources whose resource-based policies allow access from outside a defined zone of trust.
Internal access analysis: identifies possible access paths from principals within the selected account or organization to selected resources.
Unused access analysis: identifies roles, credentials, or permissions that have not been used within a configured period, subject to feature support and configuration.
Policy validation: checks policy grammar and AWS best practices, returning errors, warnings, security warnings, and suggestions.
Policy generation: uses CloudTrail activity over a selected period to suggest an identity policy based on observed actions.
Custom policy checks: can compare a proposed policy with a reference policy or evaluate whether specified critical actions are allowed, depending on the check used.

These features have different prerequisites, supported resource types, and potential charges. Check current AWS documentation and pricing before enabling features across many accounts or Regions.

Official documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html

============================================================ 2. UNDERSTAND THE ZONE OF TRUST

For external access analysis, the zone of trust is the account or organization selected when configuring the analyzer. Principals inside that boundary are treated as trusted for the purpose of external-access findings. A resource-based policy that grants access beyond that boundary can produce a finding.

For example, suppose an organization chooses its AWS Organization as the zone of trust. An S3 bucket policy in one member account grants read access to a principal in an unrelated AWS account. That sharing may be reported as external access. If a resource is shared with another account inside the selected organization, that relationship may not be reported as external because both accounts are inside the configured trust boundary.

This does not mean that every in-organization grant is safe. A compromised internal role, overly broad access between teams, or an inappropriate internal trust relationship can still matter. The boundary defines how the analyzer classifies access; it is not a business approval or a complete security judgment.

The zone of trust must match the organization's intended trust model. An analyzer configured for a single account will classify external access differently from one configured for the whole organization.

============================================================ 3. EXTERNAL ACCESS FINDINGS: WHAT THEY DO AND DO NOT MEAN

External access analysis examines supported resource-based policies. Depending on the resource type, these can include S3 bucket policies and ACLs, IAM role trust policies, KMS key policies and grants, Lambda resource policies, and other supported resource policies.

An IAM role is a global resource, but external-access findings for a role may appear in each enabled Region where the analyzer is configured. Supported resource types differ between external and internal analysis, so verify the current AWS resource support list rather than assuming every AWS service is covered.

An external access finding can be valuable even if there is no evidence that anyone used the access. The analyzer evaluates whether the policy permits a type of external access; it does not need to observe an actual external request before identifying that policy condition.

That distinction matters during triage:

A finding is evidence of a policy-based access path as understood by the analyzer.
It is not evidence that the external principal actually accessed the resource.
It does not necessarily establish that the resource contains sensitive data.
It does not necessarily mean the access violates the resource owner's intended sharing model.
It may not provide visibility into the configuration or permissions inside the external account.

A finding should prompt investigation, not an automatic claim of compromise.

============================================================ 4. INTERNAL ACCESS ANALYSIS

External sharing is only one side of access control. Organizations also need to understand which internal principals can reach important resources and why.

Internal access analysis can identify possible access paths between IAM users or roles within a selected account or organization and the resources selected for monitoring. It evaluates relevant policies, which may include identity-based policies, resource-based policies, service control policies, resource control policies, and permissions boundaries, where supported by the feature.

This can help answer questions such as:

Which internal roles can access a sensitive S3 bucket?
Is access granted through an identity policy, a resource policy, or a combination?
Does a principal have access that its team does not appear to require?
Are there complex policy relationships that are difficult to identify by reading a single policy?

Internal access analysis requires its own configuration and supports a defined set of resource types. Do not assume that enabling an external access analyzer automatically provides internal access findings for every resource. Consult the current documentation for supported resources and API operations.

A principal being able to access a resource is not automatically a vulnerability. The reviewer must determine whether that access is intended, appropriately scoped, and consistent with the organization's data classification and business needs.

============================================================ 5. UNUSED ACCESS: PERMISSIONS THAT MAY NOT BE NEEDED

Unused access analysis helps teams review access that has not been used during a specified usage window. Depending on the configuration, findings can include unused roles, IAM user access keys or passwords, and permissions that have not been used.

This is useful for least-privilege work. A role may have accumulated permissions over time as an application evolved. Activity data can help identify permissions that appear unnecessary for the role's observed workload.

However, unused does not always mean unnecessary. A permission might be used only during a monthly close, a disaster recovery exercise, a deployment, or another infrequent operation. A review window that is too short may incorrectly make a legitimate permission look disposable.

Before removing access:

Understand the role or user's purpose and owner.
Check the configured analysis window and the activity represented.
Consider scheduled, emergency, deployment, and recovery tasks.
Compare observed use with application and operational requirements.
Test proposed changes in a safe environment and monitor for failures.
Remove permissions in a controlled change, with a rollback plan.

Unused-access findings are leads for a least-privilege review — not a command to delete permissions without context. Feature availability and billing depend on the analyzer type and scope.

============================================================ 6. POLICY VALIDATION: FINDING POLICY PROBLEMS BEFORE DEPLOYMENT

IAM Access Analyzer policy validation checks IAM policy documents against policy grammar and AWS best practices. Findings can include:

Errors: issues that can prevent a policy from functioning as intended.
Security warnings: statements that AWS identifies as potential security risks, such as overly permissive access patterns.
General warnings: concerns about policy quality or best practices.
Suggestions: recommendations that may improve the policy without necessarily changing its permissions.

Validation can identify malformed policy structures, incorrect action names, ARN formatting problems, and policy patterns that deserve review. It does not prove that a policy is safe in every deployment context, and a clean validation result does not guarantee that the resulting architecture is secure.

You can validate a local policy document using the AWS CLI. The following command is an example for an identity-based policy document saved as policy.json:

aws accessanalyzer validate-policy
— policy-document file://policy.json
— policy-type IDENTITY_POLICY
— region us-east-1

What it does: submits the policy document for validation. IDENTITY_POLICY tells the API that the document is an identity-based policy. The Region is included because Access Analyzer is configured and used in a regional context for this operation.

What to inspect: finding type, issue code, message, and the policy location referenced by the finding. Correct the policy or document why the warning is acceptable, then validate again. The command above is an example; no output is asserted here because it has not been run against the reader's AWS environment.

For resource-based policies, use the appropriate policy type supported by the API and ensure the document matches that policy category. Check the current CLI reference for accepted values and service-specific requirements.

Official documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html

============================================================ 7. POLICY GENERATION FROM CLOUDTRAIL ACTIVITY

Policy generation can use AWS CloudTrail activity to suggest an IAM policy based on actions and services used by an IAM entity during a selected period. This can provide a starting point for reducing permissions to those that an application appears to need.

The important phrase is "appears to need." The generated policy reflects observed activity in the selected logs and time range. If an operation did not occur during that period, it may not appear in the generated policy even if the application needs it occasionally. The generated policy also needs review for resource scope, conditions, and operational requirements.

A safe workflow is:

Select a representative period that includes normal operations and infrequent tasks where possible.
Generate the policy suggestion from the relevant CloudTrail activity.
Review each action and its resource scope.
Add appropriate resource restrictions and conditions where supported and practical.
Test the candidate policy outside production.
Monitor for denied operations and adjust only when justified.
Keep a rollback path when replacing existing permissions.

Do not blindly replace a working production policy with a generated document. Activity-based policy generation is an aid to least privilege, not a complete substitute for application knowledge and testing.

============================================================ 8. CUSTOM POLICY CHECKS AND CHANGE REVIEW

Custom policy checks help teams apply their own access standards. One use is checking whether a proposed policy grants new access compared with a reference policy, such as an existing version. Another check can determine whether specified critical actions are allowed by a policy.

This is particularly useful during permission changes. A developer may add an action to solve an application issue, but the change could also expand access beyond the intended scope. Comparing the proposed document against a baseline helps make that expansion visible.

For security review, ask:

What access is new compared with the previous policy?
Is the new access required for the application's function?
Does it apply to all resources or only the intended resources?
Are conditions needed to narrow when the action can be used?
Does the change introduce a sensitive action, such as changing permissions or passing a role to a service?
Have the consequences of the change been tested?

Custom policy checks can incur charges. Review current AWS pricing and feature requirements before adding them to automated pipelines at scale.

============================================================ 9. A PRACTICAL, AUTHORIZED REVIEW WORKFLOW

If you are reviewing an AWS account you are authorized to assess, use a consistent process rather than treating each finding as a standalone vulnerability.

Step 1 — Confirm scope

Identify the AWS account or organization, Regions, resources, and authorization boundaries included in the review. Confirm whether the analyzer's zone of trust reflects the organization's intended boundary.

Step 2 — Identify configured analyzers

Use the AWS CLI to list analyzers in the selected Region:

aws accessanalyzer list-analyzers — region us-east-1

This command lists analyzer configurations visible to the current identity in that Region. It does not list every analyzer in every Region, and access depends on the caller's permissions.

Step 3 — Review findings

For an external-access analyzer, after identifying its analyzer ARN, you can query findings:

aws accessanalyzer list-findings
— analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/example-analyzer
— region us-east-1

The ARN is an illustrative placeholder, not a real analyzer. Replace it with an ARN returned by your authorized environment. The operation shown is for findings exposed by the ListFindings API; internal-access findings use the newer findings API operation and should be queried according to the current AWS CLI documentation.

Step 4 — Triage the finding

Record the resource, principal or external account, access type, actions or permissions, relevant policy, conditions, finding status, and intended business use. Verify whether the finding is active and whether any recent configuration changes affect its interpretation.

Step 5 — Verify effective access

Read the relevant policy and authorization context. For an IAM role, inspect its trust policy as well as its permissions. For S3, inspect the relevant bucket/access-point policies and Block Public Access settings. For KMS, examine the key policy and grants. Consider applicable organization controls and resource-specific restrictions.

Step 6 — Determine impact

Establish what the principal could do, to which resource, under which conditions. If the resource contains sensitive information, confirm that separately using authorized evidence. Do not infer data exposure from a policy finding alone.

Step 7 — Recommend and verify remediation

Narrow principals, actions, resources, and conditions where appropriate. Remove unintended sharing, adjust role trust, or reduce unnecessary permissions. Validate the revised policy, test dependent workloads, and confirm that the analyzer finding resolves after AWS has re-evaluated the relevant configuration.

============================================================ 10. EXAMPLE: AN UNEXPECTED CROSS-ACCOUNT ROLE TRUST

Consider a hypothetical organization that operates an IAM role named ReportingRole. The role trust policy allows a principal from an external AWS account to assume it. The organization does not recognize the external account as a reporting vendor.

An external-access analyzer may generate a finding because the role's trust policy allows a principal outside the configured zone of trust. The finding is a useful starting point, but the investigation is not finished.

The reviewer should:

Identify the external principal and the role's trust policy statement.
Check whether the principal is a specific role, account, or another supported principal type.
Examine conditions such as external ID or other context restrictions, where relevant.
Inspect the role's identity-based and inline permissions.
Consider permissions boundaries, session policies, and organization controls where applicable.
Ask the resource owner whether the relationship is approved.
Determine what resources and actions the role could access if assumed.
Review relevant CloudTrail records for evidence of actual role assumption or subsequent activity, if logs are available and within scope.

If the relationship is not authorized, remediation might involve removing the external principal or tightening the trust policy. If the relationship is legitimate, document the owner, purpose, expected principal, required conditions, and review date.

The key distinction is that the analyzer can identify a policy-based external access relationship. It does not independently prove that the external account used the role or accessed sensitive information.

============================================================ 11. COMMON MISINTERPRETATIONS

"An external access finding means the account was compromised."

No. It identifies a policy-based access condition. Investigate logs and resource impact separately.

"No finding means the AWS environment is secure."

No. Analysis is limited by configuration, supported resource types, policy types, and feature scope. Other risks may exist outside the analyzer's coverage.

"An unused permission should always be deleted."

Not without understanding the activity window and operational purpose. Infrequent recovery or administrative tasks may not appear in recent activity.

"Policy validation passed, so the policy is least privilege."

Validation is helpful, but it cannot replace understanding the application's requirements, effective permissions, resource scope, and surrounding architecture.

"Internal access is always safe because it stays inside the organization."

Internal access can still violate separation of duties or expose sensitive resources to principals that do not need them. The organization boundary is not a blanket approval.

"Every AWS resource is analyzed."

No. Resource support varies by analyzer type and feature. Check the current AWS documentation for the exact resource type and feature being used.

============================================================ 12. DETECTION, GOVERNANCE, AND REMEDIATION

Organizations should treat Access Analyzer as part of an ongoing access-governance process.

Configure external-access analyzers with a clearly defined zone of trust.
Consider internal-access analysis for selected high-value resources where supported.
Use unused-access findings as input to periodic least-privilege reviews.
Validate new and modified IAM policies in development and deployment workflows.
Review policy changes against a known baseline when appropriate.
Route findings to a resource owner who can decide whether access is expected.
Track findings through remediation, exception approval, or documented acceptance.
Recheck the finding after the relevant policy changes and allow for analysis delays.
Monitor Access Analyzer API activity with CloudTrail where relevant to audit and governance requirements.

Remediation should be specific. A generic recommendation to "fix IAM" is not enough. State which principal or action should be restricted, which resource is affected, which condition is missing or too broad, and how the change will be validated without breaking legitimate use.

============================================================ 13. SECURITY RESEARCHER CHECKLIST

When reviewing an IAM Access Analyzer finding, ask:

What analyzer type generated it: external, internal, or unused access?
What account or organization defines the zone of trust?
Is the resource type supported by the feature in question?
Which policy or access relationship triggered the finding?
Which principal is granted access, and is that principal expected?
Which actions and resources are permitted?
Which conditions restrict access, and can the relevant principal satisfy them?
What other policy controls affect effective access?
Is there evidence of actual use, or only a policy-based possibility?
Does the resource contain sensitive data or provide a meaningful capability?
Is the access approved and documented by the owner?
What is the smallest safe remediation?
How will the change be tested and monitored?
Has the finding resolved after the policy was changed?

Use the result to build an evidence-based assessment. A valid finding may identify an important misconfiguration, but severity depends on the access granted, the resource's sensitivity, the principal's capabilities, and the real-world consequences.

============================================================ FINAL TAKEAWAY

AWS IAM Access Analyzer helps security teams understand access relationships and improve least privilege, but its different capabilities answer different questions.

External access analysis highlights supported resources shared beyond a defined trust boundary. Internal access analysis helps identify possible paths to selected resources from principals within that boundary. Unused access analysis helps identify permissions and credentials that may deserve review. Policy validation and generation help teams author and refine policies, while custom checks can support organization-specific controls.

The security value comes from interpreting each result in context. Confirm the policy, principal, resource, conditions, effective permissions, business purpose, and evidence of actual use before deciding whether a finding is a vulnerability or an acceptable relationship.

A finding is a lead. Evidence and authorization context determine the conclusion.

============================================================ RESEARCH NOTES AND PRIMARY AWS SOURCES

Using AWS IAM Access Analyzer https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
IAM Access Analyzer findings https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html
Understand how IAM Access Analyzer findings work https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-concepts.html
Validate policies with IAM Access Analyzer https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html
IAM Access Analyzer supported resource types for external and internal access https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html
Checks for validating policies https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-checks-validating-policies.html