Tarek Cheikh
Founder & AWS Cloud Architect
Here's a scenario that plays out in organizations daily: your security team implements MFA requirements, trains users, and believes the account is secure. Meanwhile, that contractor account created last month still has console access with just a password. The service account someone converted to human access for "temporary testing" never got MFA enabled. The inherited AWS account from your acquisition has 47 users, and nobody knows which ones actually need console access.
These aren't theoretical risks — they're the exact attack vectors used in real breaches. Attackers specifically target AWS console access because it provides immediate visibility into your entire cloud infrastructure. A single compromised console account can expose databases, storage buckets, and application secrets.
The problem isn't that teams don't care about MFA. It's that manual checking doesn't scale, and gaps appear faster than humans can track them. You need automated scanning that continuously identifies which users have console access without MFA protection.
Multi-factor authentication reduces account compromise risk by approximately 99.9% according to Microsoft's security research. For AWS environments, this protection is particularly critical because console access provides broad visibility into cloud resources and configurations.
When IAM users have console access without MFA, several risks emerge:
The business impact extends beyond security. Compliance auditors specifically check for MFA enforcement, and gaps often trigger findings that require immediate remediation.
Many organizations rely on basic AWS CLI commands to check user MFA status:
aws iam list-users --query 'Users[].UserName' --output text
aws iam list-mfa-devices --user-name USERNAME
This manual approach has several limitations:
Organizations need comprehensive IAM auditing that combines console access detection with MFA status verification across all users simultaneously.
The MFA scanner solves three critical challenges that make manual auditing impractical:
Not every IAM user needs MFA. Service accounts and API-only users don't require console access, so MFA isn't relevant for them. The scanner distinguishes between users by checking if they have a "login profile" — AWS's technical term for console access capability.
What this means practically: The tool automatically separates human users (who need MFA) from service accounts (who don't), eliminating false positives that waste security team time.
A user account that logged in yesterday poses different risk than one created six months ago but never used. The scanner tracks both password usage and API access patterns to identify which accounts represent active security risks.
What this means practically: You get a prioritized list focusing on accounts most likely to be compromised — active users without MFA protection get flagged as "Critical" while dormant accounts are marked as "High" risk.
Manually checking MFA status involves running separate AWS commands for each user — impractical with dozens or hundreds of accounts. The scanner automates this process, checking all users simultaneously and presenting results in actionable formats.
What this means practically: A complete account audit that would take hours manually completes in minutes, with results formatted for both immediate action and compliance documentation.
Before running the scanner, you'll need:
# Get the scanner tool
git clone https://github.com/TocConsulting/aws-helper-scripts.git
cd aws-helper-scripts/check-iam-users-no-mfa
# Install dependencies
pip install -r requirements.txt
# Run your first MFA compliance scan
python check_iam_users_no_mfa_cli.py
The scanner provides an executive summary showing your account's MFA posture:
Below the summary, you'll see specific users requiring attention, prioritized by risk level:
For Security Teams: Generate a compliance report for management:
python check_iam_users_no_mfa_cli.py --export-csv quarterly_mfa_audit.csv
For Daily Monitoring: See only violations that need immediate action:
python check_iam_users_no_mfa_cli.py --show-violations-only
For Multi-Account Organizations: Scan specific AWS profiles:
python check_iam_users_no_mfa_cli.py --profile production-account
While the CLI scanner is perfect for on-demand audits, production environments need continuous monitoring. The Lambda version runs automatically and sends alerts when new MFA violations appear.
The Reality: MFA compliance degrades over time. New users get created without MFA, temporary accounts become permanent, and contractors leave without proper cleanup. Without continuous monitoring, gaps accumulate until the next manual audit.
The Solution: The Lambda version runs weekly (configurable), automatically scanning your entire AWS account and sending alerts only when critical violations are detected.
The Lambda scanner uses intelligent risk scoring to reduce alert fatigue:
This approach focuses on accounts most likely to be compromised while still maintaining complete audit trails.
The Lambda version deploys as a complete AWS infrastructure stack using SAM (Serverless Application Model):
# Navigate to the Lambda version
cd ../check-iam-users-no-mfa-lambda
# Configure your email for security alerts
# Edit template.yaml: change AlertEmail parameter to your security team's email
# Deploy the complete monitoring system
sam build && sam deploy --guided
What Gets Deployed:
When violations are detected, you'll receive email alerts containing:
The alerts focus on actionable information — you won't get notified about service accounts that don't need console access or users who already have MFA properly configured.
Scenario 1: First-Time Security Assessment
You've inherited an AWS account or are conducting your first security review. Start with the CLI scanner to establish baseline:
Scenario 2: Ongoing Compliance Monitoring
Your organization needs continuous compliance for SOC 2 or PCI DSS:
Scenario 3: Multi-Account Organizations
Managing MFA compliance across multiple AWS accounts:
When You See CRITICAL Violations:
When You See HIGH Violations:
Improving Your Compliance Rate:
SOC 2 Type II Compliance:
PCI DSS Requirements:
ISO 27001 Certification:
When auditors request MFA compliance evidence:
git clone https://github.com/TocConsulting/aws-helper-scripts.git
cd aws-helper-scripts/check-iam-users-no-mfa
pip install -r requirements.txt
python check_iam_users_no_mfa_cli.py --export-csv initial_assessment.csv
This immediate assessment will show you:
Based on your scan results:
aws iam delete-login-profile --user-name SERVICE-ACCOUNT-NAME
3. For inactive users: Consider disabling or removing accounts
cd ../check-iam-users-no-mfa-lambda
sam build && sam deploy --guided
Answer the deployment prompts:
mfa-compliance-scannerTrack these metrics to demonstrate security improvement:
In Episode 3, we'll tackle another critical blind spot: publicly accessible RDS databases. You'll learn how to build scanners that identify exposed databases, check encryption settings, and validate network configurations — before attackers find them first.
All tools from this series are production-ready and available at https://github.com/TocConsulting/aws-helper-scripts. Both CLI and Lambda versions include full documentation and deployment guides.
This article is just the start. Get the full picture with our free whitepaper - 8 chapters covering IAM, S3, VPC, monitoring, agentic AI security, compliance, and a prioritized action plan with 50+ CLI commands.
Stop sending your IAM policies, CloudTrail logs, and infrastructure code to third-party APIs. Run LLMs locally with Ollama on Apple Silicon — private, offline, fast. Complete setup guide with AWS security use cases.
We obtained the actual compromised litellm packages, set up a disposable EC2 instance with honeypot credentials and mitmproxy, and detonated the malware. Full evidence: fork bomb, credential theft in under 2 seconds, IMDS queries, AWS API calls, and C2 exfiltration.
A deep technical breakdown of how threat actor TeamPCP compromised Trivy, pivoted to LiteLLM, and turned a popular AI proxy into a credential-stealing weapon targeting AWS IMDS, Secrets Manager, and Kubernetes.