Two AWS commands set an IAM user’s console password, and picking the wrong one returns NoSuchEntity instead of a new password. Which one you need depends on a single fact about the user: whether they have ever had console access at all. Most guides show only update-login-profile, which is the command that fails on a brand new user.
This guide covers both routes end to end: resetting an IAM user password from the AWS Management Console, doing the same from the AWS CLI, letting users change their own password, and setting the account password policy that decides whether any of those attempts are accepted. It also covers the two identities people confuse with IAM users, the root user and IAM Identity Center, because the reset procedure for those is completely different. Every command below was run on a live AWS account in August 2026 with the CLI reporting aws-cli/1.42.18, and the screenshots come from that same session. AWS CLI v1 is in maintenance mode, so install v2 if you are starting fresh; the IAM subcommands below take the same flags in either version.
Which password you are actually resetting
Three different sign-in identities live behind the AWS console, and none of them shares a password store with the others. Getting this wrong is the most common reason a reset “does not work”: the command succeeds against the wrong identity, or fails because the identity is not an IAM user in the first place.
| Identity | Signs in at | How the password is reset |
|---|---|---|
| IAM user | Account sign-in URL with an IAM username | IAM console or aws iam update-login-profile. This guide. |
| Root user | Console with the account email address | “Forgot password” on the root sign-in page, email verification. No IAM API can set a root password. |
| IAM Identity Center user | AWS access portal, a d-xxxxxxxxxx start URL | Identity Center console, or the source directory when the identity is synced from Active Directory or an external IdP. |
The IAM API is blunt about the boundary. Feed it a username that belongs to the access portal rather than to IAM and you get a rejection that names the user, not the password:
aws iam update-login-profile --user-name [email protected] --password 'S0me-Strong-Pass!2026'No IAM user by that name exists, so nothing about the password is even evaluated:
An error occurred (NoSuchEntity) when calling the UpdateLoginProfile operation: The user with name [email protected] cannot be found.Email-shaped usernames are the giveaway. IAM usernames are usually short and flat, while access portal identities are normally email addresses fed in from a directory. If you inherited the account and are not sure which system is in play, check whether an Identity Center instance exists before you go hunting for an IAM user:
for r in eu-west-1 eu-north-1 us-east-1 ap-south-1; do
printf '%-14s %s\n' "$r" "$(aws sso-admin list-instances --region "$r" --query 'length(Instances)' --output text)"
doneThe Region loop is not decoration. That endpoint is regional and an Identity Center instance answers only in the Region it was enabled in, so the same account reports both answers depending on where you ask:
eu-west-1 1
eu-north-1 0
us-east-1 0
ap-south-1 0A 1 anywhere means the account has Identity Center enabled and your users may well live there. A 0 only rules it out for the Region you queried, which is the trap: query your default Region alone, get 0, and conclude wrongly that every human password in the account belongs to the root user or an IAM user. Sweep the Regions you actually use, or open the Identity Center console, before believing a negative.
Change an IAM user password from the AWS console
The console path is the one to use when you are handing a password to a human, because it can generate a compliant password for you and it never puts the password into your shell history. Open the IAM console, choose Users in the navigation pane, click the username, then open the Security credentials tab. The Console sign-in panel is where password state lives.
The button in that panel changes depending on the user’s current state, and the label tells you which of the two CLI commands you would otherwise need. Enable console access means the user has no password yet. Manage console access means they already have one.
Selecting Reset password expands the password options. Autogenerated password hands you a compliant string you can copy or download once. Custom password lets you type one, and the requirement list under the field is generated from your account password policy rather than from a fixed AWS default, so it is a live readout of what this account will accept. In the capture above the account requires 14 characters, all four character classes, and lists the acceptable symbols as ! @ # $ % ^ & * ( ) _ + - = [ ] { } | '.
Two checkboxes matter more than they look. User must create new password at next sign-in is the console equivalent of the CLI’s --password-reset-required, and it is what you want whenever you are the one choosing the password, since it stops your chosen string from becoming their permanent one. Revoke active console sessions deals with the part a password change does not: an already signed-in browser session stays valid after you rotate the password. Ticking it attaches an inline deny policy to the user, named in the dialog as AWSRevokeOlderSessions. The policy denies everything issued before the moment you tick the box, keyed on aws:TokenIssueTime.
Only tick the revoke option when you are responding to something. On a routine rotation it will knock the user out of a session they are actively using, and the inline policy stays attached afterwards.
Reset an IAM user password with the AWS CLI
The CLI route is the one you want for scripted onboarding, for offboarding, and for the case where the console itself is what you cannot reach. You need the AWS CLI configured with credentials that carry iam:UpdateLoginProfile or iam:CreateLoginProfile. If the CLI is not set up yet, the AWS CLI install and configuration steps cover that first.
The username repeats in every command below, so export it once:
export IAM_USER="alice"Before touching anything, find out which of the two commands applies. A login profile is IAM’s term for “this user has a console password”, and it exists separately from the user:
aws iam get-login-profile --user-name "${IAM_USER}"A user who already has console access returns the profile, including whether they are currently under a forced change. The outputs in this section come from the test user this guide was written against, this one read after its profile had been recreated mid-testing:
{
"LoginProfile": {
"UserName": "cfg-lab-demo-user",
"CreateDate": "2026-08-19T21:44:27Z",
"PasswordResetRequired": false
}
}If that command returned a profile, change the password with update-login-profile. Add --password-reset-required so the string you picked is temporary:
aws iam update-login-profile --user-name "${IAM_USER}" \
--password 'T3mp-Console-Pass!2026' --password-reset-requiredSuccess is silent. Nothing prints, and the next console sign-in by that user lands on a forced password change screen rather than in the console.
That screen serves double duty. The same page appears when a password has aged past the account’s MaxPasswordAge, which is why the wording covers both cases at once, and why an expired password usually needs no admin action as long as the user still knows the old one. The exception is --hard-expiry, which stops a user from setting a new password once theirs has expired and hands the reset to an administrator. It only closes the console door, though: a user holding iam:ChangePassword with active access keys can still rotate an expired password through the CLI. Note also that completing the change does not drop the user into the console. AWS returns a success page with a Continue to sign in link, and they sign in again with the new password.
Clearing a forced change without changing the password again uses the negated flag:
aws iam update-login-profile --user-name "${IAM_USER}" --no-password-reset-requiredOne warning about all of these. A password passed as a command line argument lands in your shell history and is visible in the process list while the command runs. Prefer the console’s autogenerated password when you are provisioning for someone else, and if you must use the CLI, prefix the command with a space on a shell configured with HISTCONTROL=ignorespace.
Error: “Login Profile for User … cannot be found”
This means the IAM user exists but has never had console access, so there is no password to update. It is the single most common failure on this task, and it is why copying update-login-profile out of an older guide fails on a freshly created user:
An error occurred (NoSuchEntity) when calling the UpdateLoginProfile operation: Login Profile for User cfg-lab-demo-user cannot be found.Read the noun carefully, because IAM returns NoSuchEntity for two unrelated problems. “Login Profile for User X cannot be found” means the user is real and needs create-login-profile. “The user with name X cannot be found” means the username itself is wrong. Create the missing profile with:
aws iam create-login-profile --user-name "${IAM_USER}" \
--password 'T3mp-Console-Pass!2026' --password-reset-requiredUnlike the update, this one prints the profile it created:
{
"LoginProfile": {
"UserName": "cfg-lab-demo-user",
"CreateDate": "2026-08-19T21:27:25Z",
"PasswordResetRequired": true
}
}A console password is only half of console access. The user also needs permissions, because a new IAM user has none, and signing in successfully to an empty console is a support ticket waiting to happen. Grouping users and attaching policies at the group level is covered in the guide on creating IAM users and groups from the CLI.
Error: “Login Profile for user … already exists”
You used create-login-profile on a user who already has a password. The two commands are not interchangeable in either direction:
An error occurred (EntityAlreadyExists) when calling the CreateLoginProfile operation: Login Profile for user cfg-lab-demo-user already exists.Switch to update-login-profile and the same password goes through. For a script that must handle both cases, try the update first and fall back to create on NoSuchEntity, since the update is the common path for any account that has been running a while.
Let users change their own password
An admin resetting passwords by hand is a bottleneck, and AWS gives you two ways to hand the job back to the user, though the two are not equivalent.
The blunt one is an account setting. Enabling Allow users to change their own password in the IAM account password policy grants every IAM user in the account access to the iam:ChangePassword action for their own user, plus iam:GetAccountPasswordPolicy so the change form can display the rules. One flag, whole account:
aws iam update-account-password-policy --allow-users-to-change-passwordRead the next section before running that on its own, because on its own it will wipe the rest of your policy.
The targeted one is the AWS managed policy IAMUserChangePassword, which you attach to selected users or, better, to a group. Inspect what it actually grants before trusting it:
aws iam get-policy-version \
--policy-arn arn:aws:iam::aws:policy/IAMUserChangePassword \
--version-id $(aws iam get-policy --policy-arn arn:aws:iam::aws:policy/IAMUserChangePassword \
--query 'Policy.DefaultVersionId' --output text) \
--query 'PolicyVersion.Document'The document scopes the change to the caller’s own user through a policy variable, which is what keeps it from becoming a password reset tool for everyone:
{
"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": "*"
}
]
}Attach it to the user or group that should self-serve:
aws iam attach-user-policy --user-name "${IAM_USER}" \
--policy-arn arn:aws:iam::aws:policy/IAMUserChangePasswordOnce either mechanism is in place, the user finds the control on their own Security credentials page, reached from the account menu at the top right of the console rather than through IAM, which a non-admin cannot browse. The panel carries the same Console sign-in heading as the admin view, but the button reads Update console password instead of Manage console access, and the panel doubles as the quickest audit of a single account: it shows when the password was last changed and when the user last signed in.
Users who prefer the terminal, and who hold iam:ChangePassword, can rotate their own password without an admin:
aws iam change-password --old-password 'T3mp-Console-Pass!2026' --new-password 'M1ne-Not-Yours!2026'That command carries a precondition worth knowing before you recommend it: the user needs active access keys, because the call is signed with them. A console-only user, which is most of the people this permission is granted to, cannot run it at all and has to use the browser. Root credentials cannot run it either.
There is a trap waiting for anyone who tries to verify this permission with the policy simulator. The simulator evaluates identity and resource policies, and the account-level setting is neither, so it cannot see permissions granted that way. Worse, it also cannot resolve ${aws:username} on its own. Simulating the action against a user who has IAMUserChangePassword attached still reports a denial:
aws iam simulate-principal-policy \
--policy-source-arn "arn:aws:iam::123456789012:user/${IAM_USER}" \
--action-names iam:ChangePassword \
--query 'EvaluationResults[].[EvalActionName,EvalDecision]' --output textThe verdict looks alarming and is wrong:
iam:ChangePassword implicitDenyFeed the username in as a context entry and the same call resolves the variable, matches the statement, and names the policy that allowed it:
aws iam simulate-principal-policy \
--policy-source-arn "arn:aws:iam::123456789012:user/${IAM_USER}" \
--action-names iam:ChangePassword \
--resource-arns "arn:aws:iam::123456789012:user/${IAM_USER}" \
--context-entries "ContextKeyName=aws:username,ContextKeyValues=${IAM_USER},ContextKeyType=string" \
--query 'EvaluationResults[].[EvalActionName,EvalDecision,MatchedStatements[0].SourcePolicyId]' --output textThat is the answer you were looking for:
iam:ChangePassword allowed IAMUserChangePasswordAny policy whose resource is scoped with ${aws:username} behaves this way in the simulator, so the same context entry is worth remembering when you audit the policy that lets users manage their own access keys and SSH public keys.
Set an account password policy the console will enforce
Every password you set, whether from the console or the CLI, is validated against the account password policy. Read it first, because the answer on a fresh account is not what most people expect:
aws iam get-account-password-policyAn account with no custom policy does not return AWS defaults. It errors, and the message uses the account ID as a domain name:
An error occurred (NoSuchEntity) when calling the GetAccountPasswordPolicy operation: The Password Policy with domain name 123456789012 cannot be found.That error does not mean anything goes. AWS still enforces a built-in minimum, and the rejection message spells out the rule it applied. An eight character lowercase password on an account with no policy at all fails like this:
An error occurred (PasswordPolicyViolation) when calling the UpdateLoginProfile operation: Password should meet 2 more of the following requirements: Password should have at least one uppercase letter, Password should have at least one number, Password should have at least one symbolWhat you are hitting is the default AWS password policy: a floor of eight characters with at least three of the four character classes, a ceiling of 128 characters, and a rule that the password cannot be identical to the account name or email address. Go under the floor and the message changes to Password should have a minimum length of 8. Both are the errors you meet while scripting against an account nobody has hardened yet.
Set a real policy in one call. Every flag you want must appear in it:
aws iam update-account-password-policy \
--minimum-password-length 14 \
--require-symbols --require-numbers \
--require-uppercase-characters --require-lowercase-characters \
--allow-users-to-change-password \
--max-password-age 90 \
--password-reuse-prevention 5Read it back to confirm what landed. Note ExpirePasswords, which you never set directly: IAM derives it from the presence of MaxPasswordAge.
{
"PasswordPolicy": {
"MinimumPasswordLength": 14,
"RequireSymbols": true,
"RequireNumbers": true,
"RequireUppercaseCharacters": true,
"RequireLowercaseCharacters": true,
"AllowUsersToChangePassword": true,
"ExpirePasswords": true,
"MaxPasswordAge": 90,
"PasswordReusePrevention": 5
}
}The console renders the same policy under Account settings, which is the fastest way to show someone else what the account requires without giving them IAM read access to your terminal:
Error: “PasswordPolicyViolation … Password cannot be the same as previously used password”
Reuse prevention applies to administrators, not just to users changing their own password. With --password-reuse-prevention 5 set, an admin calling update-login-profile with a password that user has had before is rejected the same way a self-service change would be:
An error occurred (PasswordPolicyViolation) when calling the UpdateLoginProfile operation: Password cannot be the same as previously used passwordThis catches automation that resets a batch of users to a shared temporary password on a schedule. The second run fails for everyone who was reset in the first. Generate a distinct password per user instead.
update-account-password-policy replaces the entire policy
The command name says update. The behaviour is replace. Any flag you leave out is not preserved, it is reset, and nothing warns you. This is the most expensive mistake available on this API, so it is worth seeing rather than trusting.
Starting from the full policy shown above, here is a change that looks like it only tightens length:
aws iam update-account-password-policy --minimum-password-length 16Every other setting is gone. The complexity requirements are off, expiry is off, reuse prevention has vanished from the response entirely, and self-service password changes have been silently revoked for every user in the account:
{
"PasswordPolicy": {
"MinimumPasswordLength": 16,
"RequireSymbols": false,
"RequireNumbers": false,
"RequireUppercaseCharacters": false,
"RequireLowercaseCharacters": false,
"AllowUsersToChangePassword": false,
"ExpirePasswords": false
}
}The account went from a 14 character four-class policy with 90 day expiry to a 16 character policy with no complexity rules at all, and the help desk starts getting password requests it did not get yesterday.
It gets worse when the flag you keep is not the length one. Omitting --minimum-password-length does not hold your value and does not fall back to the documented default of eight:
aws iam update-account-password-policy --require-numbersIt reverts to six, which is a weaker floor than an account carrying no password policy at all:
{
"PasswordPolicy": {
"MinimumPasswordLength": 6,
"RequireSymbols": false,
"RequireNumbers": true,
"RequireUppercaseCharacters": false,
"RequireLowercaseCharacters": false,
"AllowUsersToChangePassword": false,
"ExpirePasswords": false
}
}That floor is enforced, not cosmetic. With this policy in place abc123 was accepted as a console password on the same account that had rejected an eight character lowercase password a few minutes earlier. A call whose only stated purpose was to require numbers left the account measurably weaker than having no policy.
If you ran that against a real account to see it for yourself, put the policy back before you read on:
aws iam update-account-password-policy \
--minimum-password-length 14 \
--require-symbols --require-numbers \
--require-uppercase-characters --require-lowercase-characters \
--allow-users-to-change-password \
--max-password-age 90 \
--password-reuse-prevention 5Inherited a half-set policy and unsure what it was meant to be? Deleting it is the counter-intuitive fix. aws iam delete-account-password-policy drops the custom policy and drops the account back to the default AWS policy, and at eight characters with three of four character classes that default is stronger than the six character policy a partial update leaves behind.
Treat the full command as the unit of change: keep it in version control next to your other account baselines, edit the file, and re-run the whole thing. Reading the policy back after every write is a two second habit that catches this immediately.
When the user cannot sign in at all
IAM users have no self-service password recovery. There is no “forgot password” email for them, because IAM users do not necessarily have a verified email address attached. Someone with IAM permissions has to reset it, which is exactly why an account should never have its only administrator be an IAM user with no second path in.
The sign-in page itself is the first thing to check. IAM users sign in with an account ID or an account alias plus their IAM username, not with an email address, and a user who tries the email field is using the root user form.
AWS is mid-migration on these pages, and the banner in the capture, live as of August 2026, announces sign-in and sign-up updates rolling out from mid-2026 behind a Change to new experience switch, so expect the layout to move even though those two fields will not.
If nobody can remember the sign-in URL, it is derivable from the account ID as https://123456789012.signin.aws.amazon.com/console. An alias makes it memorable, and setting one takes a single call:
aws iam create-account-alias --account-alias my-companyCheck for an existing one with aws iam list-account-aliases before you run that. An account holds exactly one alias, so setting a new one replaces the old and the previous URL stops working, which is a memorable way to lock out the colleagues who bookmarked it. Aliases must be unique across all AWS products in the partition, so any common word is already taken. The URL becomes https://my-company.signin.aws.amazon.com/console, and the account-ID form keeps working either way.
A lost MFA device is a different problem wearing the same shirt. Resetting the password does not help, because MFA is checked after the password. An administrator has to deactivate it with aws iam deactivate-mfa-device, which needs the --serial-number that list-mfa-devices prints, and the user then re-enrolls. Deactivating leaves the virtual device entity in the account, so re-enrolling under the same device name also needs aws iam delete-virtual-mfa-device first. Check what is enrolled before you start resetting anything:
aws iam list-mfa-devices --user-name "${IAM_USER}"An empty MFADevices array means the password is the only thing standing between a leaked string and your account, which is its own finding.
Remove console access without deleting the user
For a contractor whose engagement ended, or a user who should only ever have used the API, delete the login profile rather than the user:
aws iam delete-login-profile --user-name "${IAM_USER}"It succeeds silently, and afterwards the user is still there with their permissions intact while the console door is shut. Confirming it worked means expecting an error:
An error occurred (NoSuchEntity) when calling the GetLoginProfile operation: Login Profile for User cfg-lab-demo-user cannot be found.Two things this does not do. Access keys keep working, so a user locked out of the console can still drive the API until you deactivate those separately. And an active browser session survives. A session opened before the change was still loading the IAM console on the test user after two password rotations and after the login profile had been deleted outright, which is the gap the AWSRevokeOlderSessions checkbox exists to close.
The ordering also matters when you really are removing someone. A login profile is a child object, so aws iam delete-user refuses outright while one still exists:
An error occurred (DeleteConflict) when calling the DeleteUser operation: Cannot delete entity, must delete login profile first.Delete the login profile, the access keys, and the attached policies first, then the user, working through whatever child object the error happens to name.
Audit console passwords across the account
Password resets are usually reactive. The useful version of this task is periodic and answers a different question: which IAM users can reach the console at all, and how stale is each password? Loop the two commands you already know across every user:
for u in $(aws iam list-users --query 'Users[].UserName' --output text); do
created=$(aws iam get-login-profile --user-name "$u" \
--query 'LoginProfile.CreateDate' --output text 2>/dev/null || echo "no-console-access")
mfa=$(aws iam list-mfa-devices --user-name "$u" --query 'length(MFADevices)' --output text)
printf '%-30s console=%-26s mfa=%s\n' "$u" "$created" "$mfa"
doneResist the temptation to read that CreateDate as password age. It is the date console access was first granted, and it does not move when the password changes. Rotating the test user’s password twice with update-login-profile left the timestamp pinned to its original value both times, so the column answers “has had console access since” and nothing more. Any row pairing console access with mfa=0 is worth acting on before you think about rotation anyway.
Real password age lives in the credential report, which is the one place AWS records when each password was actually last set:
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode | cut -d, -f1,4,5,6,7Those five columns are user, password_enabled, password_last_used, password_last_changed and password_next_rotation. The fourth is the one the login profile cannot give you, and the fifth is populated only when the account policy sets a maximum age.
Two caveats before you build a report on top of it. Generation is asynchronous, so running the read immediately after the generate can come back with ReportInProgress, and you simply run it again. More importantly, IAM only builds a fresh report once every four hours and serves the cached copy in between, so password_last_changed can lag a rotation you did minutes ago. The GeneratedTime field in the response tells you which report you are actually reading.
One last edge to script around. aws iam get-user also reports a PasswordLastUsed field, but for a user who has never signed in the key is absent entirely rather than null or empty, so anything that assumes it exists breaks on exactly the dormant accounts you were looking for.
Two adjacent tasks come up in the same maintenance window often enough to be worth bookmarking: an IAM username is not editable, so renaming an IAM user is its own procedure, and database credentials do not live in IAM at all, which is why resetting an RDS master user password goes through the RDS API instead. For application credentials, stop rotating by hand and move them into Secrets Manager with automatic rotation. The full set of password constraints IAM applies is documented in the AWS guide to setting an account password policy.
