How to provision Luna HSM partitions and roles cleanly

This is the hands-on companion to our chapter on Luna HSM partition strategy. You’ve decided how many partitions the estate needs and what each is for; this walkthrough provisions them so they still make sense in three years — named consistently, with roles held by the right people, policies set on purpose rather than left at whatever the defaults happened to be, and the whole thing written down. The steps assume a Luna Network HSM 7 appliance, Luna HSM Client 10.x, lunash access over SSH, and lunacm on a registered client. Command syntax is drawn from the Luna 7.x documentation on thalesdocs.com; details that shift between versions are flagged inline, and anything we could not pin to a specific document this session is described generically.

Step 1: Fix the naming convention before creating anything

Partition names outlive intentions. LunaSH accepts names of 1–32 characters, and a rename later is not a casual operation once clients, HA groups and runbooks reference the name — so pick a convention that survives growth now. A pattern that works in practice:

<consumer>-<environment>-<ordinal>

adcs-issuing-prod-01
cyberark-vault-prod-01
codesign-prod-01
adcs-issuing-uat-01

Three rules make it durable. Encode the consumer and environment, never the appliance — the same partition label will exist on both HA members, and a name like hsm1-part3 becomes a lie the day it is cloned to hsm2. Keep an ordinal even if you only have one partition per consumer, because “one” is a temporary condition. And use lowercase with hyphens only: the character set allows more, but every script, register and ticket that ever references the name will thank you for boring.

Step 2: Create the partition in lunash

Partition creation is an HSM Security Officer operation on the appliance. Over SSH, log in as the HSM SO and create the partition:

lunash:> hsm login
lunash:> partition create -partition adcs-issuing-prod-01
lunash:> partition show

By default the appliance divides free space evenly; if a partition needs a specific object capacity you can pass a -size value in bytes at creation. Record the partition serial number from partition show — client assignment, HA configuration and the register in Step 6 all key off it. Repeat for each partition in your map, then log the HSM SO out. If you are building the estate’s first partition and the HSM itself is not yet initialised, stop and work through the appliance-level setup in the Luna HSM design and operational guide first.

Step 3: Initialise the partition and its Security Officer

Everything from here happens in lunacm from a registered client — the appliance hands the partition over, and its internal roles are none of the appliance’s business. Select the new partition’s slot and initialise it:

lunacm:> slot set -slot <slot_number>
lunacm:> partition init -label adcs-issuing-prod-01

Initialisation creates the Partition Security Officer (PO) and sets the partition’s cloning domain. On a password-authenticated partition you will be prompted for (or can supply) the PO password and a domain string; on a PED-authenticated partition the blue key and red domain key are imprinted at the PED instead. Two things deserve deliberate choices here, not reflexes: keep the label identical to the lunash partition name (nothing enforces this; future-you enforces it), and choose the cloning domain according to your HA and backup design — partitions can only clone within a shared domain, and the domain cannot be changed later without re-initialising. If that decision hasn’t been made yet, make it before this step, not after.

Step 4: Initialise the Crypto Officer and Crypto User roles

The partition’s working roles follow a strict chain: the PO creates the Crypto Officer (CO), and the CO — not the PO — creates the optional read-only Crypto User (CU):

lunacm:> role login -name po
lunacm:> role init -name co
lunacm:> role logout

lunacm:> role login -name co
lunacm:> role init -name cu
lunacm:> role logout

On PED-authenticated partitions the CO is imprinted on a black key and the CU on a grey key; on password partitions each role init sets an initial credential the role-holder should change at first login. Initialise the CU whenever the consuming application only ever signs, verifies, encrypts or decrypts with existing keys — a CU session cannot generate, delete or wrap objects, which is exactly the least privilege you want for a service account. Skip it only where the application genuinely manages its own key lifecycle (CyberArk and ADCS both do).

Now the part that outlasts the commands: who holds what. The PO credential is a governance instrument — it changes policies and can wipe the partition — and belongs with your security custodians, under the same two-person discipline as the rest of your ceremony material. The CO credential belongs to the consuming system’s owning team, because it is effectively that application’s identity. The CU credential, where used, is the one that goes into application configuration. If PO and CO end up with the same person, you have rebuilt the audit finding from the strategy chapter with extra steps. The custody model, witness requirements and ISM rationale are covered properly in our chapter on key ceremonies and separation of duties — run role initialisation as a ceremony, with the custody sheet signed before anyone leaves the room.

Step 5: Set partition policies deliberately

Every partition ships with default policies, and defaults are decisions someone else made. Dump them, with the verbose flag so you can see which changes are destructive:

lunacm:> partition showpolicies -verbose

Most policies can stay at default, on purpose, with the register recording that the default was reviewed. A handful deserve explicit decisions on every partition:

• 22 (Allow activation) and 23 (Allow auto-activation) — on for any partition backing an unattended service on a PED-authenticated estate, off where a human is meant to be in the loop. Both transitions are non-destructive. The full reasoning and rollout, including the reboot and power-loss drills, is in the partition policies for unattended startup walkthrough.
• 0 (Allow private key cloning) — on (the default) for anything that will join an HA group or be backed up by cloning; cloning is how replication works.
• 1 (Allow private key wrapping) — off (the default), and it stays off unless a documented interoperability requirement says otherwise. This is the “can private keys leave the hardware in a file” switch. Note that policies 0 and 1 are mutually exclusive — the HSM refuses to have both on (CKR_CONFIG_FAILS_DEPENDENCIES) — so “exportable and HA-cloned” is not a thing you can sleepwalk into, but an export-enabled partition is, and an assessor will ask about it.

Changes are a PO operation:

lunacm:> role login -name po
lunacm:> partition changepolicy -policy 22 -value 1
lunacm:> partition changepolicy -policy 23 -value 1
lunacm:> role logout

Check the verbose output before every changepolicy: some policy transitions on some versions are destructive to partition contents, and the safe moment to change those is now, while the partition is empty. The exact policy list varies with firmware and the partition’s licensed capabilities, so treat the numbers above as the stable, commonly relevant core rather than an exhaustive inventory for your version.

Step 6: Assign clients to the partition

A partition nobody can reach is safe but useless; a partition every client can reach is the opposite. Back in lunash, assign each registered NTLS client to exactly the partitions it consumes:

lunash:> client assignpartition -client ca01 -partition adcs-issuing-prod-01
lunash:> client show -client ca01

Assignment is the enforcement point for your partition strategy: the whole point of separate partitions evaporates if every client is assigned to every partition “to keep things simple”. One client, its own certificate identity, assigned only to its own partitions. If you are choosing between NTLS and STC for the client link — or wondering why the client certificate’s name matters so much at DR time — that is a chapter of its own: NTLS vs STC and what breaks at failover. On the client, confirm the new slot is visible with vtl verify (or lunacm’s slot listing) before declaring victory.

Step 7: Write the partition register

The estate is now provisioned; make it auditable. One row per partition, kept wherever your configuration records live, reviewed whenever a partition is added or a custodian changes:

Field	Example
Partition name / label	adcs-issuing-prod-01
Serial number(s)	154438865290 (hsm-a), 154438865312 (hsm-b)
Appliances	hsm-a (DC1), hsm-b (DC2)
Consumer / owner	ADCS issuing CA — PKI team
Environment	Production
Auth type	PED (multifactor quorum)
Cloning domain	dom-pki-prod (red key set A)
HA group	ha-adcs-issuing-prod
Policies changed from default	22→1, 23→1 (change record CHG-1042)
PO custodian	Security ops, safe 1 (blue key #3)
CO custodian	PKI team lead (black key #3)
CU / app credential location	n/a — CA uses CO via KSP
Assigned clients	ca01, ca02
Last verified	2026-11-05

This one table answers most of what an IRAP assessor will ask about your HSM key management in the first hour, and it is nearly free to maintain if it is filled in at provisioning time — and nearly impossible to reconstruct honestly two years later.

---

Where this leaves you

You have partitions that are named for what they serve, roles held by the people who should hold them, policies you can defend line by line, and a register that proves all of it. The next question is one no amount of clean provisioning answers: whether these partitions should live in your data centre at all, or in Thales’s cloud, or behind a hyperscaler’s KMS API — the sovereignty and IRAP trade-offs are the next concept chapter. The series index is at The Luna Field Guide.