How do you configure a strong IAM password policy in Huawei Cloud?

What “strong” means in Huawei Cloud IAM password policy

A strong IAM password policy is one that raises the cost of guessing, spraying, and reuse while still being supportable for the users who must live with it. In Huawei Cloud, that usually means longer passwords, stronger composition rules where required, password history, and sensible expiry or reuse limits, with stricter treatment for privileged accounts than for ordinary users.

A policy is only useful if it matches how the account is actually used. The same baseline should not be applied blindly to all identities: administrators, break-glass accounts, and service-facing administrative paths need tighter handling than low-risk user accounts because the blast radius of compromise is much larger.

How to set the policy so it is actually effective

Start by defining the minimum length and complexity settings that your environment can enforce consistently, then add history controls so users cannot cycle back to a recently used password. If Huawei Cloud supports expiry controls in your tenancy, use them to reduce the lifetime of exposed passwords, but do not rely on expiry alone as your main defence.

The policy should be paired with MFA wherever the platform and account type allow it, because password strength is only one layer. A strong password slows down guessing, but it does not neutralise phishing, credential stuffing, or password reuse from another breached site. That is why the policy should be part of a broader authentication design rather than a stand-alone hardening task.

For privileged users, treat password policy as a risk-reduction control, not a compliance checkbox. Privileged accounts should have the strongest feasible password requirements, tighter rotation or reset triggers, and extra monitoring for failed logons and unusual reset activity. Identity Security Programme Guide is useful when you want to place those account-level controls inside a wider governance model.

What to watch for after you turn it on

Passwords become a weak point when enforcement exists only on paper. The practical failures are predictable: users choose memorable patterns that meet the minimum, administrators exempt accounts to reduce friction, or password resets become an alternate path for takeover. Reused passwords, stale accounts, and forgotten privileged accounts create the conditions where policy exists but exposure remains.

Inactive accounts deserve particular attention because they often retain valid credentials long after the owner has stopped using them. If those accounts are not reviewed, they become attractive takeover targets, especially when the password policy is strong but the lifecycle process is weak. NHI Lifecycle Management Guide reinforces the importance of discovery, ownership, rotation, and offboarding, which are the same failure points that matter for IAM account hygiene.

Watch password reset flows as closely as you watch logon policy. Attackers often prefer resets, recovery channels, and help-desk exceptions because they bypass the strength of the password itself. Repeated failures, repeated resets, and sudden changes to dormant accounts are usually more informative than the password string length in isolation.

Risk and Threat Considerations

Weak or inconsistently enforced password policy creates an easy path for guessing, password spraying, and reuse-based compromise. The biggest risk is not a single bad password, but a policy gap that leaves privileged or forgotten accounts easier to take over than the organisation assumes.

Failure mechanism: Attackers exploit short, reused, or stale passwords, then pivot through reset flows or inactive accounts where monitoring is weaker and ownership is unclear.

Impact: A compromised IAM account can expose administrative functions, sensitive cloud resources, and security settings, turning a basic authentication weakness into broader account takeover risk.

Practitioner Guidance

What to prioritise: Set a strong baseline for ordinary users, then carve out stricter handling for administrators and any account that can change security settings, not just for “important” users in name. In practice, privileged account policy matters more than average-user policy when you are deciding where compromise would hurt most.

What to verify: Confirm that the policy is actually enforced on new passwords, password changes, and reset events, and that exceptions are documented. If a team can still create or preserve weak passwords through a special process, the control is incomplete even if the console shows the right settings.

Common mistake: Treating password expiry as the primary defence. Expiry can help reduce exposure window, but it does not stop reuse, phishing, or spraying, so it should never be the only serious control around IAM authentication.

Practitioner takeaway: The strongest IAM password policy is the one that is enforced, monitored, and paired with lifecycle discipline, especially for privileged and inactive accounts.

Related resources from NHI Mgmt Group

• Guide: Password Security and Password Manager Guide
• How do you configure password policy requirements in an AWS Cognito user pool?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• What is the difference between human IAM controls and NHI governance?