Luna HSM activation and auto-activation: running unattended services on a PED-authenticated HSM

PED authentication is the reason you bought a Luna Network HSM, and it is also the thing that will take your services down at 2am if you configure the partition policies wrong. The PED exists to keep a human in the loop: nobody logs in to a PED-authenticated partition without physically presenting a PED key. That is exactly the property an assessor wants to see, and exactly the property an unattended application server cannot live with. Your CA, your code-signing pipeline, your identity-verification platform — none of them can push a black key into a PED slot at boot time.

Luna resolves this tension with two partition policies: activation and auto-activation. Get them right and your services ride through reboots and short outages without a human anywhere near the data centre. Get them wrong — or assume they do more than they do — and a Sunday power event turns into a multi-hour outage that ends with someone driving to a secure facility with a key wallet. This chapter covers what the policies actually do, precisely what survives a reboot versus a power pull, how the failure plays out in the field, and how Remote PED changes the operational calculus. It builds on the platform decisions covered in our Luna HSM design and operational guide.

Why PED authentication and unattended servers are in tension

On a PED-authenticated partition (Thales now calls this “multifactor quorum-authenticated” in current documentation — same mechanism, new name), every role login requires the matching PED key: blue for the Partition Security Officer, black for the Crypto Officer, grey for the Crypto User. The Crypto Officer black key is the one that matters operationally, because the CO (or CU) credential is what your applications authenticate under to perform crypto operations.

An application server talking to the HSM over NTLS can supply a text credential — a challenge secret — but on a PED-authenticated partition that challenge secret is only accepted while the role’s PED key material is cached inside the HSM. No cache, no login, regardless of whether the application has the correct challenge secret. The cache is the whole game. Activation and auto-activation are simply the policies that govern when that cache exists and how long it survives.

For Australian federal and regulated-PII environments this is not an academic distinction. The reason you specified PED authentication in the first place — ISM expectations around multi-factor control of cryptographic material, IRAP assessor scrutiny of who can touch keys protecting identity-verification or police-check-class data — is the same reason you cannot simply leave a PED plugged in and a key inserted as a workaround. The policies are the sanctioned mechanism; understand them properly.

Activation and auto-activation: partition policies 22 and 23

Two partition policies control credential caching, and they are set per partition by the Partition Security Officer:

• Policy 22: Allow activation. When on, a successful Crypto Officer (or Crypto User) login with the black or grey PED key caches that role’s PED secret inside the HSM. From that point, applications authenticate with the role’s challenge secret alone — no PED interaction — for as long as the cache persists.
• Policy 23: Allow auto-activation. When on (in addition to policy 22), the cached secret is held in battery-backed memory, so the cache survives a reboot or a power outage of up to roughly two hours. Without it, the cache lives only as long as the HSM stays powered.

The dependency runs one way: policy 23 does nothing without policy 22. If the Partition SO later disables policy 22, auto-activation stops too, even though policy 23 still reads as enabled; re-enable 22 and auto-activation resumes. Activation itself is not destructive to enable or disable, which is why it is one of the few policies you can safely change on a production partition — though you should still treat any policy change as a controlled change with a rollback note.

One more piece completes the picture: the challenge secret. The Partition SO creates the CO challenge secret, and the CO can change it after first login. That secret is what goes into your application’s Luna client configuration. It is worth stating plainly: on a PED-authenticated partition the challenge secret is a second factor bound to the cached PED material, not a replacement for it. On current appliance software (7.9.0+ with Luna HSM Client 10.8.0+) the character rules for these secrets are enforced more strictly — a detail worth checking before you standardise a secret format across environments.

What survives a reboot — and what survives a power pull

This is where assumptions kill availability. The behaviour differs by event, and the differences are exactly the ones that matter during an incident:

Event	Activation only (policy 22)	Activation + auto-activation (22 + 23)
Application reconnects, HSM stays up	Cache intact — service resumes	Cache intact — service resumes
Appliance reboot / maintenance restart	Cache lost — black key required	Cache restored — service resumes
Power outage under ~2 hours	Cache lost — black key required	Cache restored — service resumes
Power outage over ~2 hours	Cache lost — black key required	Cache lost — black key required
Tamper event	Cache zeroised, activation disabled	Cache zeroised, activation disabled

Three things to internalise from that table. First, activation without auto-activation buys you almost nothing for resilience: any restart of the appliance, planned or not, drops the cache. If you enable 22, enable 23 — there are few defensible reasons to run one without the other on a service partition.

Second, the roughly-two-hour window on auto-activation is a battery, not a policy setting. It is the design behaviour of the battery-backed memory that holds the cached secret while the appliance is dark. You cannot extend it by configuration. A dual-feed data centre with generators will essentially never hit it; a comms room with a single UPS absolutely can.

Third, a tamper event overrides everything. Tamper zeroises the cached PED material and disables activation and auto-activation until the tamper is cleared and the partition is reactivated. In practice this means an over-enthusiastic chassis intrusion during rack work can produce the same outage as a long power cut — worth remembering when you schedule physical maintenance in the same window as anything else.

The Sunday outage: how this fails in the field

Here is the pattern we see repeatedly in regulated environments — a composite drawn from community war stories and support-forum post-mortems rather than any single engagement, but it will be uncomfortably familiar to anyone who has run PED-authenticated Luna estates.

A site power event hits early on a Sunday morning — a failed transfer switch, a substation fault, scheduled electrical work that overran. The UPS carries the rack for forty minutes, then everything goes dark. Power is restored four hours later. The Luna appliance boots cleanly, NTLS comes up, the network is fine. But four hours exceeds the auto-activation window, so the partitions come back deactivated. Every dependent application — the issuing CA, the signing service, the tokenisation layer in front of the PII store — reconnects, presents its challenge secret, and is refused. From the application side this looks like an authentication failure, so the first hour of the incident is burned on the wrong hypothesis: password rotation, client config, certificate expiry.

Eventually someone realises the partitions need reactivation, which requires a Crypto Officer login with the black PED key. And now the real outage begins: the black keys are in a safe, the safe is at the secure facility, the facility requires two-person access, and the people on the access list are not the people on call. On a Sunday. In a federal deployment with an interstate data centre, the community’s reported experience turns “the HSM is fine” into six to eight hours of service outage — all of it spent on logistics, none of it on technology.

The uncomfortable part: every component behaved exactly as designed. The design was never tested against the question “who can present a black key at 6am on a Sunday, and how long does it take them to get there?”

Remote PED: reactivation without a site visit

Remote PED is the operational answer to that scenario. Instead of the PED hanging off the appliance, a PED in remote mode connects by USB to a workstation running the pedserver service; the appliance’s built-in pedclient establishes an encrypted, mutually-authenticated path to it across the network. The trust anchor is a Remote PED Vector (RPV) held on an orange PED key, imprinted on both the HSM and the remote PED, so only a PED holding the matching vector can serve authentication to that HSM.

Operationally, this changes the black-key problem from “who can get to the data centre” to “who has custody of a PED, a workstation, and the keys” — which can be a security officer working from a hardened laptop kit at home, or a manned SOC location in a different city from the appliance. After the power event above, reactivation becomes: start pedserver, connect from the appliance over SSH, present the orange key then the black key at the remote PED, and log the CO back in. Minutes, not hours, and no facility access required.

Two caveats stop Remote PED being a silver bullet. First, it must be set up in advance — the RPV has to exist and the orange keys have to be cut and distributed before the incident, and the pedserver workstation needs network reachability to the appliance (default port 1503, direction depending on which end initiates). Second, it moves rather than removes the custody problem: your remote PED kits, orange keys and black keys now need the same custody discipline as the safe they replaced, and your IRAP assessor will expect to see that documented. We cover the full setup, step by step, in the companion how-to in The Luna Field Guide.

Runbook implications for on-call

If a PED-authenticated Luna sits under production services, your on-call documentation needs to answer these before the incident, not during it:

• Recognition. “Applications failing CO authentication after an HSM restart” should route to “check partition activation state” as a first-line diagnostic, not a last resort. An hour of misdiagnosis is the most preventable part of the composite above.
• Key custody and hours. Named custodians for black and orange keys, with after-hours contact and realistic travel or remote-connect times. If the answer is “the safe opens Monday”, write that down and make the business own it.
• Reactivation procedure. The exact command sequence, per partition, for both local PED and Remote PED paths — tested, not aspirational.
• Dependency map. Which services die when each partition deactivates, and in what order they should be recovered once activation is restored. HA pairs change the maths — a surviving member keeps servicing requests — but only if your HA design actually covers the failed site.
• Power reality. Know your actual UPS runtime and generator posture against the two-hour window, per site. This is a one-line risk statement that most Luna deployments have never written.

None of this weakens the control story. Auto-activation with PED authentication is a deliberate, documented trade — the PED ceremony still gates the initial caching of credentials, physical tamper still zeroises them — and it is a far easier position to defend to an assessor than the workarounds teams invent under outage pressure.

---

Where this leaves you

You now know what keeps a PED-authenticated partition serving crypto without a human in the room, and exactly which events put a black key between you and recovery. The next problem is the layer above: even with partitions activated, your client connections — NTLS certificates, STC identities, HA group membership — are the next thing to break in a DR event, and they fail in quieter, more confusing ways. That is the next chapter. For the rest of the series, start at The Luna Field Guide.