Luna HSM cloning domains: the decision you can’t undo

Every Thales Luna HSM deployment contains one decision that cannot be revisited, reversed, or repaired: the cloning domain. It is set in the first minutes of a partition’s life, usually during a key ceremony when everyone is watching the label and the Security Officer credential instead. Get it right and nobody ever thinks about it again. Get it wrong — or inherit an estate where nobody wrote it down — and you discover that backup, restore, high availability and hardware migration are all downstream of a secret you no longer control.

This chapter of the Luna Field Guide explains what the cloning domain actually is, what it permanently determines, why the “inherited HSM with an unknown domain” scenario ends the way it always ends, and how to design domains properly before you run your first hsm init. If you want the full deployment context first, start with our comprehensive Luna HSM design and operational guide.

What a cloning domain actually is

The cloning domain is a shared secret that acts as a second layer of encryption around every object that leaves a Luna partition. When keys are cloned — and “cloning” here covers backup, restore, and HA replication, not just the literal clone command — the source and destination each prove knowledge of the same domain secret before any material moves. No matching domain, no transfer. The operation simply fails.

How the secret exists depends on your authentication model:

• Password-authenticated HSMs — the domain is a text string (1–128 characters) supplied at initialisation, either on the command line or at a prompt. It behaves like a password that is never asked for again in daily operation, which is exactly why it gets lost.
• PED-authenticated (multifactor quorum) HSMs — the domain secret is generated by the Luna PED and imprinted on a red PED key (or an M-of-N split across several red keys). The secret never exists as text anywhere. The red key is the domain.

One nuance that trips up people reading older documentation: on Luna 7, the HSM-level domain you set during hsm init on a password-authenticated appliance is a legacy field — Thales’ own documentation notes it must be set but has no practical function on Luna 7. The domains that matter operationally are the ones set on each application partition at partition initialisation. On PED-authenticated units the HSM-level red key still protects the admin partition, and the partition-level red keys protect application partitions. Plan for both.

What the domain permanently decides

The cloning domain is the membership card for every replication relationship a partition will ever have. Concretely, two partitions can only exchange key material if their domains match — and that single rule cascades into everything that makes an HSM estate operable:

• High availability. Every member partition in a Luna HA group must be initialised with the same cloning domain. Same auth method, same domain, or the partition can never join the group.
• Backup. A backup HSM partition receives objects via cloning. The backup target must share the source partition’s domain, or the backup fails.
• Restore. You can restore a backup to the original partition or to any other partition initialised with the same domain — and to nothing else. A backup made under domain A is unreadable by any partition in domain B, forever.
• Hardware refresh and DR builds. Standing up a replacement or DR appliance means initialising new partitions and cloning production material into them. If the new partitions can’t be initialised into the original domain, the material can’t follow.

Notice what’s on that list: essentially every operation you perform when something has gone wrong. The cloning domain is invisible on the good days and load-bearing on the bad ones.

The trap: you only get one chance to set it

Here is the property that makes this a chapter rather than a footnote: the initialisation procedure is the only opportunity to set a partition’s cloning domain. There is no provision in the product to change, reset, or recover a domain after the fact. Thales’ documentation is blunt about it — there is no way to change the cloning domain of a partition without reinitialising it, which destroys every object in that partition.

Compare that with the other secrets in the system. A lost Crypto Officer password can be reset by the Partition SO. A lost Partition SO credential is worse but survivable if the partition contents are cloneable elsewhere first. The domain sits in a different category: it is not an access credential, it is a property of the encrypted objects themselves. Nobody — not Thales, not their support organisation — can reverse it. Their own guidance on lost domain secrets says it plainly: if you have not kept a secured record of the domain, or the red PED keys for a PED-authenticated unit, you are out of luck.

Two partial escape hatches exist, and it’s worth being precise about their limits. First, keys whose policies permit wrapped export can leave a partition under a wrapping key regardless of domain — but in regulated environments the whole point is usually that private keys are non-exportable, so this rarely helps with the material you actually care about. Second, firmware 7.9.2 and newer supports assigning up to three cloning domains to a partition (“universal cloning”), which can bridge previously incompatible estates — including password-to-PED — going forward. Neither retrofits a domain onto an existing partition whose secret you don’t hold.

The inherited HSM with an unknown domain

This is a pattern we see repeatedly in regulated environments, and the same story circulates in operations forums and Thales support threads because it happens everywhere. The composite version goes like this.

An agency or regulated organisation has a pair of Luna Network HSMs that have run untouched for five or six years, anchoring a PKI or protecting an identity-data encryption hierarchy. The engineer who commissioned them has left. The runbook, if it exists, records the appliance IPs and the Crypto Officer password — because those are the things day-to-day operations needed. The applications authenticate happily. Everything works.

Then a trigger arrives: a hardware refresh, an IRAP assessment asking for evidence of tested restores, or a plan to finally add the DR site into HA. Someone tries to initialise a partition on the new unit into the existing domain — and discovers that nobody knows what the domain is. On a password-authenticated estate, the string was typed once in a ceremony years ago and never written down, or it’s in a sealed envelope that turns out to contain the SO password instead. On a PED-authenticated estate, there is a drawer of unlabelled iKeys and no record of which red key belongs to which partition, whether the domain was split M-of-N, or whether the key in hand is a duplicate or an orphan from a decommissioned unit.

The cruel part is that production keeps working the entire time. Signing works. Decryption works. The estate looks healthy on every dashboard. What has actually happened is that the organisation is one hardware failure away from permanent loss of key material, and has no way to prove otherwise — because every path that would prove it (backup, restore test, HA join) requires the domain they don’t have. And you cannot test your way to the answer by trial and error in any useful sense: on the password side you’d be guessing a string of up to 128 characters, and there is no command that displays the domain secret for comparison.

Why regenerate is the only honest path

When the domain is genuinely unknown, there is exactly one defensible plan, and it should be executed while the existing partitions are still alive and their operational credentials still work:

• Initialise fresh partitions (on the existing or new hardware) with a new, properly documented cloning domain.
• Regenerate keys into the new partitions and re-enrol every consuming application: reissue certificates from a new key pair, re-encrypt data under new data-protection keys, rotate whatever the old partition anchored.
• Run old and new in parallel through the cutover, because nothing can be cloned across the boundary.
• Only then decommission the old partitions.

That is a key rotation project, not a copy job — for a CA hierarchy it may mean a subordinate reissue; for an encryption estate it means a re-encryption campaign. Which is exactly why the temptation to defer is so strong, and exactly why deferring is wrong: the migration is only possible while the old partition still works. Every month of deferral is a month of unhedged single-point-of-failure risk on hardware that is, by definition of the scenario, already old. In ISM terms, you currently cannot meet your own key-recovery and availability commitments, and an assessor who asks for a tested restore will surface that in writing.

Designing domains before first init

All of the above is avoidable with about an hour of planning before anyone touches a console. The domain layout is an architecture decision, and it should be written down and approved before the ceremony, not improvised at the prompt.

Draw the replication map first

List every partition you intend to create across production, DR and backup HSMs, and draw the arrows: which partitions must HA together, which backup device must be able to receive which partitions, where restores must be possible. Every connected set of arrows is one domain. A typical pattern for an Australian federal deployment — two production units in HA, a DR unit, and a backup HSM — is a single domain per application workload spanning its partitions on all four devices, with separate workloads (say, a CA and a database-encryption service) kept in separate domains so a compromise or ceremony error in one can never propagate to the other.

Decide the sharing boundary deliberately

A domain is a trust boundary: anything in it can, with the right credentials, receive your keys. Too many domains and you multiply ceremonies, red keys and custody records. Too few — one domain across the whole estate — and any partition anywhere can become a clone target for your most sensitive material. Match the boundary to data classification: partitions protecting police-check-class PII or identity-verification data should not share a domain with a general-purpose TLS partition merely because it was convenient on ceremony day.

Plan custody like the secret it is

For password-authenticated domains: generate a high-entropy string, seal it, store it in at least two geographically separated safes, and record its existence (not its value) in the key management plan. For PED-authenticated domains: decide before the ceremony how many red key copies exist, whether the domain is split M-of-N across multiple red keys for quorum control, who holds each, and how they are labelled — the red key is widely treated as the single most important PED key to protect, and an unlabelled red key is a future incident. Either way, the domain record belongs in your key ceremony evidence, which your IRAP assessor will ask for.

Password-auth vs PED-auth domains

The two authentication models handle domains differently enough that the choice shapes your ceremony and custody design:

	Password-authenticated	PED-authenticated (multifactor quorum)
Domain form	Text string, 1–128 characters	Secret imprinted on red PED key(s)
Set during	hsm init / partition init with -domain	PED prompts during initialisation; red key created or reused
Reusable across partitions	Type the same string at the next init	Present the existing red key and choose to reuse it
Custody artefact	Sealed written record	The physical red key(s), optionally split M-of-N
Failure mode	String never recorded, or recorded wrongly	Keys unlabelled, lost, or quorum holders unavailable
Cross-compatibility	Password-auth and PED-auth partitions cannot clone to each other (prior to universal cloning on firmware 7.9.2+)

Note that cross-compatibility row: an HA group also requires all members to use the same authentication method, so a mixed estate isn’t just awkward — it partitions your replication topology. If you’re running privileged access tooling against the same estate, the multi-site considerations in our CyberArk multi-domain deployment guide pair naturally with this planning exercise.

---

Where this leaves you

You now know why the domain must be designed before the first init, and what it costs when it isn’t. But a correct domain only makes replication possible — it doesn’t make it correct. HA groups have their own quiet failure modes: members that silently stop synchronising, policy mismatches that block a join, and a client-side group config that isn’t stored where you think it is. That’s the next chapter. The full series lives at The Luna Field Guide.