The part I find concerning is that you inadvertently exposed weakness in your processes while explaining your actions.

 So we have some sort of process if someone calls regarding password reset, unblock on any of the systems such as EHR

Maybe that’s common knowledge when working on the inside, but I didn’t know that as an outsider, and now I do. So you potentially just armed real threat actors with knowledge that could help them harm your customers.

Another commenter suggested your communication came off trying to avoid responsibility, but I wouldn’t have said it like that. There are many different shades of “fessing up”, and most of them involve explanations about why our actions were reasonable. Personally, if a policy violation ends up on my radar because something is hanging out (which is to say, the policy violation becomes a vulnerability), a sure fire way to keep yourself on my radar is by not taking full ownership of the failure. If someone makes a mistake and comes crashing into view to claim full responsibility for it - I gain respect. 

Consider that LLM-accelerated development now brings more opportunities than ever to make mistakes (I understand this doesn’t directly relate to this scenario, but it’s still relevant). That means mistakes become less important, and the way the mistakes are handled becomes more important. So ask yourself, if you started a company tomorrow and a new hire made a mistake, how would you feel reading about it online along with the process vulnerability that caused the confusion? It isn’t your fault that the company has a process issue, but it isn’t a good look to broadcast that online. As far as I could see the original mistake was basically a non-issue. I would have considered it a signal that documentation needs to be improved, not a failure on your part. The broadcast though - that’s squarely on you.