Skip to main content
emnode / learn
Compliance High severity

AWS Security Hub · IAM

IAM.28: No Access Analyzer is watching for unintended external access

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub IAM.28 check?

IAM.28 fails when an account-Region pair has no enabled IAM Access Analyzer external access analyzer. Because the analyzer is Regional, every active Region needs its own to pass.

Why does IAM.28 matter?

The external access analyzer uses automated reasoning to prove which resources — buckets, roles, keys, queues — are reachable by principals outside your zone of trust, catching unintended public or cross-account exposure that's easy to introduce and hard to spot by eye. With no analyzer running, an over-permissive resource policy can sit exposed indefinitely with nothing watching.

How do I fix IAM.28?

  1. Check each Region for an existing analyzer with list-analyzers.
  2. Create an external access analyzer in every Region you operate in via create-analyzer.
  3. Review its findings and resolve or archive each unintended-access entry.
  4. Bake analyzer creation into your account baseline so new Regions land compliant.

Remediation script · bash

# 1. AWS Config: bind to the service-linked role, record all resources, then start.
ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
aws iam create-service-linked-role --aws-service-name config.amazonaws.com 2>/dev/null || true
aws configservice put-configuration-recorder \
  --configuration-recorder "name=default,roleARN=arn:aws:iam::${ACCOUNT}:role/aws-service-role/config.amazonaws.com/AWSServiceRoleForConfig,recordingGroup={allSupported=true,includeGlobalResourceTypes=true}"
aws configservice start-configuration-recorder --configuration-recorder-name default

# 2. IAM Access Analyzer: create an external access analyzer in this Region.
aws accessanalyzer create-analyzer --analyzer-name external-access --type ACCOUNT

# 3. Systems Manager: enroll an instance role, then confirm it is managed.
aws iam attach-role-policy --role-name app-instance-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].{Id:InstanceId,Ping:PingStatus}' --output table

Full walkthrough (console steps, edge cases and verification) in the lesson Enable AWS security tooling (Config, Access Analyzer, SSM).

Is IAM.28 a false positive?

Inside AWS Organizations an org-level analyzer treats the whole org as the zone of trust, so cross-account access between member accounts won't be flagged — that's intended, not a missed finding.

Full lesson Enable AWS security tooling (Config, Access Analyzer, SSM) Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for IAM controls ↗ Check your own account for IAM.28 →
Part of the learning path See what's happening

More IAM controls

  • IAM.1 A policy grants full "*" administrative privileges
  • IAM.2 Policies attached directly to users do not scale or audit cleanly
  • IAM.3 Long-lived access keys have not been rotated
  • IAM.4 The root user still has long-lived access keys
  • IAM.5 Console users without MFA are one phish from compromise
  • IAM.6 The root user is not protected by hardware MFA
  • IAM.7 The IAM password policy is too weak
  • IAM.8 Unused IAM keys and passwords are waiting to be leaked
  • IAM.9 The root user can sign in without MFA
  • IAM.10 IAM user password policies should be strong (PCI DSS)
  • IAM.19 MFA should be enabled for all IAM users
  • IAM.21 Wildcard permissions grant far more access than intended