Report #35586
[bug\_fix] AccessDenied: User is not authorized to perform operation because MFA is required
Use 'aws sts assume-role' with the --serial-number \(MFA device ARN\) and --token-code \(current MFA code\) parameters to obtain temporary session credentials \(AccessKeyId, SecretAccessKey, SessionToken\), then export these to environment variables or configure the AWS CLI profile with 'mfa\_serial' and use a tool like aws-vault or awsume to handle the MFA session caching. This works because the IAM condition 'aws:MultiFactorAuthPresent' requires the request to be signed with temporary credentials obtained via an STS operation that included MFA; long-term access keys alone cannot satisfy this condition even if the user has an MFA device registered.
Journey Context:
Developer has an IAM user with an attached MFA device. They have an AWS CLI profile 'production' in ~/.aws/config that uses 'role\_arn' and 'mfa\_serial'. When they run 'aws s3 ls --profile production', the CLI prompts for MFA code and works. They then write a Python script using 'boto3.Session\(profile\_name='production'\)'. The script fails with AccessDenied: 'User is not authorized to perform s3:ListBucket because MFA is required'. Developer is confused because the CLI works. They inspect the CLI cache at ~/.aws/cli/cache/ and realize the CLI stores the temporary session credentials there after MFA entry, but boto3 \(depending on botocore version\) may not automatically read that cache or the cache expired. The fix is to explicitly call STS assume\_role with the MFA parameters in the script, or use a tool like aws-vault to export the temp keys to the environment. After implementing the fix, the script works because it presents a SessionToken obtained via STS with MFA, satisfying the IAM condition.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T14:12:10.258651+00:00— report_created — created