TBH where you see this kind of thing (mandatory periodic password rotation every month or two) being recommended, it's people not keeping up with even regulators view of good security practice.
Well, my experience working in the industry is that almost no company uses good security practices or goes beyond some outdated checklists - a huge number wants to rotate passwords, disallow/require special characters, lock out users after X attempts, or disallow users to choose a password they used previously (never understood that one).
I think the number of orgs that follow best practices from NIST etc is pretty low.
It's not necessarily the organization's fault. In several companies that I've worked for (including government contractors) we are required to implement "certifications" of one kind or another to handle certain kinds of data, or to get some insurance, or to win some contract.
There's nothing inherently wrong with that, but many of these require dubious "checkbox security" procedures and practices.
Unfortunately, there's no point in arguing with an insurance company or a contract or a certification organization, certainly not when you're "just" the engineer, IT guy, or end user.
There's also little point in arguing with your boss about it either. "Hey boss, this security requirement is pointless because of technical reason X and Y." Boss: "We have to do it to get the million dollar contract. Besides, more security is better, right? What's the problem?"
I’ve had several companies, including cyber insurers, ask for specific password expiry policies and when I’ve gone back to them explaining that we don’t expire passwords and referencing the NCSC and NIST advice all of them have accepted that without any arguments.
As you say, these are largely box ticking exercises but you don’t have to accept the limited options they give you as long as you can justify your position
And to add to this, it can sometimes be helpful to reply to every wrongheaded security request with "I am not going to decrease the security of my users.". You can use before or after, but once you've explained why a request is not permissible, you can use this line instead of repeatedly explaining.
> disallow users to choose a password they used previously (never understood that one)
That’s because you never responded to an incident when user changed their compromised password because they were forced to only to change it back next day because “it’s too hard to remember a new one”.
Disallow the use of breached passwords - whenever a password change occurs check against e.g haveibeenpwned.
No need to remember past passwords (which is another security risk btw if you ever get breached it will leak all passwords the user ever had).
Legitimate users usually aren't going to fail more than a couple times. If someone (or something) is repeatedly failing, lock that shit down so a sysadmin can take a look at leisure.
>disallow users to choose a password they used previously (never understood that one)
It's so potentially compromised passwords from before don't come back into cycle now.
I fail all the time. Oops, forgot to change my keyboard layout back or 'is it flamingmonkey1, 2, or 3 this time?' (because I have to rotate it every N months and clearly I'm not going to keep generating new passwords that I have to remember, unless the security people really explain why, which they never do), or 'oops, capslock was on', or 'does this password prompt require special characters (is it flamingmonkey1!?) or does it ban them? (or worst of all 'is whatever validates passwords just broken mysteriously and I have to reset my password to fix it?')
There's so many reasons I get passwords wrong. (it doesn't help that work has 4 systems that all use different passwords, all with different requirements).
If you locked me out (without me being able to easily unlock myself), I would immediately consider this an even-more-hostile relationship than normal and would immediately respond in kind.
> Legitimate users usually aren't going to fail more than a couple times.
Have your users authenticate to the wifi with a certificate that expires after 18 months, and you'll find users will reboot a dozen times or so, racking up authentication failures each time, before they call IT support.
I think the number of orgs that follow best practices from NIST etc is pretty low.