Password Changes hero image

Disclaimer: Before we start, the following applies to regular user accounts and is not advisable for privileged accounts or accounts that are unable to use multi-factor authentication (MFA).

The Problem?

As users, aren’t we sick of being forced to change our passwords for no reason? Then have to update each device and even sometimes the odd application?

As IT professionals and CIOs, isn’t it painful to see how much time and money we spend on password issues, not to mention all the complaints and gripes?

So imagine being able to go passwordless, reducing Help Desk tickets related to passwords by 60-80%, while giving back hundreds of hours a year to end users. Depending on the size of your organization this can save many thousands of dollars per year.

Read on…


Our story begins in the late 1990’s, back in those days the Identity Management industry decided a great way to thwart brute force password attacks was to have users change their passwords every 90 days. In short, we didn’t exactly know if an account was compromised so we just figured changing passwords regularly made sense. I guess 90 days must have been a fair trade-off between business disruption and security.

It’s been one of our industry’s biggest struggles, securing the crown jewels without shoving security in the face of our users. In the end they just want to access the applications and services needed to do their job. They should not need to know special security hoops to jump through, nor see security barriers as we triple check it’s still them.


I was privileged to run enterprise security during my time at both Adobe and Cisco. In both cases I was responsible for workforce Identity and Access Management, Directory & Authentication and led zero trust strategy and execution. Under that remit I decided to create a security intelligence team that would focus on applying machine learning (ML) and user and entity behavior analytics (UEBA) to data.

If the problem is knowing when an account might be compromised we decided to use data and UEBA/ML to answer this question.

However, removing the need to rotate passwords, while satisfying the regulatory requirements meant we needed to demonstrate more. We approached this in four ways:

  1. Using certificates
  2. Device posture
  3. Requiring MFA everywhere
  4. Security intelligence

So, let’s acknowledge that this isn’t exactly zero trust. Just good-old identity management fun, the stuff I wish we all had done – well at least number 1 & 2…

Time to dig in further…

1. Using certificates and device posture
The goal here is to adapt your IDP workflow to leverage a certificate instead of a password. The certificate would be stored in a trusted platform module (TPM) or secure enclave. The certificate would be tied not just to the user ID, but also the specific device. This means if the user has three devices there are three unique certificates; one per device. In the event of a device compromise that specific certificate would be revoked; but leaving the other two active.

2. Device Posture
If one of the challenges is account takeover, then requiring devices meet a minimum security posture to allow a login makes great sense. This isn’t a new concept, it’s been around in the VPN and networking world for many years. But their approach focused on the goal of gaining access to a network. In our case we are less concerned about the network and more concerned about the application and data being accessed. This is because fewer users and applications are actually on your network. So, device posture verification during application login is far more important. In our case, being granular and identity-based provides more control, based on user, device, and application. Posture requirements can be more dynamic based on policy and risk.

3. Requiring MFA Everywhere
While at Adobe our team leveraged Okta’s IDP and published a self-service method enabling application teams to enroll their apps with Okta. This meant we quickly had over 2,000 applications leveraging Okta and requiring MFA. A great partner makes it easy to enable this via APIs and it’s vital to your quick success. I’ve little patience (as people at Okta will attest to), but a great partner enables rapid deployment.

4. Security Intelligence
In Adobe we built our own Sec Intel platform using open source; while at Cisco we partnered with Exabeam. The important thing is that we only ingested required data (which for security reasons we’re not documenting here). We managed to use data that would demonstrate when a user’s behaviour deviated from regular patterns, reflected in a dynamic risk score. When this occurred we contacted the user in the same way your bank does when it sees abnormal transactions.

It’s at that point we would determine if the user’s password should be changed.

Our friends at Exabeam have a great write-up that explains behavior analytics and trust scoring:

Side Topic: Password Managers and Password Complexity

There’s two somewhat related categories here – password managers and privileged password/secrets vaulting. For this post I’ll speak to password managers.

First of all, I’m a big fan of password managers for both your professional and personal life. Ensuring all passwords are unique and available across devices, OSs, and browsers is a great step to keeping your accounts protected. A decent password manager will track compromised, re-used or weak passwords and enable an easy way to update those passwords.

If your company has its identity act together then all corporate applications and services would tie back to your directory and authentication platform. Which would mean there’s very few passwords to worry about in your corporate life. It’s for this reason that some IT teams are no longer offering password managers as a corporate service. In some cases negotiated an employee discount. For me personally I am all-in on password managers and always recommend their use for your corporate and personal accounts.


There’s many upsides that result from the above-discussed items. Imagine being the person who removed the need for 40,000 people to change their passwords every 90 days… walking Adobe’s hallways my team and I were filled with pride. Oh, not to mention some free lunches from delighted users 😉

  • Service desk ticket reduction: Tickets related to password changes are almost always in the top 10 of any Service Desk load. So in large companies like Adobe and Cisco this would equate to thousands of tickets per month. This shift enabled a reduction between 60-80% of those tickets.
  • User productivity:
    • Changing a password often means updating several devices, so we guessed 5-15 minutes per user per quarter. So quick calculation…10k users is equal to 10,000 hours per year!
    • Back to the service desk tickets, this usually means someone has an issue and therefore unable to login – we never calculated the true cost of that…


As we wrap up, the ability to remove the 90-day password change, aka going passwordless, requires some serious effort to ensure these four things exist:

  1. Using certificates
  2. Device posture
  3. Requiring MFA everywhere
  4. Security intelligence

However, it goes beyond the benefits of doing these things. It’s a launch point for using Security Intelligence for other ideas where we are able to use data to our advantage. And, while it’s not a pure zero trust play, we at Banyan Security would plant the seed that our solution will get you a good part of the way there…

See our “Passwordless Authentication with Zero Trust” blog for more information on going passwordless.