Designing Luna HSM high availability for a CyberArk primary and DR vault pair

CyberArk’s DR story looks tidy on the whiteboard. PADR replicates the vault database to a satellite vault at the DR site, failover promotes it, and the business keeps retrieving credentials while the primary data centre is dark. Then someone moves the server key into a Luna HSM — which is the right call for a regulated environment — and the tidy story grows a dependency that PADR knows nothing about. The DR vault now needs a working, authorised path to the same key material, on an HSM at the DR site, before it can decrypt a single safe. Get the Luna side of that wrong and your DR vault is a perfect, current, fully replicated copy of data it cannot read.

This chapter is about designing the Luna high-availability layer underneath a CyberArk primary + DR vault pair: where the key material lives, how it replicates, where the HA group boundary sits relative to the site boundary, and what a DR exercise actually needs to prove. It assumes you know the basics from the earlier Luna HSM design and operational guide.

The trap: a replicated server key you can’t use

Start with what the server key actually does. CyberArk encrypts vault objects with object keys, wraps those with safe keys, and wraps the safe keys with the server key — a classic key-encryption-key hierarchy. When you run ChangeServerKeys against an HSM keyset, the server key is generated inside a Luna partition as a non-exportable key, and DBParm.ini is pointed at it with ServerKey=HSM#1. From that point, the vault cannot start, and cannot decrypt safe keys, without a live PKCS#11 session to a partition that holds that key.

Here’s the part that catches people. PADR replicates vault data and metadata; it deliberately does not replicate the server key, and it doesn’t copy DBParm.ini either. So the DR vault’s ability to read what PADR delivers depends entirely on the Luna layer replicating the server key to an HSM the DR vault can reach. And Luna will only clone key material between partitions that share a cloning domain — the domain string (or PED key) burned in at partition initialisation. If the DR-site HSM partitions were initialised with a different domain, no HA group, backup restore, or cloning operation will ever move that server key across. The domain decision is made once, at initialisation, and it is not changeable afterwards — that’s the whole subject of the cloning domains chapter.

So the non-negotiable design rule for a CyberArk primary + DR pair is: the partitions serving the primary vault and the partitions serving the DR vault must share a cloning domain, decided and recorded before anyone runs ChangeServerKeys. On firmware 7.8+ with Luna HSM Client 10.5+, extended domain management lets a partition carry up to three domains, which gives you some room to bridge estates — but the common-domain requirement still holds; members of an HA group need at least one domain in common.

Topology option 1: one HA group spanning both sites

The simplest mental model: a single Luna HA group whose members live in both data centres — say two HSMs at the primary site and one or two at DR — with both vault servers registered as clients of the same virtual slot. As covered in the HA chapter, what an HA group actually replicates is every key object in the member partitions, synchronously at creation time: when ChangeServerKeys generates the server key on the primary member, the client replicates it to every member — including the DR-site HSMs — before reporting success.

The attraction is that replication is automatic and continuous; there is no separate “sync the DR HSM” procedure to forget. The costs are operational:

• Latency bias. The Luna client schedules operations towards low-latency members, so the DR-site HSMs mostly idle — fine for this workload, but it means your DR HSMs are never exercised by production traffic and problems hide until failover.
• WAN sensitivity. Failover between members triggers on a roughly 20-second timeout, with health-check heartbeats on the order of every 10 seconds. A flapping inter-site link can push the group into repeated member recovery cycles.
• One client configuration to protect. The HA group definition lives in the client’s configuration on each vault server. Because PADR doesn’t replicate DBParm.ini or the Luna client config, the DR vault’s copy is maintained by hand — and drifts by hand.

If you take this route, consider configuring the DR-site members as standby members: they replicate all objects but serve no traffic unless every active member is gone, which is exactly the DR semantic you want. And enable HA-only mode on both vault servers so the application can never bind to an individual physical slot and quietly create a key that doesn’t replicate.

Topology option 2: per-site HA groups, same cloning domain

The alternative keeps the HA group boundary inside the site boundary: the primary vault uses an HA group of primary-site HSMs; the DR vault uses a separate HA group (or single partition) of DR-site HSMs. Key material crosses the site boundary not through HA replication but through a deliberate transfer — cloning the partition contents or restoring from a Luna backup HSM into the DR partitions. Because every partition shares the cloning domain, this is a supported, verifiable operation.

This buys you isolation: an HSM fault, client misconfiguration, or WAN event at one site cannot ripple into the other site’s HSM service. It costs you a procedure: every time the server key changes — which for CyberArk means every deliberate ChangeServerKeys run, not daily churn — someone must replicate the new key to the DR partitions and verify it landed, before the next DR test or real failover. The CyberArk workload makes this tractable because the key inventory is tiny and changes rarely; this is not a PKI issuing thousands of keys a day.

In federal and regulated-PII environments we generally see the per-site pattern favoured, for the same reason IRAP assessors like it: the movement of key material between sites is an auditable, ceremonied event rather than an implicit property of a client configuration file. But both topologies are defensible. What is not defensible is the accidental third topology: per-site HSMs initialised with per-site domains, discovered at the first DR test.

Where the HA boundary sits decides your failure modes

It’s worth being explicit about the trade, because it determines who gets paged for what:

	HA group spans sites	Per-site groups, cloned domain
Server key reaches DR	Automatically, at creation	By procedure, after each key change
DR HSM health visibility	Poor (idle members)	Good (DR vault exercises them)
WAN flap impact	Member recovery churn on both sides	None across sites
Failure blast radius	One group, shared fate	Contained per site
Audit story for key movement	Implicit in client config	Explicit ceremony + record

Registering the DR vault as an NTLS client

Whichever topology you choose, the DR vault server is a full Luna client in its own right: its own Luna HSM Client install, its own certificate exchange, its own registration on every HSM it may need during a failover. The trust model behind that registration — and when you’d choose STC over NTLS for it — is its own chapter; the mechanics on the appliance side look like this (lunash, Luna Network HSM 7.x):

lunash:> client register -client dr-vault01 -ip 10.60.20.15
lunash:> client assignpartition -client dr-vault01 -partition CYBERARK
lunash:> client show -client dr-vault01

Then verify from the DR vault server itself that the partition is visible and the connection healthy (on the client, vtl verify and lunacm’s slot list are your friends), and confirm the DR vault’s DBParm.ini carries the HSM parameters that PADR will never copy for you: ServerKey=HSM#N, the PKCS#11 provider path, and the encrypted HSM PIN created on that machine. Treat the DR vault’s HSM client configuration as a controlled artefact with its own change record, because nothing replicates it and nothing warns you when it drifts.

What a DR exercise actually has to prove

A DR test that stops at “PADR replication is green and the DR vault service starts as satellite” proves almost nothing about the HSM layer, because the satellite isn’t decrypting production safes. The test that matters promotes the DR vault and makes it do cryptographic work:

• Fail over properly (in a controlled window): promote the DR vault and confirm it starts with ServerKey=HSM#N against the DR-site partition — this is the moment a wrong cloning domain announces itself.
• Retrieve a credential from a safe that was created after the last HSM key sync, not just an old one — this catches the per-site topology’s stale-copy failure mode.
• Run a CPM change and a PSM session through the promoted vault, so the whole chain exercises the DR HSM path, not just a console login.
• Pull one DR-site HSM mid-test and confirm the client fails over inside the group (or degrades as designed if you run a single DR partition).
• Record timings — how long the vault takes to start against the DR HSM, how long first credential retrieval takes — because these become your runbook expectations.

And test failback. Re-syncing the primary from the promoted DR vault is a CyberArk procedure, but the HSM question — “is the primary-site partition still holding the current server key?” — belongs on the same checklist.

---

Where this leaves you

You now have a primary + DR vault pair whose key material provably exists at both sites — and a new problem: a composite system (vault, PADR, Luna client, HA group, WAN) whose combined failure modes nobody has actually drilled. What does the vault do when the HSM is unreachable at startup versus mid-flight? What do users see, and what should the NOC do at 2am? That failure drill is the next chapter. The full series lives at The Luna Field Guide.