IAM Identity Center Not Enabled: Centralize AWS Access the Right Way

If you run more than one AWS account, the way your people log in matters as much as what they can do once they are in. The account_identitycenter check looks at whether AWS IAM Identity Center is turned on in your organization. When it is off, the usual outcome is a sprawl of IAM users, static access keys, and per-account passwords that nobody fully tracks. That is the kind of setup attackers love and auditors hate.

This post walks through what the check detects, why it is worth fixing, and how to get IAM Identity Center running cleanly with copy-paste commands and an IaC example.

---

What this check detects

The check queries your AWS environment to see whether IAM Identity Center has an active instance. In practical terms, it confirms one of two things:

• No IAM Identity Center instance exists, so there is no centralized place to manage human access across accounts.
• An instance exists but is not configured as the access path for your accounts, leaving IAM users as the default login method.

A passing result means you have a central directory, permission sets, and account assignments in place. A failing result means access management is happening account by account, usually through IAM users.

---

Why it matters

IAM users with static access keys are the most common root cause behind real breaches. Keys end up in Git history, in CI logs, in Slack messages, and in laptop config files. Once an organization has more than a couple of accounts, managing those users independently in each account creates predictable problems.

Credential sprawl and key leakage

Every IAM user with an access key is a long-lived credential that does not rotate on its own. The more accounts you have, the more of these float around. A single leaked key can give an attacker a stable foothold that persists until someone notices and revokes it, which is often weeks later.

No single off switch when someone leaves

When an engineer leaves the company and you use per-account IAM users, offboarding means hunting through every account to disable or delete their access. Miss one and you have an orphaned credential with live permissions. With IAM Identity Center wired to your identity provider, disabling the person in the IdP cuts off every account at once.

Weak audit trail

IAM Identity Center issues short-lived, role-based credentials and centralizes sign-in events. That makes it far easier to answer questions like "who had admin in the production account last quarter" than digging through IAM user policies in each account separately.

MFA enforcement gaps

With scattered IAM users, MFA enforcement depends on per-account policy that is easy to forget. IAM Identity Center lets you enforce MFA in one place for everyone.

---

How to fix it

You enable IAM Identity Center once, at the organization level, then connect an identity source and assign access. Below is the practical sequence.

Step 1: Enable IAM Identity Center

This must be done from the management account of your AWS Organization. The console is the simplest path for the initial enablement:

1. Sign in to the management account.
2. Open the IAM Identity Center console.
3. Choose Enable. If your account is not yet part of an organization, AWS will offer to create one.
4. Pick the AWS Region that will host your Identity Center instance. Choose carefully, because moving it later means recreating assignments.

Step 2: Choose an identity source

You have three options:

• Identity Center directory — the built-in store, fine for small teams.
• External IdP via SAML 2.0 — Okta, Entra ID (Azure AD), Google Workspace, and others. This is the recommended path for most organizations.
• AWS Managed Microsoft AD — if you already run Active Directory.

For an external IdP, you exchange metadata between the IdP and Identity Center, then enable SCIM so users and groups sync automatically.

Step 3: Create permission sets

A permission set is a reusable definition of access that gets provisioned as an IAM role in each assigned account. Create them with the CLI:

# Find your Identity Center instance ARN
aws sso-admin list-instances

# Create a read-only permission set with an 8-hour session
aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx \
  --name "ReadOnly" \
  --description "Read-only access for engineers" \
  --session-duration "PT8H"

# Attach an AWS managed policy to it
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxx/ps-yyyyyyyy \
  --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

Step 4: Assign access to accounts

Now bind a group from your identity source to a permission set in a specific account:

# Get the group ID from the identity store
aws identitystore list-groups \
  --identity-store-id d-xxxxxxxxxx

# Assign the group to a permission set in a target account
aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxx \
  --target-id 111122223333 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxx/ps-yyyyyyyy \
  --principal-type GROUP \
  --principal-id 90671234-abcd-1234-efgh-1234567890ab

Step 5: Log in with the CLI

Engineers configure a profile once and authenticate through the browser:

aws configure sso
# Follow the prompts to select the start URL, account, and role

# Then use it like any profile
aws s3 ls --profile my-sso-profile

---

Define it as code

Clicking through the console once is fine, but permission sets and assignments should live in version control. Here is the same setup in Terraform:

data "aws_ssoadmin_instances" "main" {}

resource "aws_ssoadmin_permission_set" "read_only" {
  name             = "ReadOnly"
  description      = "Read-only access for engineers"
  instance_arn     = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  session_duration = "PT8H"
}

resource "aws_ssoadmin_managed_policy_attachment" "read_only" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
  permission_set_arn = aws_ssoadmin_permission_set.read_only.arn
}

resource "aws_ssoadmin_account_assignment" "read_only_dev" {
  instance_arn       = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  permission_set_arn = aws_ssoadmin_permission_set.read_only.arn

  principal_id   = "90671234-abcd-1234-efgh-1234567890ab" # group ID
  principal_type = "GROUP"

  target_id   = "111122223333" # account ID
  target_type = "AWS_ACCOUNT"
}

---

How to prevent it from happening again

Enabling Identity Center once does not stop teams from creating new IAM users for "quick" automation or one-off access. Put guardrails in place.

Block IAM user creation with an SCP

A Service Control Policy applied at the organization or OU level can deny IAM user and access key creation, pushing everyone toward Identity Center and IAM roles.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIamUserCreation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateAccessKey"
      ],
      "Resource": "*"
    }
  ]
}

Gate IaC in CI/CD

Add a policy-as-code check to your pipeline so pull requests that introduce aws_iam_user or aws_iam_access_key resources fail before merge. With Open Policy Agent and Conftest, a rule can reject those resource types and point reviewers to Identity Center instead.

# Run against a Terraform plan converted to JSON
conftest test plan.json --policy ./policy

Continuously monitor

Run the account_identitycenter check on a schedule so a disabled or misconfigured Identity Center instance surfaces quickly. Lensix evaluates this automatically across your accounts and flags drift, so you find out from a dashboard rather than from an auditor.

---

Best practices

• Use groups, not individuals, for assignments. Assign permission sets to IdP groups so access changes happen through group membership, not one-off edits.
• Keep session durations short. One to four hours for sensitive permission sets limits the blast radius of a stolen session.
• Enforce MFA at the identity source. Whether you use the built-in directory or an external IdP, require MFA for every sign-in.
• Scope permission sets tightly. Prefer narrow, purpose-built permission sets over broad AdministratorAccess grants. Reserve admin for a small, audited group.
• Keep one break-glass IAM user. Maintain a single, heavily protected emergency access path in case Identity Center or your IdP is unavailable. Store its credentials offline and alert on any use.
• Review assignments quarterly. Schedule an access review to remove stale permission set assignments before they become a finding.

Centralized access management is one of those changes that pays for itself the first time someone leaves the company or an audit lands on your desk. Turn on IAM Identity Center, wire it to your identity provider, and let permission sets do the work that scattered IAM users were never good at.