AWS Account Security Scan: Step-by-Step Security Assessment Guide
Run an AWS account security scan in 30 minutes. Covers root MFA, S3 Block Public Access, CloudTrail, open security groups, and IAM wildcards — with CLI commands.
AWS Account Security Scan: Step-by-Step Security Assessment Guide
TL;DR: An AWS account security scan is a structured review of IAM configuration, S3 bucket permissions, network security groups, logging coverage, and cross-account trust relationships to catch misconfigurations before attackers do. The highest-impact checks, in priority order: enable MFA on the root account and stop using it day-to-day, enable S3 Block Public Access at the account level, enforce CloudTrail logging in every region, eliminate security groups open to 0.0.0.0/0 on administrative ports, and audit IAM policies for wildcard (
*:*) permissions. Most of these checks take under 10 minutes each via the AWS CLI, and a focused first-pass review covering the highest-impact items can be completed in about 30 minutes.
AWS breaches rarely start with a novel exploit against AWS's own infrastructure — they start with basic configuration hygiene that nobody got around to fixing. A temporary IAM permission granted during a development sprint that became permanent. A security group opened for a "quick test" on port 22 or 3389 that's still open to the entire internet eight months later. An S3 bucket policy that grants public read access because someone needed to share one file and never scoped it down afterward. Security researchers running paid AWS assessments consistently report finding the same handful of misconfigurations in the large majority of accounts they review.
This guide walks through exactly how to run that review — an AWS account security scan — from the account-level controls that matter most through to the CLI commands that verify each one.
What Is an AWS Account Security Scan?
Definition: An AWS account security scan is a systematic review of an AWS account's configuration — IAM users, roles, and policies; S3 bucket and object access settings; VPC network security (security groups, NACLs); logging and monitoring coverage (CloudTrail, GuardDuty); and cross-account trust relationships — checked against AWS security best practices to identify misconfigurations independent of any software vulnerability. The scan covers configuration your organization controls under AWS's shared responsibility model, not the security of AWS's underlying physical and virtualization infrastructure, which AWS itself is responsible for.
The distinction matters because AWS's own infrastructure is generally considered highly secure and independently audited — the scan is entirely about how your organization configured the account layered on top of that infrastructure, which is where nearly all real-world incidents originate.
Manual CLI Review vs. AWS Native Tools vs. Third-Party CSPM
| Manual CLI/Console Review | AWS Native (Security Hub, GuardDuty, Access Analyzer) | Third-Party CSPM | |
|---|---|---|---|
| Setup time | None — AWS CLI access only | Minutes — enable services, some ongoing cost | Requires connecting via IAM role/API |
| Coverage | Whatever the reviewer specifically checks | Broad, AWS-specific, updated with new AWS services | Often broader, frequently multi-cloud |
| Detects public S3 buckets/objects | Yes, with correct commands | Yes, via Access Analyzer for S3 | Yes, typically with additional context |
| Detects IAM policy over-permissioning | Yes, but labor-intensive to review at scale | Partially — IAM Access Analyzer flags external access | Often yes, with least-privilege recommendations |
| Detects cross-account trust misconfigurations | Only if specifically checked | Partially | Often yes, explicitly |
| Continuous drift detection | No — point-in-time only | Yes, via GuardDuty/Security Hub findings feed | Yes, typically with alerting |
| Compliance framework mapping (SOC 2, HIPAA, PCI DSS) | Manual cross-referencing required | Security Hub supports standard framework packs | Usually yes, often more comprehensive |
| Cost | Free (engineer time only) | AWS service costs (typically modest) | Subscription cost |
| Best for | Initial baseline, single-account environments | Ongoing native monitoring within AWS | Multi-account, multi-cloud, or compliance-heavy environments |
Most mature AWS security programs use a combination: native tools (GuardDuty, Security Hub, IAM Access Analyzer) for continuous baseline monitoring, supplemented by either periodic manual deep-dives or third-party CSPM for cross-account correlation and broader compliance mapping.
How to Run an AWS Account Security Scan: A Step-by-Step Guide
Step 1: Confirm Root Account MFA and Stop Using Root Day-to-Day
Verify MFA is enabled on the account root user (aws iam get-account-summary and check AccountMFAEnabled), and confirm the root account isn't used for routine operations — the root user should be locked away for account-level tasks only (like closing the account or changing support plans), with all day-to-day administrative work performed through IAM Identity Center or a scoped IAM role instead. A compromised root credential with no MFA is complete, unrestricted account takeover.
Step 2: Move Off Long-Lived IAM User Access Keys
IAM users with static, long-lived access keys are increasingly considered outdated for human access in 2026 — they lack centralized lifecycle management and are easy targets if leaked. Migrate human access to IAM Identity Center (AWS SSO) integrated with your identity provider, and for workloads (EC2, Lambda, ECS), always prefer IAM roles over embedded access keys. For any access keys that must remain, audit LastUsedDate via aws iam generate-credential-report — keys showing "None" (never used) or unused for 30+ days should be deactivated, verified safe, then deleted.
Step 3: Audit IAM Policies for Wildcard Permissions
Review IAM policies for overly broad grants — "Action": "*" or "Resource": "*", and service-level wildcards like "s3:*" applied where only a handful of specific actions are actually needed. Temporary permissions granted during development are a particularly common source of this: a broad policy attached to unblock a sprint, never scoped down once the immediate need passed. Use IAM Access Analyzer to identify policies granting access to external principals, and review service roles specifically — wildcard permissions on a service role (like an EC2 instance role or Lambda execution role) mean a single compromised workload can be chained into privilege escalation and full account takeover.
Step 4: Enable S3 Block Public Access at the Account Level
Run aws s3control put-public-access-block with all four settings enabled (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets) at the account level — this single control overrides individual bucket policies and ACLs, preventing any bucket in the account from being made public regardless of a later misconfiguration on a specific bucket. Amazon S3 remains the most commonly misconfigured AWS service and the source of numerous high-profile data breaches, precisely because a single bucket policy or ACL error is enough to expose data broadly. Even with the account-level block enabled, audit individual buckets with aws s3api get-public-access-block and aws s3api get-bucket-policy-status to confirm no documented exceptions have drifted out of scope.
Step 5: Enforce CloudTrail Logging in Every Region
Confirm CloudTrail is enabled and logging to a centralized, access-restricted S3 bucket across every region your account can operate in, not just the regions you actively deploy to — an attacker operating in an unmonitored region specifically to avoid detection is a well-documented technique, and a CloudTrail configuration scoped to only your "primary" regions leaves this gap wide open. Confirm log file validation is enabled to detect tampering, and that the destination bucket itself has public access blocked and appropriate access logging of its own.
Step 6: Review Security Groups for Overly Permissive Network Access
Audit security groups for rules allowing 0.0.0.0/0 (unrestricted internet access) on administrative ports — SSH (22), RDP (3389), and database ports (3306, 5432, 1433) are the highest-risk findings. These are frequently opened "temporarily" for a specific troubleshooting session and never closed afterward. Cross-reference against actual usage: a security group open to the world on a port with no legitimate business reason for external access should be restricted to specific IP ranges, a bastion host, or a VPN/Direct Connect path instead.
Step 7: Check for Publicly Accessible RDS Instances and Other Exposed Services
Query RDS instances for PubliclyAccessible: true and confirm each has a specific, documented business justification — most database instances should never be directly internet-reachable, with access instead routed through application servers or a controlled bastion. Extend this same review to other commonly-exposed services: API Gateway endpoints without authentication, Lambda function URLs left public, and EC2 instances with public IPs that don't need them.
Step 8: Enable GuardDuty and Security Hub for Continuous Monitoring
Enable Amazon GuardDuty for continuous threat detection across account activity, network traffic, and DNS logs, and AWS Security Hub to aggregate findings across GuardDuty, IAM Access Analyzer, and other AWS security services into a single view with compliance framework mapping (Security Hub supports standard packs aligned to frameworks like CIS AWS Foundations, PCI DSS, and NIST). This is the step that shifts the scan from a one-time review into ongoing coverage — native findings continue accumulating after the manual review is complete.
Step 9: Audit Cross-Account Trust Relationships and OIDC Federation
Review IAM role trust policies for cross-account access and, increasingly relevant in 2026, OIDC federation trust policies used for CI/CD (GitHub Actions, GitLab CI, and similar). This is a specifically underrated risk area: a documented pattern in recent audits found a substantial majority of accounts using GitHub OIDC federation had a trust policy scoped too broadly — allowing any repository within an organization, or in worse cases any GitHub repository at all, to assume a role rather than restricting it to the exact repository and branch that legitimately needs it. Verify every cross-account and federated trust relationship is scoped to the specific principal that needs it, not a broad wildcard set "once and forgotten."
Step 10: Apply Service Control Policies and Establish a Recurring Cadence
For multi-account AWS Organizations, apply Service Control Policies (SCPs) as account-wide guardrails — preventing entire categories of risky action (disabling CloudTrail, leaving specific regions unrestricted, detaching required security services) regardless of what individual IAM policies within an account might otherwise allow. Finally, schedule this review on a recurring cadence — the checks above catch a point-in-time snapshot, but permissions, security groups, and trust relationships drift continuously as teams ship new infrastructure. A quarterly deep review, supplemented by continuous native monitoring (Step 8), is the realistic minimum for most organizations.
Most Common Findings by Risk Category
| Category | Common Finding | Typical Fix |
|---|---|---|
| Root/IAM | Root account without MFA; long-lived IAM user access keys | Enable root MFA; migrate to IAM Identity Center/SSO |
| IAM policies | Wildcard Action:* or Resource:* grants, often from dev-time shortcuts |
Scope to specific actions/resources; review service roles specifically |
| Access keys | Keys unused for 30–90+ days still marked "Active" | Deactivate, verify, then delete unused keys |
| S3 | Public buckets or objects; account-level Block Public Access not enabled | Enable Block Public Access at account level; audit individual bucket policies |
| Logging | CloudTrail enabled in only "primary" regions, not all regions | Enable CloudTrail across every region the account can operate in |
| Network | Security groups open to 0.0.0.0/0 on SSH/RDP/database ports | Restrict to specific IPs, bastion hosts, or VPN paths |
| Database | RDS instances marked publicly accessible with no documented reason | Disable public accessibility; route through application layer |
| Federation | Overly broad OIDC trust policies (any repo can assume role) | Scope trust policy to exact repository and branch |
Frequently Asked Questions
How long does an AWS account security scan take? A focused first-pass review covering the highest-impact items (root MFA, S3 Block Public Access, CloudTrail coverage, open security groups) can be completed in about 30 minutes using the AWS CLI commands referenced in each step above. A comprehensive review covering all ten steps, including IAM policy audit and cross-account trust review, typically takes several hours depending on account complexity and the number of IAM policies and roles in use.
Is AWS itself insecure, or is this purely a configuration issue? AWS's underlying infrastructure is independently certified against numerous compliance frameworks and generally considered highly secure. Under the shared responsibility model, AWS secures the cloud infrastructure itself, while the customer is responsible for security in the cloud — meaning IAM configuration, S3 permissions, network rules, and logging are entirely the customer's responsibility, which is exactly why misconfiguration, not a platform flaw, is the overwhelming source of real-world AWS incidents.
What's the single highest-impact check to run first? Confirming S3 Block Public Access is enabled at the account level. A single setting override prevents any bucket in the account from being made public regardless of individual bucket policy mistakes, and S3 misconfiguration remains one of the most consistent sources of major data exposure incidents.
Why is CloudTrail coverage across all regions important if we only actively deploy to one or two? Attackers specifically look for unmonitored regions to operate in precisely because activity there won't generate alerts if logging is scoped only to your primary deployment regions — enabling CloudTrail account-wide, across every region, closes this specific blind spot regardless of which regions you actually use for production workloads.
Do AWS native tools like GuardDuty and Security Hub replace the need for a manual review? They significantly reduce ongoing manual effort by providing continuous monitoring, but an initial manual baseline review remains valuable for catching configuration issues (like overly broad IAM policies or cross-account trust misconfigurations) that native detection tools may not flag as explicitly, and periodic manual spot-checks help validate that native tooling coverage itself hasn't drifted (for example, GuardDuty accidentally disabled in a specific region).
How does this compare to a Google Workspace or Microsoft 365 tenant scan? The underlying goal is the same — catching configuration drift before attackers exploit it — but AWS's risk surface centers heavily on infrastructure-as-a-service concerns (IAM roles, network security groups, storage permissions) rather than the SaaS-specific identity and sharing concerns covered in Google Workspace and Microsoft 365/Entra ID tenant scans. Organizations using multiple platforms typically need all three reviews as part of a complete security posture.
Related Resources
- Google Workspace Tenant Scan: Step-by-Step Security Assessment Guide — the parallel guide for Google Workspace tenants
- Microsoft 365 & Entra ID Tenant Scan: Step-by-Step Security Assessment Guide — the parallel guide for Microsoft cloud tenants
- What Is Cloud Security Posture Management (CSPM)? — the continuous discipline this scan feeds into
- What Is Zero Trust Architecture? — how least-privilege IAM design implements Zero Trust in AWS
- Trusteed Cloud Security & Compliance — continuous configuration monitoring across AWS, Azure, and GCP
IAM Permissions and Security Groups Drift Every Week — A Quarterly Scan Isn't Enough
A wildcard IAM policy granted for a Friday-afternoon deploy. A security group opened for a debugging session that never got closed. An OIDC trust policy copied from a tutorial that trusts every repository in your GitHub organization instead of one. None of these show up on a dashboard unless something is actively watching — and the gap between your last quarterly review and today is exactly where real incidents happen.
Trusteed's cloud security platform extends this same continuous-monitoring discipline across AWS, Azure, and GCP simultaneously — catching IAM policy drift, public S3 exposure, and open security groups the moment they occur, with the same evidence trail that supports SOC 2, ISO 27001, and HIPAA compliance automatically.
Ready to move from a periodic scan to continuous coverage? Start scanning for free or talk to an expert to see how Trusteed keeps your AWS account configuration continuously monitored, not just reviewed once a quarter.
This post was published on the Trusteed Blog. Trusteed provides continuous cloud and SaaS security configuration monitoring — catching misconfigurations like public S3 buckets, overly permissive IAM policies, and open security groups the moment they occur, with automated evidence generation for SOC 2, ISO 27001, and HIPAA.