AWS Builder Center

Builder Center

How to Restrict IAM User Console Access Using Service Control Policies in AWS Organizations Member Accounts

Account administrators in AWS Organizations member accounts can create IAM users with console passwords, creating an uncontrolled access path that bypasses centralized SSO and MFA standards. This article explains how to use a Service Control Policy (SCP) to prevent IAM users from being granted AWS Management Console access, while preserving their ability to function as service principals with programmatic access.

bnh

The Problem

In an AWS Organization, any administrator in a member account can:
  1. Create an IAM user
  2. Assign a username and password (a "login profile")
  3. Grant that user any permissions available in the account
  4. That user can then sign in directly at console.aws.amazon.com
This creates a "side door" into your AWS accounts that:
  • Bypasses your centralized SSO/identity provider
  • May not enforce multi-factor authentication (MFA)
  • Creates credentials outside your identity governance process
  • Reduces visibility for your security team

The Solution: An SCP to Deny Console Password Creation

Service Control Policies (SCPs) set the maximum available permissions for all accounts in your organization. By applying an SCP that denies console-password-related actions, you prevent anyone in member accounts from enabling console access for IAM users.

The Policy

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyIAMUserConsoleAccess",
"Effect": "Deny",
"Action": [
"iam:CreateLoginProfile",
"iam:UpdateLoginProfile",
"iam:ChangePassword"
],
"Resource": "*",
"Condition": {
"StringNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam::*:role/BreakGlassRole"
]
}
}
}
]
}

What Each Action Does

ActionPurposeWho Calls It
iam:CreateLoginProfileCreates a console password for an IAM userAccount administrators
iam:UpdateLoginProfileResets or changes an IAM user's console passwordAccount administrators
iam:ChangePasswordAllows an IAM user to change their own passwordThe IAM user themselves
These are the only three IAM API actions that create or modify console login passwords. There is no other API path to grant an IAM user console access.

What This Policy Does NOT Block

  • Programmatic access — IAM users can still be created with access keys for service-to-service communication
  • SSO/federated access — AWS IAM Identity Center and external identity provider logins are completely unaffected
  • IAM roles — AssumeRole workflows remain functional
  • Root user — The account root user is not affected by SCPs (see Additional Considerations below)

The Condition Block

The StringNotLike condition exempts a specific break-glass role. This ensures you retain an emergency access path if your SSO provider experiences an outage. Adjust the ARN to match your organization's emergency access role. If you don't have one, you can remove the Condition entirely — the management account is never affected by SCPs regardless.

Pros and Cons

Pros

  • Closes the side door — Prevents bypassing your SSO and MFA standards
  • Centralized enforcement — Applies automatically across all current and future member accounts in the targeted OU
  • No impact to service accounts — Programmatic IAM users (access keys only) continue to work
  • No impact to federated access — SSO and Identity Center workflows are unaffected
  • Audit-friendly — Demonstrates to compliance teams that console access is governed at the organizational level
  • Low maintenance — Set once, always enforced

Cons

  • Not retroactive — The SCP only prevents creation/modification of passwords. Existing IAM users who already have console passwords can still sign in until their login profiles are explicitly deleted.
  • Break-glass planning required — If SSO goes down, you need a pre-planned exemption path. Without it, you could lose console access to member accounts during an identity provider outage.
  • Root user not affected — The account root user (email + password) is not governed by SCPs. This requires separate controls (see below).
  • Migration coordination — If teams currently rely on IAM user console logins, deploying this SCP before migrating them to SSO will break their access.

Implementation Steps

Phase 1: Discovery

Identify existing IAM users with active console passwords across your organization.
For each member account, run:
1
2
3
4
5
# List all IAM users
aws iam list-users --query 'Users[*].UserName' --output text

# For each user, check if they have a login profile (console password)
aws iam get-login-profile --user-name <USERNAME>
If get-login-profile returns successfully, that user has console access. If it returns NoSuchEntity, the user is programmatic-only.
For organizations with many accounts, consider using AWS Config or a script that assumes a role in each member account to automate this audit.

Phase 2: Migration

For each IAM user with console access:
  1. Determine if the user is a person or a service account
    • People should be migrated to AWS IAM Identity Center or your external IdP
    • Service accounts should not have console passwords — convert to access-key-only or (preferably) IAM roles
  2. Set up federated access for any users who need console access via your SSO provider
  3. Notify affected users with a migration deadline

Phase 3: Cleanup

Once users are migrated:
1
2
# Delete the console password for each identified IAM user
aws iam delete-login-profile --user-name <USERNAME>
Re-run the Phase 1 audit to confirm zero login profiles remain.

Phase 4: Deploy the SCP

  1. Test first — Attach the SCP to a sandbox or test OU and verify:
    • Console password creation is blocked
    • Service accounts (access keys) still work
    • SSO access is unaffected
  2. Roll out — Attach the SCP to your root OU or all child-account OUs
  3. Validate — Attempt to create a login profile in a member account to confirm the deny is active

Additional Considerations

Root User Access

SCPs do not apply to the root user of member accounts. To address this:
  • Recommended: Enable centralized root access management  in AWS Organizations. This allows you to delete root credentials from member accounts entirely and manage privileged root actions centrally from the management account.
  • Minimum: Ensure all member account root users have MFA enabled, and monitor root user sign-in events via CloudTrail.

Management Account

The management account is never affected by SCPs. Protect it with:
  • Strong MFA on the root user
  • Minimal IAM users (ideally zero — use federated access)
  • CloudTrail monitoring for all IAM actions

Monitoring

After deploying the SCP, set up a CloudTrail alert for denied iam:CreateLoginProfile calls. This tells you when someone attempts to create a console password and is blocked — useful for detecting policy awareness gaps or potential malicious activity.
1
2
3
4
5
6
7
8
{
"source": "aws.iam",
"detail-type": "AWS API Call via CloudTrail",
"detail": {
"eventName": "CreateLoginProfile",
"errorCode": "AccessDenied"
}
}

Summary

Restricting IAM user console access via an SCP is a high-impact, low-effort security control that enforces your organization's identity governance standards across all member accounts. Combined with federated access through AWS IAM Identity Center and centralized root access management, it ensures that the AWS Management Console can only be accessed through your approved authentication pathways.
Related resources:
# aws-organizations# iam# service-control-policies# security# identity
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article