Configuring Multi-Factor Authentication for AWS S3 Read-Only Roles

Configuring Multi-Factor Authentication (MFA) for AWS S3 read-only roles is the difference between an exposed archive and controlled access. AWS Identity and Access Management (IAM) lets you combine role-based permissions with session policies requiring MFA. This ensures access is possible only after a verified user passes a second authentication check.

Start by creating a read-only IAM role. Attach the AmazonS3ReadOnlyAccess policy. To enforce MFA, define a condition in the role’s trust policy using aws:MultiFactorAuthPresent. This rejects role assumption unless the MFA flag is present in the session credentials. Use short session durations to reduce risk. A typical setup uses one-hour sessions, forcing frequent re-authentication.

Example trust policy snippet:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME"},
 "Action": "sts:AssumeRole",
 "Condition": {
 "Bool": {
 "aws:MultiFactorAuthPresent": "true"
 }
 }
 }
 ]
}

Once the policy is active, users must call aws sts assume-role with MFA parameters. That command includes the ARN for the read-only role, the ARN for the MFA device, and the OTP code. Without these, AWS denies access. This blocks automated scripts and unsecured profiles from pulling S3 objects.

Combining MFA with read-only permissions limits blast radius. Even if credentials leak, attackers cannot write, delete, or escalate privileges. Logs in AWS CloudTrail will show each role assumption alongside MFA status, giving a clear audit trail.

Security teams use this pattern on shared S3 buckets containing logs, backups, or compliance data. It’s simple, predictable, and difficult to bypass without full credential control and the MFA token.

Protect your S3 buckets with MFA-enforced read-only roles in minutes. Try it now with hoop.dev and see the setup live.