Should I set my password policy to never expire?

I had some people contact me about this after my Azure AD best practices guide for the SMB dropped. Microsoft has been saying to get rid of password expiration. They even award you more Secure Score points if you follow their advice and trash it. In fact, I personally have eliminated my password expiration policy, and in general I think you should work toward getting there as well. And of course eventually, the idea is to get rid of passwords, period.

But most small businesses aren’t yet at that point. Most of them don’t have great credential hygiene–it’s true. And it’s also likely that forcing too regular of a cadence to changes increases the frequency of dumb and predictable behaviors like incrementing a password by one digit at a time, etc. But all those issues aside, the key problem is this: most SMB’s simply do not have visibility into when their identity is under threat–e.g. if it has been exposed in a breach or used by an attacker to login and impersonate them. They just don’t, in my opinion, have enough in place today to be making broad assumptions about the security of their identities with any kind of confidence.

Therefore, removing the requirement to rotate that admittedly crappy password is bad advice. Yes, let’s all be shocked–Microsoft gave us bad advice. To be fair, MS does make it clear (if you read their actual publications) that orgs need to be doing additional things and adopting other services & practices in place of password rotation (so don’t just eliminate the policy without taking other steps to protect your identities).

Besides that, the “passwordless” push is coming, and there is a lot of marketing behind it too–so I’m sure there are security engineers at MS losing their minds over some of the press out there. The new “password guidance” is being misinterpreted widely in tech blogs and media outlets–both traditional and social.

In short, here are the conditions that I think you would need to meet, before you could safely disable password expiration:

1. Get MFA in place for every account. Every. Single. One. Eliminate or disable shared accounts so they don’t even have a login. Don’t forget about the exclusion that is recommended for an emergency access account, and think about protecting that one using another MFA provider (e.g. Duo)
2. Implement Conditional access to further protect the sign-on experience. For instance, if MFA is ever bypassed or phished, often Conditional access will still be able to block the sign-on attempt due to risk, location or device status.
3. Since passwords are never rotating, but credential theft still happens daily, you will want to have some indicators of when a password needs to be changed manually. Look at dark web monitoring services such as ID Agent, as well as a subscription to something like Microsoft Cloud App Security, which can alert you to unusual (especially unusual and successful) sign-ins.

And there is one additional consideration, specifically for hybrid environments: if you are in a directory synchronization situation (e.g. password hash sync), or came from DirSync/Azure AD Connect initially during your migration, then you could be bringing old demons and bad practices into the new cloud environment. So reset those passwords before going to non-expiry.

Cloud-born accounts on the other hand will support password protection out-of-the-box, but on-prem passwords and password policies always trump what you’ve got in the cloud when using Azure AD Connect, unless you purposefully implement the on-premises integration so that the local AD supports the password protection provided by Azure AD, which in turn prevents crappy passwords from being used in the first place. Again, this consideration is not as necessary for born-in-the-cloud accounts, which will prevent you from using some of the most common passwords or patterns by default.

If you can successfully tick off all of the the above stated criteria whether cloud-only or hybrid, then you would be mitigating most of the risks associated with never expiring your password.

And if you are able to go completely passwordless someday (after the feature reaches general availability of course), then you could also presumably eliminate the password rotation requirement–but I’d still recommend Conditional access, dark web monitoring and MCAS on top of that, for the same reasons already discussed.

Because even today, with the passwordless experience, it is still possible to fall back on the password (the password still exists as an attribute in the directory that can be used in an authentication attempt). Eventually however, rumor has it that passwords can be removed from the directory entirely, and then of course the expiration policy is moot. But that day is not today.