Summary

  • Thales announced UK-hosted Luna Cloud HSM availability on 14 September, saying keys will be generated, stored, used, backed up and destroyed in the UK.
  • Two UK Data Protection on Demand instances support its stated availability and disaster-recovery offer. Their location is not independent evidence of a tested restore, a preserved earlier key state or complete application compliance.

A key can stay in the right country and still be unavailable when an application needs it. Conversely, keeping a cryptographic service running does not necessarily preserve the earlier state needed after a mistake. Thales's new UK-hosted Luna Cloud HSM offer makes the geographic side of those questions more explicit.

The company announced the service on 14 September through its Data Protection on Demand marketplace. Its commitment covers more than the place where a key is actively used: generation, storage, use, backup and destruction will all take place in the UK. Thales says two UK-based instances will provide high availability and disaster recovery within that boundary.

That is a more useful description than a bare “hosted in the UK” label. A customer with a location requirement needs to know where copies used for recovery sit, not just where routine operations happen. But the announcement remains a supplier statement about the service. It is not a published recovery exercise or evidence that a named customer has satisfied a regulator.

The asset being located is the key service

An HSM, or hardware security module, protects cryptographic keys and performs operations with them. The cloud offer lets customers use those capabilities without deploying and managing dedicated HSM infrastructure for the service. Thales positions the new option for organisations including regulated businesses and the public sector.

A key's location should not be confused with the location of everything it protects. The release does not establish that an application's data, logs, client software or administrators all reside in the UK. Nor does it turn a cloud or hybrid application into an entirely domestic operating environment.

Thales itself says sovereignty is not only about physical location; access, control and operational requirements also matter. The meaningful new product choice is therefore a specified geographic boundary around the managed key lifecycle, not a universal compliance certificate.

The announcement does not disclose a price, customer adoption count or detailed allocation of recovery responsibilities. It also does not provide precise recovery-time or recovery-point commitments, a historical-backup retention schedule or the failure-domain architecture behind the two instances. Two instances should not silently become two independently verified regions or a promise of survival under every UK-wide disruption.

Availability and recoverable history answer different questions

Thales's general Luna documentation explains why the distinction is material. Its high-availability guide describes standby members that receive replicated current objects. Those members do not, by that fact alone, preserve multiple generations of earlier partition contents. When earlier states must be retained, the guide points to intentional backups.

This is general product guidance, not a technical description of the newly announced UK managed service. It neither proves that the two UK instances use that client-managed arrangement nor shows that the new service lacks historical backups. It does identify a question that an instance count cannot answer: which valid state can a customer restore?

The separate Luna Cloud HSM backup guide calls for a documented plan covering what is backed up, how often, where it is kept, who can perform recovery and how frequently that process is exercised. It recommends recovery exercises at least every six months. That is the supplier's general practice recommendation, not a report that a UK-service exercise has taken place or a new regulatory obligation.

The same guide describes implementations using dedicated backup HSMs, with matching domains and the required credentials. Those options do not mean every buyer of the new managed offer must purchase backup hardware. They show why the scope of an actual deployment and its responsibilities need to be specified rather than inferred from the family name.

A boundary to buy, and a recovery plan to agree

The UK announcement gives a buyer a concrete location commitment to examine. The next useful commercial information would connect that commitment to the service's actual recovery terms: covered incidents, available backup history, restoration objectives and the people authorised to act.

If a customer adds its own integrations or recovery components, their responsibilities and location requirements also need agreement. That is a deployment question, not an allegation that the new service permits keys to leave the UK.

The distinction changes what should count as procurement evidence. A statement about where operations occur answers one part. A tested, contractually scoped route back to usable cryptographic operations answers another. Neither should be used as a substitute for the other.

Sources