I manage a 100+ virtual machine cyber security lab built around on-premises Active Directory, where I run a capture-the-flag (CTF) exercise.
One of the easier flags asks players to review the domain password policy for accounts using password-only, or single-factor, authentication and determine whether it aligns with the current Australian Government Information Security Manual (ISM).
Recently, a player reported that the password policy wasn’t aligned because it still enforced password complexity.
My initial reaction was:
No way. Password complexity is good.
They pointed me to ISM-2080:
Password complexity requirements are not imposed for passwords.
They were right.
I try to keep up with new and updated ISM controls, but I had missed this one.
And it isn’t the only long-standing password practice that has changed.
Password expiry has changed too
Another password-related ISM change that I see catch people out concerns maximum password age.
The ISM now states:
Generally, credentials should not need to be changed…
In December 2025, ISM-1590 was updated to remove the previous requirement for user credentials to be changed at least every 12 months.
For organisations that have historically enforced password changes every 90 days, 180 days, or annually, this can feel counterintuitive.
We’ve spent years treating password complexity and regular password changes as fundamental security controls.
So why remove them?
This isn’t about making passwords weaker
At first glance, removing complexity requirements and routine password expiry could appear to weaken password security.
That’s not the intent.
The controls need to be considered together rather than individually.
For password-only authentication on systems up to PROTECTED, ISM-0421 requires passwords to be at least 15 characters long.
The ISM also provides guidance on how those passwords should be constructed. ISM-1558 specifies the use of a sequence of random words, with at least four random words used when constructing a passphrase.
The result is a shift away from passwords designed primarily to satisfy technical rules and towards passwords that are long, memorable, and difficult to guess.
Instead of something like:
P@ssw0rd1!
the objective is closer to a long passphrase composed of unrelated words.
The important security property becomes length and unpredictability, rather than whether a user has replaced an a with @ or added an exclamation mark to the end.
Complexity rules can create predictable passwords
Traditional complexity policies typically require users to include some combination of:
- uppercase characters
- lowercase characters
- numbers
- special characters
The problem is that users are still humans.
When faced with these requirements, people tend to develop predictable ways of satisfying them.
A password might start with a capital letter, contain a word or name, replace a character with a number, and finish with a special character.
The password technically satisfies the policy, but that doesn’t necessarily mean it is strong.
The policy has changed the appearance of the password without necessarily improving its unpredictability.
Long passphrases constructed from multiple random words can provide significantly greater search space while also being easier for users to remember.
Routine password changes have similar problems
Password expiry creates another predictable behaviour.
If we’re forcing users to change their password every three or twelve months, how many users are really generating a completely new password each time?
A password such as Summer2025! might become Summer2026! or Summer2025!1.
The organisation technically has password rotation.
But the user’s effective credential may have changed very little.
Frequent password changes can also encourage users to choose passwords that are easier to remember, because they know they will have to replace them again soon.
A better approach is to allow a strong credential to remain in use unless there is a reason to believe it has been compromised.
Changing the policy isn’t enough
There is another part of this change that I think is easy to overlook.
Changing the technical password policy doesn’t automatically change user behaviour.
If an organisation disables complexity requirements and routine password expiry tomorrow, users who have spent years being told to create passwords like:
Password1!
aren’t suddenly going to start creating strong passphrases.
From the user’s perspective, the computer has simply stopped forcing them to do something.
Without accompanying education, some users may interpret the change as:
Password requirements aren’t as important anymore.
That is the opposite of what we’re trying to achieve.
The technical change should therefore be accompanied by a change in guidance.
Users should understand that the new approach isn’t:
Passwords can now be simpler.
It is:
Passwords should be longer, more memorable, and harder to guess.
This is a good opportunity to explain why long passphrases are preferable to short, complicated passwords and why changing a strong password every few months doesn’t necessarily improve security.
What should organisations check?
If your environment still relies on password-only authentication, it is worth reviewing the password policy against the current ISM rather than relying on what the policy has historically required.
In particular, consider whether your implementation and guidance still reflect older assumptions around:
- password complexity
- minimum password length
- passphrase construction
- routine password expiry
And don’t stop at the technical configuration.
If you’ve changed your password policy, tell your users what changed and why.
Use the change as an opportunity to explain what a good password now looks like.
Security controls are much more effective when the people subject to them understand the behaviour the control is trying to encourage.
