Use aws iam get-account-password-policy to read the custom password policy for IAM users in your AWS account. It is a configuration inspection, not a password-strength test against individual accounts and not an MFA audit. A successful response describes password rules; it does not establish that every identity uses multi-factor authentication.
This narrow check is useful when an access-review ticket asks what console-password requirements are configured. Keep that question separate from root-account security, access-key rotation and the controls applied by an external identity provider.
Confirm which account and identities you are reviewing
Start with an approved AWS CLI profile and verify its account and role. The account and role preflight helps prevent attaching a technically correct response from the wrong environment to your audit ticket.
AWS documents iam:GetAccountPasswordPolicy as the permission to view the account’s password policy. Ask for that read capability through your normal access process if it is missing. You do not need policy-update or policy-delete permission for this task, and you should not create a test user or change a password simply to demonstrate that the read works.
Define scope in the ticket: “IAM user console-password policy for the verified account.” Do not label it a complete AWS authentication review. AWS explicitly says this password policy does not apply to the root user’s password or to IAM user access keys.
Run the read-only CLI command
After replacing the example profile name with an existing authorised profile, run:
aws iam get-account-password-policy --profile review --output json --no-cli-pagerKeep the full response and record the review time and account context. Do not include access keys, session tokens or passwords in screenshots. The command retrieves configuration; it does not reset passwords, enforce MFA or make changes to sign-in settings.
If the command fails, preserve the error before deciding what it means. Expired credentials, denied access and an absent custom policy are different outcomes. A connection failure is not evidence that the account has weak password settings, and repeated attempts with broader administrator credentials are not the first troubleshooting step.
Read the returned fields without inventing compliance
A successful custom-policy response contains a PasswordPolicy structure. Review the minimum length, required character types, whether users may change their own passwords, expiry information and any reuse-prevention setting. Record the values actually returned; do not silently replace missing fields with the values you expected.
For example, a hypothetical response with a minimum length of fourteen and ExpirePasswords: false documents those two configuration facts. It does not establish that every existing password is fourteen characters long. AWS explains that changes to minimum length and character requirements are enforced when users next change their passwords, rather than forcing all existing passwords to change immediately.
Expiry settings need separate care. AWS says a newly configured expiration period can affect already-old passwords immediately. This article deliberately makes no configuration change. If a later remediation proposes expiry or administrator-reset requirements, assess the operational impact and recovery arrangements under an approved change plan.
Interpret NoSuchEntity as no custom policy, not no rules
The CLI reference states that NoSuchEntity is returned when no password policy is defined for the account. Read this together with the IAM user guide: when an administrator has not set a custom policy, AWS’s default password policy applies to IAM user passwords.
Therefore, a useful finding is “No custom account password policy returned; AWS default policy applies,” with the service response retained as evidence. Do not write “passwords have no requirements.” Consult the current default-policy section in AWS documentation when comparing the account with your organisation’s standard, rather than copying a remembered default into the report.
Conversely, AccessDenied does not establish that the custom policy is absent. Resolve the permission or account-selection issue before reporting the policy outcome.
Separate the remaining security questions
- MFA: the password-policy response does not inventory enrolled devices or demonstrate MFA enforcement for sign-in or privileged actions.
- Access keys: these password rules do not rotate, revoke or expire API access keys. AWS notes that a user with an expired console password can continue using their access keys.
- Root identity: review root security separately; the IAM user password policy does not govern the root password.
- Federated access: obtain the relevant identity-provider and federation evidence rather than assuming an IAM user setting governs those credentials.
Does reading the policy prove our users meet it? No. It supplies configuration evidence with the enforcement limitations above, not a measurement of each user’s secret.
Should I delete a custom policy to restore access? Not as part of this inspection. Deletion changes account-wide password requirements and requires a separate authorised decision.
Sources and educational-use notice
The AWS CLI reference describes the operation, output and absent-policy error. The IAM password-policy guide explains defaults, scope and enforcement timing.
This tutorial is for educational purposes. Test carefully before using steps in production. The site owner is not responsible for misuse, damage, data loss or production issues.
