Yes. When a policy is crazy, the Right Thing is to find out how to either alter that policy or obtain an authorised deviation from it as tatersolid describes.

If you spend an hour a month on something that's required by policy and in your opinion shouldn't be, then six hours invested finding the person who sets that policy and explaining why it's a terrible idea may free up net six extra hours of your life within a year.

That story where the guy comes down a mountain with a stone tablet with Ten Commandments carved into it is (a) a myth and (b) no kind of a way to set effective policy. People can't even agree on what his Ten Commandments were, let alone on following them.

As always with PCI, it depends on your auditor.

Using NIST password guidelines as a compensating control has been accepted by every assessor I’ve dealt with (even the really bad ones). A compensating control must exceed the requirements of the control its compensating for, and the NIST rules clearly do. I’d say it has much more to do with how you write your compensating control worksheet rather than anything else. If you assessor is refusing to accept compensating controls, you should report them to the SSC, and then find a new assessor.

Yes, if you’re not actually doing the “compare password against breach lists” part of SP 800-63B regularly they likely won’t accept it.

I hope forced expiry will be gone from next PCI revision anyway.

Do you happen to have a library/tool you could recommend that helps with this or did you develop something in-house?

My startup is implementing most of the NIST rec’s with the help of projects like zxcvbn but we would like to also start doing breach list comparisons so figured I’d ask.

We use the NTLM version of the haveibeenowned lists plus a power shell script from https://github.com/MichaelGrafnetter/DSInternals/blob/master...

H8mail on Github and the APIs it connects to.