No IAM Support Role Configured: Why It Matters and How to Fix It

When an incident hits, the worst time to discover a permissions gap is in the middle of it. The No IAM Support Role Configured check looks for exactly that kind of latent gap: an AWS account with no IAM role wired up to interact with AWS Support. It sounds small, but it sits directly on the critical path for getting help when something is on fire.

---

What this check detects

Lensix flags this finding (account_supportrole) when it scans your account and finds that no IAM role has the AWS managed policy AWSSupportAccess attached.

The AWSSupportAccess policy grants permission to the AWS Support API, which backs the Support Center console. It allows actions like support:CreateCase, support:DescribeCases, and support:AddCommunicationToCase. AWS Trusted Advisor checks also rely on this access in several flows.

The check is intentionally narrow. It does not care how many roles you have or what else they do. It only asks one question: does at least one role grant access to AWS Support?

---

Why it matters

AWS Support is part of your incident response toolchain whether you treat it that way or not. Consider a few situations where the absence of a support role turns a minor problem into a stalled one:

• Service limit increases during an outage. You hit an EC2 vCPU quota or an SES sending limit while scaling up to absorb traffic. Raising it requires a support case. If nobody can open one without root, you wait.
• Suspected account compromise. You need AWS to help confirm or contain unusual activity. Filing that case quickly matters, and forcing it through root credentials during a security event is the opposite of what you want.
• Billing and abuse notices. AWS sometimes flags accounts for abuse or unexpected charges and expects a timely response through Support. A missing role adds friction to every one of those exchanges.

There is also a compliance dimension. Frameworks like CIS AWS Foundations Benchmark include a recommendation to maintain a support role so that authorized users can manage incidents with AWS. Auditors look for it, and the fix is cheap, so it tends to show up as low-effort, high-signal remediation work.

---

How to fix it

The remediation is to create an IAM role that trusted principals can assume, then attach the AWSSupportAccess managed policy to it. Below are three ways to do that.

Option 1: AWS CLI

First, create a trust policy that defines who can assume the role. This example allows IAM users in the same account to assume it; adjust the principal to fit your access model (for example, an SSO permission set or a federated role).

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

Save that as support-trust-policy.json, then create the role and attach the policy:

aws iam create-role \
  --role-name AWSSupportRole \
  --assume-role-policy-document file://support-trust-policy.json \
  --description "Role for managing AWS Support cases"

aws iam attach-role-policy \
  --role-name AWSSupportRole \
  --policy-arn arn:aws:iam::aws:policy/AWSSupportAccess

Verify the attachment:

aws iam list-attached-role-policies --role-name AWSSupportRole

You should see AWSSupportAccess in the output.

Option 2: AWS Console

1. Open the IAM console and go to Roles, then Create role.
2. For trusted entity type, choose AWS account and select This account (or another account if you centralize access).
3. On the permissions page, search for AWSSupportAccess and check the box next to it.
4. Name the role something clear like AWSSupportRole, review, and create.

Option 3: Terraform

If you manage IAM as code, the role belongs in your baseline account module so it ships with every new account:

data "aws_iam_policy_document" "support_assume" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]

    principals {
      type        = "AWS"
      identifiers = ["arn:aws:iam::111122223333:root"]
    }

    condition {
      test     = "Bool"
      variable = "aws:MultiFactorAuthPresent"
      values   = ["true"]
    }
  }
}

resource "aws_iam_role" "support" {
  name               = "AWSSupportRole"
  assume_role_policy = data.aws_iam_policy_document.support_assume.json
  description        = "Role for managing AWS Support cases"
}

resource "aws_iam_role_policy_attachment" "support" {
  role       = aws_iam_role.support.name
  policy_arn = "arn:aws:iam::aws:policy/AWSSupportAccess"
}

---

How to prevent it from happening again

A one-time fix solves today's account. The real win is making sure every account, including ones created next quarter, ships with a support role by default.

Bake it into account provisioning

If you use AWS Control Tower or an Account Factory pipeline, add the support role to the baseline that runs at account creation. With AWS Organizations, you can deploy it via a CloudFormation StackSet across every member account:

aws cloudformation create-stack-set \
  --stack-set-name baseline-support-role \
  --template-body file://support-role.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

With auto-deployment enabled, new accounts that join the organization inherit the support role automatically.

Gate it in CI/CD

If your IAM lives in Terraform, add a policy-as-code check so a pull request cannot merge an account module that lacks the support role. An Open Policy Agent rule against a Terraform plan can assert the attachment exists:

package terraform.support

deny[msg] {
  not support_policy_attached
  msg := "No role attaches arn:aws:iam::aws:policy/AWSSupportAccess"
}

support_policy_attached {
  some r
  rc := input.resource_changes[r]
  rc.type == "aws_iam_role_policy_attachment"
  rc.change.after.policy_arn == "arn:aws:iam::aws:policy/AWSSupportAccess"
}

Monitor continuously

Detective controls catch drift when someone deletes the role or detaches the policy. Lensix re-runs account_supportrole on every scan, so you get an alert if the role disappears. Pair that with an EventBridge rule on DetachRolePolicy if you want near-real-time notification.

---

Best practices

• Use a dedicated, clearly named role. AWSSupportRole or similar signals intent and keeps audits simple.
• Scope the trust policy tightly. Grant assume-role rights only to the identities that handle incidents, and require MFA on the trust relationship.
• Keep support access off root. The whole point is to stop reaching for root credentials during incidents. Make sure your on-call runbooks reference the role, not the root login.
• Confirm your support plan. The role grants API access, but the level of help you actually receive depends on your AWS Support plan. Basic support limits what you can do regardless of permissions.
• Review attachments periodically. Treat the support role like any other privileged role and include it in your regular IAM access reviews.

This is one of the cheapest fixes in your security backlog. A single role and a single policy attachment remove a real obstacle from your incident response path, and a StackSet keeps it solved for every account you will ever create.