We use an HSM" is the answer we hear most often when we ask an OEM's security team how they protect their signing keys. It is meant to close the question. In our experience, it opens a longer one.
An HSM is the right foundation. Tamper resistant boundary, cryptographic operations confined inside a certified module, private key material that never touches general-purpose compute. All of that is correct and it matters. What governs it is something else entirely. That something else is where the real gaps tend to appear.
What we typically find in an OEM signing estate is capable hardware sitting inside a governance gap. The HSM is there. The policies around it are sparse, assumed rather than documented, or inherited from a vendor setup guide. Key custodians, the individuals authorised to access or operate on sensitive key material, exist but their responsibilities have never been formally defined. Ceremonies, the procedures that authorise sensitive key operations, happen informally or not at all. The audit log exists because the HSM generates one, but nobody has specified what to do with it and in some cases nobody is routinely reading it.
This is a pattern we see often and it is understandable. It is what happens when a procurement decision gets treated as a security decision. Buying the hardware is straightforward. Building the governance layer that makes the hardware meaningful is where the real work begins and also where the greatest opportunity for improvement usually lies.
The governance layer has four components we look for whenever we assess a signing estate.
-
The first is policy
. A written, version controlled document that specifies what the HSM may be used for, under what conditions and by whom. Not a vendor reference guide but an organisation specific document that has been reviewed and approved.
-
The second is key custody
. A formal model that names custodians, defines their authorities, requires dual control for sensitive operations and documents what happens when a custodian leaves the organisation. Key custodianship should be a defined role, not an informal arrangement assumed by whoever happens to be closest to the hardware.
-
The third is evidence architecture
. The set of artefacts that prove, after the fact, that every sensitive operation was authorised, performed correctly and recorded accurately. An HSM log is a start. An evidence architecture specifies retention, integrity, chain of custody and what the evidence is expected to demonstrate in the event of an audit or an incident.
-
The fourth is lifecycle
. What happens when a key expires, when a key is compromised, when a custodian is unavailable or when the HSM itself reaches end of support. Lifecycle decisions made reactively, because the key has already expired or the incident is already in progress, are rarely the right ones. Having those procedures defined in advance changes the outcome significantly.
When KT Secure worked with a Tier 1 British automotive manufacturer to establish their Cryptographic Centre of Excellence, the HSM infrastructure was largely in place before we arrived. Our work was almost entirely in the governance layer. Writing the policies, formalising the key custodianship model, designing the evidence architecture and establishing the lifecycle procedures that would hold up against regulatory scrutiny and stand up to operational reality.
The HSM gave them the capability. The governance gave them the assurance.
So when a team tells us they use an HSM, we do not question the decision. We ask who the custodians are, what the policy says, what their evidence architecture looks like and when they last walked through the lifecycle procedures. Those questions usually tell us more about the real state of cryptographic security than the hardware specification ever could.
