Skip to main content

​
Overview

IAM Audit generates two CSV reports that provide a comprehensive view of identity security posture across all accounts in your AWS Organization. This guide explains how to interpret the data and identify actionable security risks.

​
Report Files Generated

Every audit run produces timestamped CSV files:

IAM Audit Report

iam_audit_report_YYYYMMDD_HHMMSS.csvComplete inventory of IAM users, access keys, MFA status, and console access across all accounts.

CloudTrail Events

cloudtrail_events_YYYYMMDD_HHMMSS.csvIAM-related events for tracking remediation progress over time (user/key deletions, creations).

​
Understanding the IAM Audit Report

​
CSV Structure

The main audit report contains 11 fields per user: 
account_id,account_name,username,password_status,password_last_used,access_key_id,status,created_date,last_used_date,service_name,mfa_status
123456789012,Production,john.doe,Configurada,2026-03-01 14:23:45,AKIAIOSFODNN7EXAMPLE,Active,2023-01-15 09:30:00,2026-02-28 18:45:12,s3,Virtual

​
Field Definitions

FieldDescriptionSecurity Relevance
account_idAWS account IDIdentifies where the risk exists
account_nameAccount name from OrganizationHuman-readable context
usernameIAM user nameWho owns the credential
password_statusConfigurada or No configuradaConsole access enabled
password_last_usedTimestamp or NuncaConsole activity indicator
access_key_idAccess key identifierSpecific long-term credential
statusActive or InactiveKey can be used right now
created_dateKey creation timestampAge of the credential
last_used_dateMost recent usage or Nunca utilizadaActivity indicator
service_nameAWS service last accessedBlast radius of compromise
mfa_statusVirtual, Hardware, or NoneSecond factor protection

​
Risk Scoring Framework

​
High-Risk Indicators

Immediate Action Required: These findings represent critical security gaps.
Criteria:
  • password_status: Configurada
  • mfa_status: None
  • password_last_used is recent (within 30 days)
Risk: Account takeover via password compromise. Single-factor authentication is insufficient for production environments.Example:
987654321098,Production,admin-user,Configurada,2026-03-04 10:15:33,AKIAI...,Active,2025-12-01 08:00:00,2026-03-03 16:20:10,iam,None
Priority: Critical — remediate within 24 hours.
Criteria:
  • created_date is more than 365 days ago
  • status: Active
  • Key appears in active use (last_used_date is recent)
Risk: Long-term credentials violate AWS best practices. Older keys have higher probability of being exposed, logged, or embedded in legacy systems.Example:
123456789012,Legacy-App,service-account,No configurada,Nunca,AKIAJ...,Active,2018-06-22 11:30:00,2026-03-02 14:50:00,dynamodb,None
Priority: High — migrate to IAM roles or temporary credentials within 30 days.
Criteria:
  • status: Active
  • last_used_date: Nunca utilizada
  • Key exists for more than 7 days
Risk: Forgotten or abandoned credentials. These keys may have been created for testing, lost in documentation, or never deactivated after a migration.Example:
555666777888,Development,test-user,No configurada,Nunca,AKIAZ...,Active,2025-11-10 09:00:00,Nunca utilizada,N/A,None
Priority: Medium — safe to delete immediately after brief verification.

​
Medium-Risk Indicators

Scheduled Remediation: Address these findings in your next security sprint.
  • Keys 90+ days old with recent usage: Still active, but aging credentials
  • Console users with MFA but old passwords: Enforce password rotation policies
  • Inactive keys that haven’t been deleted: Clean up unnecessary resources
  • Service accounts with console access: Service identities shouldn’t have passwords

​
Low-Risk Indicators

Best Practices: Already aligned with AWS recommendations, but continue monitoring.
  • Keys less than 30 days old with active usage
  • Console users with MFA enabled (Virtual or Hardware)
  • Inactive keys scheduled for deletion
  • Service accounts without console access and with temporary credential usage

​
Pattern Analysis Across Accounts

​
Identifying Systemic Issues

Look for patterns that indicate organizational problems rather than individual mistakes:

​
Anti-Pattern: Uniform Key Ages

account_id,account_name,username,access_key_id,created_date
111111111111,Account-A,deploy-user,AKIAI...,2023-01-15 10:00:00
222222222222,Account-B,deploy-user,AKIAJ...,2023-01-15 10:05:00
333333333333,Account-C,deploy-user,AKIAK...,2023-01-15 10:10:00
Diagnosis: Same username with keys created on the same date across multiple accounts suggests a multi-account deployment pattern using long-term credentials. Solution: Migrate to cross-account IAM roles or AWS Systems Manager Session Manager.

​
Anti-Pattern: Shared Service Accounts

account_id,account_name,username,access_key_id,mfa_status,last_used_date,service_name
444444444444,Production,shared-dev,AKIAL...,None,2026-03-05 08:30:00,ec2
444444444444,Production,shared-dev,AKIAM...,None,2026-03-05 09:15:00,s3
Diagnosis: Multiple active keys for one user, both recently used with different services. Indicates credential sharing among team members. Solution: Create individual IAM users or federate with your identity provider.

​
Anti-Pattern: Zombie Accounts

account_id,account_name,username,password_status,password_last_used,last_used_date
555555555555,Legacy,john.smith,Configurada,2024-06-15 11:20:00,Nunca utilizada
Diagnosis: Console access configured but not used in 9+ months. Access key never used. User likely left the organization. Solution: Delete the IAM user entirely after verifying with HR/IT.

​
Understanding CloudTrail Events

​
Event Types Tracked

The CloudTrail report captures five IAM lifecycle events:

User Lifecycle

  • CreateUser
  • DeleteUser

Access Key Lifecycle

  • CreateAccessKey
  • DeleteAccessKey

Console Access

  • DeleteLoginProfile

​
Tracking Remediation Progress

Use CloudTrail events to measure security improvements over time: 
eventTime,eventName,username,account_id,account_name,resources
2026-03-01 10:30:00,DeleteAccessKey,admin-user,123456789012,Production,AKIAIOSFODNN7EXAMPLE
2026-03-01 10:31:00,DeleteLoginProfile,security-team,123456789012,Production,old-contractor
2026-03-02 14:20:00,DeleteUser,security-team,123456789012,Production,old-contractor
Analysis: Proper user offboarding sequence — access key deleted first, console access removed, then user deleted.

​
Example Analysis Workflows

​
Workflow 1: Production Account Audit

1

Filter Production Accounts

grep "Production" iam_audit_report_*.csv > production_findings.csv
2

Identify Critical Risks

Search for:
  • Users with password_status: Configurada AND mfa_status: None
  • Access keys where created_date is older than 1 year
3

Group by User

Some users may have multiple keys. Count total keys per username to identify power users.
4

Cross-Reference CloudTrail

Check if any remediation actions have already been taken but not yet reflected in the latest audit.
5

Generate Remediation List

Create a prioritized task list with account ID, username, and specific action required.

​
Workflow 2: Key Age Distribution

1

Extract Key Ages

Calculate days since created_date for all active keys.
2

Bucket by Age

  • 0-30 days (acceptable)
  • 31-90 days (rotate soon)
  • 91-365 days (overdue)
  • 365+ days (critical)
3

Identify Outliers

Keys older than 2-3 years in production are major findings.
4

Check Usage Patterns

  • Old + recently used = migration priority
  • Old + never used = safe deletion candidate

​
Workflow 3: MFA Coverage Assessment

1

Count Total Console Users

Filter for password_status: Configurada
2

Count MFA-Enabled Users

Filter for mfa_status that is NOT None
3

Calculate Coverage Percentage

MFA Coverage = (MFA Users / Total Console Users) × 100
4

Segment by Account Type

Production accounts should have 100% MFA coverage. Development accounts may have more flexibility.
5

Track Monthly Trends

Re-run audit monthly and measure coverage improvement.

​
Red Flags Requiring Immediate Investigation

If you find these patterns, investigate immediately for potential security incidents.

​
Unexpected Active Keys

  • Finding: Access key created in the last 24 hours for a user you don’t recognize
  • Action: Check CloudTrail for CreateAccessKey event source and investigate

​
Service Usage Anomalies

  • Finding: service_name shows access to services your organization doesn’t use
  • Action: Review recent API calls in CloudTrail for that access key

​
MFA Removal

  • Finding: CloudTrail shows DeactivateMFADevice events you didn’t authorize
  • Action: Potential account compromise — rotate credentials immediately

​
Multiple Keys Per User

  • Finding: User has 2 active access keys (AWS maximum)
  • Action: Verify with user why both are needed — may indicate shared credentials

​
Next Steps

Remediation Guide

Step-by-step workflows to fix identified issues

Security Maturity Model

Understand how findings map to AWS SMM controls

Configuration

Set up permissions for cross-account auditing

CloudTrail Analysis

Deep dive into event analysis

Build docs developers (and LLMs) love

Get started for freeTalk to us