Is there a possibility to integrate a password change policy for the master password?
Depending on the infrastructure and environment, you have to change a password in a cycle of x days. However, the master password remains unaffected and is always the same.
In Enterprise plans, the administrator can set up a number of policies, but a master password expiration date is not available as a policy.
To be clear, it is generally recognized that setting an expiration date for passwords that have to be memorized (like the master password) should be avoided when possible, as it creates more problems (i.e., security vulnerabilities) than it solves. For example, this is what the US National Institute of Standards and Technology (NIST) has to say about the matter [source]:
“Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”
Users tend to choose weaker memorized secrets when they know that they will have to change them in the near future. When those changes do occur, they often select a secret that is similar to their old memorized secret by applying a set of common transformations such as increasing a number in the password. This practice provides a false sense of security if any of the previous secrets has been compromised since attackers can apply these same common transformations.
for this reason, it is possible to define settings such as length and complexity for a password. this is already possible today for the master password. thus, the user cannot weaken his password much.
but there are certain regulatory institutions that require a sporadic password change. since the user does not do this proactively, it would be practical to be able to define this by policy.