In my time in enterprise-level support, I was often asked how to reset the master password on various devices after the existing password had been lost for one reason or another.
Most people requesting that information were surprised when I asked for an independent person to validate both the need for the reset and that the information should be given to the requester. It is not a common question, but it should be.
My mantra is that it is better to delay legitimate access to a computing asset, than to facilitate an unauthorized access.
Support organizations should plan for how they are going to obtain independent authentication and authorization to release all kinds of sensitive information. They also need to train their staff that giving out such sensitive information without adequate validation could be very harmful to all involved.
When I say independent, what I mean is: an entirely separate and verifiable path to ensure that I am not simply talking to a potential co-conspirator of the person asking for the sensitive data. If Joe is asking, you cannot take his word for it that Jane has the authority. In one organization I coached responders that they should go through the account technical sales reps to validate need and authority for such sensitive information.
If, as a product manufacturer, you have master password reset information in an FAQ on your website, please consider making it internal use only, and changing the product in the next release so that the already broadcast information is no longer valid in subsequent products. Also, put warnings on the now-internal-use-only password reset pages for support to delay supplying the information while they develop the independent validation of need and authorization to change the password.
The sources of potential breach are many and varied. Let’s all work together to close off as many of those sources as possible.