IAM Roles, STS and MFA

What it is

An IAM role is an identity with permissions but no password or long term keys. A trusted principal assumes the role, and the AWS Security Token Service (STS) returns temporary credentials that expire.

Roles are the core mechanism for service access, cross account access and federation. The exam tests who can assume a role, how long the session lasts, and how to add protection such as MFA (multi factor authentication).

How it works

Two policies on every role

A role has a trust policy that says who may assume it, and permission policies that say what the session can do. Both must be right. A frequent mistake is to fix permissions when the problem is the trust policy.

A cross account trust policy names the other account, and adds conditions for safety, such as an external ID for a third party.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "a1b2c3-unique-value" }
    }
  }]
}

Naming the account root as principal delegates the decision to that account, where its administrators must still allow their principals to call sts:AssumeRole on this role. Name a specific role ARN as principal for tighter control.

Cross account access and the external ID

When a third party assumes a role in your account, the external ID prevents the confused deputy problem. The third party assigns you a unique value and must supply it when assuming the role, so another of its customers cannot trick it into using your role. For AWS services, use aws:SourceArn and aws:SourceAccount conditions for the same purpose.

STS operations

# AWS CLI: assume a role and show the caller identity
aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/AuditRole \
  --role-session-name audit-2026-10 \
  --external-id a1b2c3-unique-value

aws sts get-caller-identity

Session controls

• Duration. A role has a maximum session duration that you set. Role chaining, where one role assumes another, is limited to a one hour session.
• Session policy. A policy passed when assuming the role can only reduce permissions for that session, never add any.
• Session tags and source identity. Tags pass attributes for ABAC, and sts:SourceIdentity records the original user across role chains, so CloudTrail shows who really acted.
• Revocation. You cannot cancel a single session, but you can revoke all sessions issued before a time, as the incident response chapter showed.

MFA

MFA adds a second factor. AWS supports passkeys and FIDO security keys, virtual authenticator apps and hardware TOTP tokens. FIDO based factors resist phishing best.

To require MFA for sensitive actions, use the aws:MultiFactorAuthPresent condition key, and aws:MultiFactorAuthAge to require a recent MFA check.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": ["ec2:TerminateInstances", "ec2:StopInstances"],
    "Resource": "*",
    "Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } }
  }]
}

The BoolIfExists operator also denies requests where the key is absent, such as long term access key calls that never used MFA. A plain Bool against false would miss them.

For API or CLI users, the principal calls GetSessionToken or AssumeRole with the MFA device serial number and a token code, and uses the returned session credentials.

IAM Roles Anywhere

IAM Roles Anywhere lets workloads outside AWS, such as servers in a data centre, obtain temporary credentials by presenting an X.509 certificate from a trusted certificate authority (CA). It removes the need for long term access keys on those servers. You create a trust anchor, a profile and a role that trusts the Roles Anywhere service.

Service roles and instance profiles

AWS services assume roles to act for you. EC2 uses an instance profile to pass a role to an instance. Passing a role to a service needs the iam:PassRole permission, and it is a key control to limit, because it can allow privilege escalation.

Best practices

• Prefer roles and short sessions to IAM user access keys.
• Scope trust policies to specific principals and add conditions.
• Use external IDs for third parties and source conditions for AWS services.
• Require MFA for human access to sensitive roles.
• Limit iam:PassRole to specific role ARNs and services.