# Ensure Users Make Use of Temporary Credentials Assuming IAM Roles

- Source: https://support.icompaas.com/support/solutions/articles/62000233834-ensure-users-make-use-of-temporary-credentials-assuming-iam-roles
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS Checks New Version](https://support.icompaas.com/support/solutions/62000112673) › [AWS New Checks](https://support.icompaas.com/support/solutions/folders/62000169206)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Profile Applicability:**  

-   **Level 2**

**Description:**  
AWS Identity and Access Management (IAM) allows users and applications to assume roles and obtain temporary security credentials instead of using long-term access keys. Temporary credentials reduce the risk of credentials being compromised, as they are short-lived and automatically expire after a defined period. Enforcing the use of IAM roles for authentication enhances security by following the principle of least privilege and minimizing exposure to long-term credentials.

**Rationale:**  
Using temporary credentials instead of static IAM user credentials minimizes the risk of credential leakage and unauthorized access. Temporary credentials are automatically rotated and expire after a predefined duration, reducing the attack surface for compromised credentials. IAM roles also allow for fine-grained access control, ensuring users and applications only have the necessary permissions required for their tasks.

**Impact:  
Pros:**

-   Reduces the risk of long-term credential exposure.
    
-   Enhances security through automatic expiration and rotation.
    
-   Supports best practices for least privilege access.
    
-   Simplifies credential management and auditing.
    

**Cons:**

-   Requires additional configuration and management of IAM roles.
    
-   Users may require training on how to assume roles correctly.
    

**Default Value:**  
By default, IAM users can create and manage access keys unless restricted by policy. AWS recommends using IAM roles for access instead of long-term access keys.

**Pre-requisites:**

-   AWS IAM permissions:
    
    -   iam:PassRole
        
    -   sts:AssumeRole
        
    -   iam:CreatePolicy (if defining policies for role-based access control)
        
-   AWS CLI installed and configured.
    
-   Appropriate IAM roles set up with policies that grant least privilege access.
    

**Remediation:**

**Test Plan:  
Using AWS Console:**

1.  Sign in to the AWS Management Console.
    
2.  Navigate to IAM > Roles.
    
3.  Identify roles that are actively being assumed by users and services.
    
4.  Review IAM user policies to ensure they are not using long-term access keys.
    
5.  Ensure users authenticate using IAM roles via AWS STS (Security Token Service).
    

**Using AWS CLI:**

1.  List IAM users with active access keys:  
    
    aws iam list-users --query "Users\[\*\].UserName"
    
2.  Check for access keys associated with each IAM user:  
    
    aws iam list-access-keys --user-name <USER\_NAME>
    
3.  Validate that users are assuming roles instead of using access keys by checking CloudTrail logs:  
    
    aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole
    

**Implementation Plan:  
Using AWS Console:**

**1\. Create IAM Roles**

-   Go to **IAM → Roles → Create role**.  
    ![](https://support.icompaas.com/assets/kb/80c37bf8679bbc45.png)
    
-   Choose **Trusted entity type**:
    
    -   **AWS service** (e.g., EC2, Lambda) if services need the role.
        
    -   **Another AWS account** or **IAM Identity Center** if users need to assume the role.  
        ![](https://support.icompaas.com/assets/kb/5f904e17108a4356.png)
        
-   Attach the required **permissions policy** (least privilege).  
    ![](https://support.icompaas.com/assets/kb/861bdddadb1987ac.png)
    
-   Finish creating the role.
    

**2\. Set Trust Relationship**

-   In the role, go to **Trust relationships → Edit trust policy**.  
    ![](https://support.icompaas.com/assets/kb/7a15bc09f1312622.png)
    
-   Define which users, groups, accounts, or services are allowed to **assume the role**.  
    ![](https://support.icompaas.com/assets/kb/01b8e4262b943052.png)
    

  

**Using AWS CLI:**

1.  Create an IAM role:  
    
    aws iam create-role --role-name <ROLE\_NAME> --assume-role-policy-document file://trust-policy.json
    
2.  Attach policies to the role:  
    
    aws iam attach-role-policy --role-name <ROLE\_NAME> --policy-arn arn:aws:iam::aws:policy/<POLICY\_NAME>
    
3.  Allow users to assume the role by updating their permissions.
    
4.  Restrict IAM users from using access keys:  
    
    aws iam update-user --user-name <USER\_NAME> --no-permanent-credentials
    
5.  Verify that users assume roles correctly using AWS STS:  
    
    aws sts assume-role --role-arn arn:aws:iam::<ACCOUNT\_ID>:role/<ROLE\_NAME> --role-session-name <SESSION\_NAME>
    

**Backout Plan:  
Using AWS Console:**

1.  Sign in to the AWS Management Console and navigate to IAM.
    
2.  Identify the affected user or role and review permission changes.
    
3.  Re-enable access keys for affected users if necessary.
    
4.  Update IAM policies to allow temporary exceptions if needed.
    
5.  Document any changes made and notify relevant stakeholders.
    

**Using AWS CLI:**

1.  List IAM users to identify affected users:  
    
    aws iam list-users --query "Users\[\*\].UserName"
    
2.  Re-enable access keys for a specific user if required:  
    
    aws iam create-access-key --user-name <USER\_NAME>
    
3.  Restore previous IAM policies by attaching necessary policies:  
    
    aws iam attach-user-policy --user-name <USER\_NAME> --policy-arn arn:aws:iam::aws:policy/<POLICY\_NAME>
    
4.  Monitor CloudTrail logs to assess the impact of the rollback and take corrective action as needed.
    

**Reference:**

-   AWS IAM: AssumeRole API
    
-   AWS STS: Temporary Security Credentials
    
-   AWS Best Practices: IAM Role-Based Access Control

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.