[timmclean]

Is there a reason why they couldn't split the load across multiple HSM? For something so sensitive I would've expected a design where one or more root/master keys (held in HSM) are periodically used to sign certificates for temporary keys (which are also held in HSM). The HSMs with the temporary keys would handle the production traffic. As long as the verification process can validate a certificate chain, then this design should allow them to scale to as many HSMs as are needed to handle the load...

[toast0]

HSM are expensive, the performance is bad, and administration is a pain. They're almost certainly running many clusters of their auth servers around the world, and would need significant capacity at all the locations, in case traffic shifts.

It's probably a better idea to pursue short lived private keys, rather than HSMs. If the timeline is accurate, the key was saved in a crash dump in 2021 and used for evil in 2023, monthly or quarterly rotation would have made the key useless in the two year period.

A certificate chain is a little too long to include in access tokens, IMHO, but I don't know how Microsoft's auth systems work.

[twisteriffic]

According to https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...

The key expired in April 2021. Short lived keys only work if you actually check for expiry, which it appears they weren't doing.