# Ensure that no custom IAM policies exist which allow permissive role assumption

- Source: https://support.icompaas.com/support/solutions/articles/62000227147-ensure-that-no-custom-iam-policies-exist-which-allow-permissive-role-assumption
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Security Controls](https://support.icompaas.com/support/solutions/62000065178) › [IAM Policies](https://support.icompaas.com/support/solutions/folders/62000096130)
- Last updated: 2026-10-14
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:  
AssumeRole (AWS STS) returns temporary security credentials (access key ID, secret access key, and security token) used to access AWS resources. This check reviews customer-managed IAM policies and fails any policy with an Allow statement where Action contains sts:AssumeRole or sts:\* and Resource contains \*.

  

Rationale:  
A principal that assumes an IAM role inherits the role’s permissions. Allowing sts:AssumeRole on "Resource": "\*" lets any user, role, or service with the policy attached attempt to assume any role, including cross-account roles, which may expose confidential resources.

  

Impact:  
Restricting role assumption to only the required roles reduces the risk of unauthorized access. If a required role is missed, the affected principals will lose access to it.

Pre-Requisite:

-   Clear definition of “WHO needs to assume WHICH roles” (identify role ARNs from CloudTrail AssumeRole events, roleArn field).
    
-   A backup copy of the current policy document as a JSON file.
    

  

Remediation

Test Plan

1.  Sign in to the AWS Management Console.
    
2.  Navigate to the IAM dashboard at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
    
3.  In the left navigation pane, choose Policies.
    
4.  Filter by Type = Customer managed.
    
5.  Open the policy reported by the finding.
    
6.  On the Permissions tab, select JSON.
    
7.  The policy is non-compliant if any statement has Effect: Allow, Action including sts:AssumeRole or sts:\*, and Resource set to \* or a wildcard such as arn:aws:iam::\*:role/\*.if so, follow the Implementation steps.
    

  

Example non-compliant statement:

json

{ "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "\*" }

  

Implementation steps:

1.  Sign in to the AWS Management Console.
    
2.  Navigate to the IAM dashboard at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
    
3.  In the left navigation pane, choose Policies.
    

4.  Open the non-compliant policy.
    
5.  On the Permissions tab, select JSON, copy the policy document, and save it as a backup.
    

6.  On the Policy versions tab, if 5 versions exist, delete the oldest non-default version.
    
7.  Choose Edit, then select JSON.
    

8.  Replace "Resource": "\*" with only the required role ARNs. If the action is sts:\*, change it to sts:AssumeRole.
    
9.  If the statement contains other actions that need "Resource": "\*", move sts:AssumeRole into a separate statement:
    

  

Before (non-compliant):

json

{  
  "Version": "2012-10-17",  "Statement": \[    {      "Effect": "Allow",      "Action": "sts:AssumeRole",      "Resource": "\*"    }  \]}

After (compliant):

json

{  
  "Version": "2012-10-17",  "Statement": \[    {      "Effect": "Allow",      "Action": "sts:AssumeRole",      "Resource": "arn:aws:iam::<ACCOUNT\_ID>:role/<RoleName>"    }  \]}

  

10.  Choose Next, then Save changes.
     
11.  Re-run the Test Plan to confirm compliance.
     

  

Backout Plan:

1.  Sign in to the AWS Management Console.
    
2.  Navigate to the IAM dashboard at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
    
3.  In the left navigation pane, choose Policies.
    
4.  Open the affected policy.
    
5.  On the Policy versions tab, select the previous version and choose Set as default.
    
6.  If the previous version is unavailable, choose Edit, select JSON, paste the backup policy, choose Next, then Save changes.
    

  

Reference:

-   [https://docs.aws.amazon.com/IAM/latest/UserGuide/id\_roles\_use\_permissions-to-switch.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html)
    
-   [https://docs.aws.amazon.com/IAM/latest/UserGuide/access\_policies\_managed-versioning.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-versioning.html)
    
-   [https://docs.aws.amazon.com/STS/latest/APIReference/API\_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)

## 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.