I am ambivalent about using HSMs to protect password databases, because if you're going to do that, you might as well simply introduce a minimalized authentication server (ie: something with an <AUTHENTICATE(user, password) bool> interface). It'll have approximately the same attack surface, it actually helps your architecture in other ways, and it precludes attackers from getting hashes in the first place (at least, the same way an HSM does with the HMAC key).
A Go, Rust, or (minimal, non-framework) Java authentication server speaking HTTPS to solely that AuthN interface and sharing no database with anything else is extremely unlikely to be part of any realistic "kill chain"; it'll be among the last things on your network compromised.
Meanwhile: you get to stick with technology you fully understand and can manage (simple HTTP application servers and a decent password hash) and monitor.
HSMs have a lot of uses elsewhere in secure architectures, but the password storage use case is overblown.
A Go, Rust, or (minimal, non-framework) Java authentication server speaking HTTPS to solely that AuthN interface and sharing no database with anything else is extremely unlikely to be part of any realistic "kill chain"; it'll be among the last things on your network compromised.
Meanwhile: you get to stick with technology you fully understand and can manage (simple HTTP application servers and a decent password hash) and monitor.
HSMs have a lot of uses elsewhere in secure architectures, but the password storage use case is overblown.