Topic starter
30/09/2026 4:59 pm
TL;DR: A 20-year relationship with Entrust nShield HSMs underpins cryptographic infrastructure across banking, government, digital identity and enterprise environments, with deployments spanning certificate authorities, code signing, cloud applications, remote signing and database encryption, according to Verisec International. The real governance issue is that hardware alone does not create trust; durable security depends on how HSMs are operated, integrated and supported across their full lifecycle.
Editorial analysis by NHI Mgmt Group, based on content published by Verisec International: “Two decades of progress. One direction forward.”.
Key questions
Q: How should teams govern HSM-backed cryptographic services in critical environments?
A: Treat HSM-backed services as part of the identity and trust control plane, not as isolated appliances.
Q: Why is HSM trust not created by hardware alone?
A: Because hardware protects keys, but trust also depends on enrollment, access control, recovery, monitoring and support.
Q: What are the signs that an HSM programme is becoming operationally fragile?
A: Common warning signs include a small number of staff holding all configuration knowledge, unclear ownership for certificate and key lifecycles, recovery steps that are rarely tested, and integrations that only one team understands.
Practitioner guidance
- Map HSMs to governed service boundaries Document which identities, applications and trust services each HSM instance supports, then assign explicit operational ownership for enrollment, access, change and recovery.
- Separate lifecycle control by use case Treat certificate authorities, code signing, remote signing and database encryption as distinct control domains with separate rotation, revocation and recovery requirements.
- Test failover and recovery as security controls Validate that authentication and signing services continue through HSM outage, cluster failure and maintenance windows, not just during nominal operation.
Bottom line: HSMs protect keys, but they do not on their own create trustworthy cryptographic infrastructure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/09/2026 5:00 pm
Hardware assurance is only the starting point, not the trust model. This article reinforces a persistent governance mistake: organisations often equate tamper-resistant hardware with end-to-end cryptographic trust. That assumption fails because trust is created by the operating model around the device, including lifecycle control, integration discipline and recovery readiness. The implication is that HSM programmes must be judged as services with governance obligations, not as appliances on a shelf.
A question worth separating out:
Q: What should organisations do when cryptographic services underpin critical identity flows?
A: They should define explicit service ownership, test outage recovery, and document how signing or authentication continues during maintenance or failure. That applies especially when HSM-backed services support eID, remote signing or certificate authorities, because identity assurance can fail even if the cryptographic device remains intact.
👉 Read our full editorial: Cryptographic infrastructure depends on HSM expertise, not just hardware