IAM User Cannot Change Their Own Password? The Account Checkbox, IAMUserChangePassword, the ${aws:username} Path Trap, Expired Passwords and PasswordPolicyViolation, Fixed

If an IAM user cannot change their own AWS password, it is almost always one of three things: nothing allows iam:ChangePassword for that user, the user cannot read the password rules (iam:GetAccountPasswordPolicy), or the new password breaks the account's password policy. The fastest fix for the whole account is one checkbox: IAM > Account settings > Password policy > Edit > "Allow users to change their own password". For selected users, attach the AWS managed policy IAMUserChangePassword. Here is the trap that keeps this error alive in otherwise well-run accounts: the hand-written policy most people copy does not work for users created with a path. It allows iam:ChangePassword on arn:aws:iam::*:user/${aws:username}, but a user created under a path such as /engineering/ has the ARN user/engineering/jake, which that pattern never matches. The managed policy was updated on February 12, 2026 to cover both forms; copies of the older one-line version are still everywhere. A second trap: if the account uses "Password expiration requires administrator reset," a user whose password has expired cannot change it in the console at all, whatever their permissions.

Jake's computer shop has an AWS account with three IAM users: Ethan, Jake, and a part-time bookkeeper who signs in once a month to download invoices. In September Ethan turned on a 90-day password expiry, as his security checklist suggested. On Monday the bookkeeper signed in, was told her password had expired, typed a new one, and got an error saying she was not allowed to change it. Ethan's first thought was a typo in her new password. It was not. The policy he had pasted from a forum two years ago only matched users without a path, and he had created the bookkeeper under /finance/.

New to IAM? Our plain-English IAM guide explains users, groups and policies in about ten minutes. The fixes below need an administrator for the account; if you are the user who is stuck, send this page to whoever manages your AWS account.

How changing your own password is supposed to work

An IAM user (someone who signs in with an account ID or alias, a user name and a password) changes their own password like this:

1. Sign in to the AWS console with the account ID or alias, the IAM user name and the current password.
2. Choose your user name in the top-right corner of the console, then Security credentials.
3. On the AWS IAM credentials tab, choose Update password.
4. Enter the current password, then the new password twice, and choose Update password.

Behind that button are two permissions, and both must be allowed:

• iam:ChangePassword, on the user's own user ARN. This is the action that actually changes the password.
• iam:GetAccountPasswordPolicy, on *. The Change password page reads the account's password rules to check the new password against them; without this permission the page cannot load those rules and the change fails.

There are two ways to grant both, and choosing between them is the first decision. Before you change anything, match what you see to this table; it tells you which section to read:

"So it isn't my password the computer dislikes," the bookkeeper said, when Jake explained it. "It's whether you're allowed to have a new one," Ethan said.

Fix 1: let every IAM user change their own password (one checkbox)

For most small accounts this is the right fix. An account-level setting gives every IAM user permission to change their own password and read the password policy, without attaching anything to anyone.

1. Sign in as an administrator and open the IAM console.
2. In the navigation pane, choose Account settings.
3. In the Password policy section, choose Edit.
4. Choose Custom, select Allow users to change their own password, and choose Save changes.

The same from the CLI. Be careful here: update-account-password-policy replaces the whole policy, so pass every setting you want to keep, not just the new one. Read the current policy first:

aws iam get-account-password-policy

aws iam update-account-password-policy \
  --minimum-password-length 14 \
  --require-uppercase-characters --require-lowercase-characters \
  --require-numbers --require-symbols \
  --max-password-age 90 --password-reuse-prevention 5 \
  --allow-users-to-change-password

If get-account-password-policy returns NoSuchEntity, the account has no custom policy and uses AWS's default rules; creating a custom one with the setting above is fine. The setting applies straight away. In Jake's account, this checkbox would have fixed the bookkeeper in thirty seconds, path or no path, because the account-level permission is not tied to a resource pattern.

Fix 2: allow only selected users (the managed policy)

Larger accounts often leave the checkbox off and grant password changes only to some users or groups. Use the AWS managed policy IAMUserChangePassword for this. Attach it to a group and put the users in the group:

aws iam attach-group-policy --group-name console-users --policy-arn arn:aws:iam::aws:policy/IAMUserChangePassword
aws iam add-user-to-group --group-name console-users --user-name bookkeeper

This is what the managed policy contains today (version 5, edited February 12, 2026):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": [
        "arn:aws:iam::*:user/${aws:username}",
        "arn:aws:iam::*:user/*/${aws:username}"
      ]
    },
    {
      "Effect": "Allow",
      "Action": ["iam:GetAccountPasswordPolicy"],
      "Resource": "*"
    }
  ]
}

Two lines in it do the real work. ${aws:username} is a policy variable that IAM replaces with the name of the user making the request, so each user can change only their own password, never someone else's. And the second resource line, user/*/${aws:username}, is the one most hand-written copies are missing.

The path trap: why the copied policy fails for some users

IAM users can be created with a path, an optional folder-like prefix such as /finance/ or /engineering/contractors/. Tools and companies use paths to organize users. The path becomes part of the user's ARN:

user without a path:   arn:aws:iam::111122223333:user/jake
user with a path:      arn:aws:iam::111122223333:user/finance/bookkeeper

Now look at the single-resource policy that circulates in tutorials, answers and old templates:

"Resource": "arn:aws:iam::*:user/${aws:username}"

For the bookkeeper, ${aws:username} becomes bookkeeper, so the pattern is user/bookkeeper. Her real ARN is user/finance/bookkeeper. They do not match, the Allow does not apply, and the password change is denied, even though the policy is attached and looks correct. Users without a path, created the same day with the same policy, change their passwords without trouble, which is what makes it so hard to spot.

To check whether a user has a path:

aws iam get-user --user-name bookkeeper --query "User.[Path,Arn]"

A path of / means no path. Anything longer means the user needs the second resource line. Fix the policy by adding it (or switch to the managed IAMUserChangePassword, which already has both):

"Resource": [
  "arn:aws:iam::*:user/${aws:username}",
  "arn:aws:iam::*:user/*/${aws:username}"
]

One more condition for the variable to work at all: the policy must start with "Version": "2012-10-17". Policy variables were added in that version of the policy language. In a policy with an older version, or with no Version line, ${aws:username} is treated as the literal text "${aws:username}", which matches no user. Old policies copied from very early examples sometimes have exactly this problem.

"So the policy was right for Ethan and wrong for me," the bookkeeper said. "Right for anyone without a folder in their name," said Ethan. "I put you in a folder."

When the password has expired

Password expiry adds a separate set of rules, and one setting changes everything:

• Expiry on, "administrator reset" off (the default when you turn on expiry): when a user signs in with an expired password, the console asks them to set a new one. They still need permission to change it: either the account-level checkbox or the policy above. This is what happened to the bookkeeper.
• "Password expiration requires administrator reset" on (HardExpiry): after the password expires, the user cannot change it in the console, whatever their permissions. An administrator with iam:UpdateLoginProfile has to set a new one. A user who has iam:ChangePassword and working access keys can still change it from the CLI, but most console-only users have neither.

For an administrator, resetting a user's password and asking them to choose their own at the next sign-in:

aws iam update-login-profile --user-name bookkeeper --password "Temp-Pass-2026!" --password-reset-required

In the console, the same is under IAM > Users > the user > Security credentials > Console sign-in > Manage console access, with "User must create a new password at next sign-in" selected. That reset flow still needs the user to be allowed to change their password at the next sign-in, so the permission problem above has to be solved too, or the user is stuck on the "set a new password" screen.

A few facts about expiry that explain surprising behavior:

• Setting an expiry period applies immediately: turn on 90 days, and every user whose password is already older than 90 days must change it at their next sign-in. That is why expiry problems tend to arrive in a wave the week after someone changes the setting.
• Users whose passwords are 75 to 89 days old (with a 90-day policy) see a warning in the console before it expires.
• An expired password blocks console sign-in only. The same user's access keys keep working.
• Before turning on "administrator reset," make sure the account has more than one administrator, or one expired admin password can lock everyone out of the console.

"Your password does not meet the requirements": the password policy

If the permission is fine and the change still fails, the new password is breaking the account's password policy. In the CLI and SDKs this shows up as PasswordPolicyViolation: the provided password did not meet the requirements imposed by the account password policy. Check the rules with aws iam get-account-password-policy (or on the Change password page, which lists them), then compare. The common reasons:

Reuse prevention catches people who rotate between two familiar passwords: with "prevent reuse of the last 5," the previous five are all refused. Password managers that generate a long random password avoid every row of this table at once. Note that tightening the length or character rules does not force anyone to change an existing password; the new rules apply the next time each user changes it.

When a "require MFA" policy blocks the change

Many accounts attach a policy that denies almost everything until the user signs in with MFA. If it is written well, it leaves room for a user to manage their own password and set up MFA without MFA; if it is written too strictly, a new user can never set a password, because changing it is blocked until MFA is active, and adding MFA is blocked until they can sign in properly.

Look for a Deny statement with a condition on aws:MultiFactorAuthPresent. Its NotAction list (the actions it does not block) should include at least iam:ChangePassword, iam:GetAccountPasswordPolicy, iam:GetUser and the MFA setup actions. If iam:ChangePassword is missing from it, that Deny wins over every Allow, and the user cannot change their password until they have MFA. Add it to the NotAction list, or have an administrator reset the password and set up MFA with the user.

SCPs, permissions boundaries and explicit denies

If the user has the right Allow and still cannot change their password, something is denying it. In order of how often they cause this:

• A permissions boundary on the user that does not include iam:ChangePassword. A boundary sets the maximum a user can do, so the action must be inside it as well as allowed by a policy.
• A service control policy (SCP) from AWS Organizations that denies IAM changes in this account. Only the organization's administrators can change it; our Organizations guide explains how SCPs sit above every account policy.
• An explicit Deny in a policy attached to the user or a group, often a broad "deny IAM" statement meant for something else.

The CLI error spells out which kind of policy refused, for example "... is not authorized to perform: iam:ChangePassword ... with an explicit deny in a service control policy." Our explicit deny guide walks through finding the statement responsible.

Changing the password from the CLI

A user with iam:ChangePassword and working access keys can change their own console password without the console, which is also the way out of a hard-expired password if an administrator is not around:

aws iam change-password --old-password "current-password" --new-password "a-long-new-password-2026!"

The CLI shows the precise reason when it fails, which the console sometimes hides:

• AccessDenied ... is not authorized to perform: iam:ChangePassword: the permission or path problem above.
• PasswordPolicyViolation: the new password breaks a rule.
• InvalidUserType: the request came from a principal that is not an IAM user, such as the root user or a role.
• EntityTemporarilyUnmodifiable: the user was just deleted and recreated with the same name; wait a few minutes and retry.

To keep passwords out of your shell history on Kali or macOS, put a space before the command (if your shell is set to ignore space-prefixed commands) or clear the history afterwards. In PowerShell, history is saved to a file by PSReadLine; consider changing the password in the console instead.

If you are not an IAM user at all

Not every AWS sign-in is an IAM user, and the IAM password settings do not apply to the others:

• The root user (the email address that created the account) changes its password from the account menu > Security credentials, or with "Forgot password" on the root sign-in page. The IAM password policy does not apply to root.
• IAM Identity Center (SSO) users sign in through the AWS access portal. Their password is managed by Identity Center or by your company's identity provider (Microsoft Entra ID, Okta, Google), not by IAM. Our Identity Center guide explains where those passwords live.
• Federated users and roles have no IAM password at all. They change their password with their company's identity provider.

A quick way to tell: if you sign in at a URL ending in awsapps.com/start, you are an Identity Center user. If you sign in with an account ID, a user name and a password, you are an IAM user, and this page applies.

For IT admins: making this a non-issue

• Select the account-level checkbox unless you have a specific reason not to. It is path-proof and covers every IAM user at once.
• If you grant per user, use the managed IAMUserChangePassword rather than a hand-written copy, so future fixes from AWS apply automatically.
• Audit old custom policies for the single-line resource pattern and for missing or old Version lines.
• Leave "administrator reset" off on small accounts unless at least two people can reset passwords, and add password changes to the NotAction list of any MFA-enforcement policy.
• Move people off IAM users where you can. IAM Identity Center gives each person one sign-in, MFA and self-service password resets without any of the policies on this page.

Frequently asked questions

Ethan selected the account-level checkbox, replaced the forum policy with the managed one for good measure, and the bookkeeper set her new password on the second attempt (the first reused last quarter's). Jake wrote "check the path" on a sticky note and stuck it on the monitor. It is still there, slightly curled, next to the one that says "check what the computer is reading."

Revision note. Written October 17, 2026. "The devil is in the details," the proverb says; in IAM, the details are in the ARN.