Root account is using a virtual MFA device instead of a hardware token
- Severity
- Medium
- Service
- IAM
- Check ID
- ROOT_MFA_NOT_HARDWARE
What this check finds
Virtual MFA devices (software authenticators) are more susceptible to phishing and device compromise than hardware security keys (YubiKey, Google Titan). For the root account — the most privileged identity in AWS — a hardware MFA token is strongly recommended.
Passing looks like: Root account uses hardware MFA.
How to fix it
Replace the virtual MFA device on the root account with a hardware security key. Sign in as root → IAM → Security credentials → Multi-factor authentication (MFA) → Manage → Deactivate the virtual device → Assign a hardware MFA device.
Compliance controls it is evidence for
A failing result counts against these controls in KloudLytics; a passing one is evidence towards them. How compliance mapping works
| Framework | Controls |
|---|---|
| CIS AWS Foundations Benchmark v5.0.0 |
|
| PCI-DSS v4.0.1 |
|
| HIPAA Security Rule |
|
| SOC 2 — Trust Services Criteria |
|
| NIST SP 800-53 Rev5 (Moderate) |
|
| NIST Cybersecurity Framework 2.0 |
|
| ISO/IEC 27001:2022 Annex A |
|
Checked on every scan
KloudLytics runs this check each time it scans a connected AWS account, through a read-only role, and lists every affected resource with its region. On Pro and Business a fix is written for the specific resource rather than the general case above. The exact access it needs
More IAM checks
- HighDeprecated or flawed AWS managed policy in use
- HighIAM role allows assumption from anywhere
- HighIAM role with admin privileges can be assumed by unexpected principals
- HighIAM role with s3 listing and get privileges can be assumed by unexpected principals
- HighIAM user access key has not been rotated in over 180 days
- HighIncorrect policy used to attempt to enforce MFA
- HighInline policy allows privilege escalation to admin
- HighPrincipal has an attached policy granting administrative access