Sure in theory you could use a more decentralized solution but often there are no COTS solutions for this and making your own would require it to be certified, so that's not feasible. In some options you might even be better of with not deploying such a single point of failure. However for certifications that's often not an option.
There’s nothing stopping you implementing something better than the now slightly outdated recommendations/best practice for those controls found in 27002. It is guidance only, and if you have good reason to implement a control in a different way, or to not implement a control that is listed but instead treat a risk with an entirely different control you are free to do that.
That’s not to say that 27001 doesn’t have other flaws, and that it isn’t sold/understood as being something it’s not in a problematic way.
It seems like a quintessential example of "the road to hell is paved with good intentions". Either the prescribed solutions are bad, or the drive to check off boxes in an audit results in shallow implementations that appear to do something but don't actually.
But I appreciate that the password example wasn't the point of your comment. Organisations will often default to a certification and/or standard blindly because they don't have the knowledge of how to do it differently themselves, or they don't want to be on the hook for choosing to deviate from a standard and be bitten.
Realistically security teams should be able to go above and beyond the strength of these certifications. In any case, ISO 27001 isn't really that great of a cert, it is only smaller less mature organisations that flash ISO 27001 as anything worth seeing.
Spot on at the end there
