Luna HSM partition strategy: per application, per environment, or per tenant?

Every Luna estate starts with the same quiet decision, usually made in the first week and lived with for a decade: how do we carve the HSM into partitions? Some teams create one big partition and point everything at it. Some create a partition per application, per environment, per tenant — and discover two years later that they have forty partitions, forty Partition Security Officers’ worth of credentials, and a licensing invoice nobody budgeted for. Both extremes hurt. This chapter is about choosing deliberately.

If you’re new to the platform, our Luna HSM design and operational guide covers the foundations. Here we assume you know what a partition is and focus on how many you should have, and why.

What a partition boundary actually isolates

An application partition on a Luna Network HSM is a logically independent vault inside the appliance. The boundary is real, and it isolates three things that matter for security architecture:

• Keys. Cryptographic objects in one partition are invisible to sessions on another. An application authenticated to partition A cannot enumerate, use or exfiltrate keys in partition B. There is no cross-partition key access, full stop.
• Roles. Each partition carries its own role hierarchy — Partition Security Officer (PO), Crypto Officer (CO) and Crypto User (CU) — with independent credentials. Compromising the CO of one partition grants nothing on its neighbours.
• Policies. Partition policies — activation, key export, cloning behaviour — are set per partition by that partition’s PO. One partition can permit key wrapping for a justified interoperability case while every other partition on the appliance keeps it off.

Just as important is what the boundary does not isolate:

• The physical device. Every partition shares the same cryptographic module, the same tamper envelope, the same power supplies and the same fans. A hardware failure or tamper event takes them all down together.
• Firmware and appliance software. A firmware upgrade is an appliance-wide event. You cannot upgrade one partition’s firmware; every consumer shares the same maintenance window and the same regression risk.
• Appliance administration. The appliance admin (lunash) and the HSM Security Officer sit above all partitions. They cannot read partition keys, but they can create, delete and resize partitions and reboot the appliance. That is an availability-level power over every tenant.
• Performance. Partitions share the appliance’s crypto engine. A signing-happy consumer can starve its neighbours; partitioning is a security boundary, not a QoS mechanism.

Hold both lists in your head at once. Partitions give you genuine key, role and policy separation without buying more hardware — and they give you nothing against shared-fate risks, which is why partitioning strategy and HA strategy have to be designed together.

The three strategies

Per application

Each consuming system — the privileged-access vault, the issuing CA, the code-signing service — gets its own partition. This is the natural grain for most estates: blast radius maps to a system, policies map to what that system actually needs, and the CO credential lives in exactly one place (that application’s configuration). When the vault team asks “what can our HSM credential reach?”, the answer is one line long.

Per environment

Production, non-production and development each get a partition (or a set of them), usually multiplied against the per-application split: vault-prod, vault-uat, ca-prod, and so on. The argument for it is discipline: a load test in UAT cannot touch production keys, a developer’s misconfigured client cannot be pointed at the production slot, and you can rehearse destructive operations — policy changes, restores, re-initialisation — on a partition whose destruction costs nothing. The argument against is arithmetic: it multiplies your partition count, and partition count is a licensed resource.

Per tenant

Relevant when you operate cryptography as a service for organisational units, agencies or customers who must not share a trust boundary. Each tenant gets a partition, its own PO/CO/CU keyset or credentials, and often its own cloning domain so their keys cannot even be replicated alongside a neighbour’s. This is the strongest separation the platform offers short of separate hardware — and the most expensive in role management, because every tenant boundary is a full set of credentials, custodians and ceremonies.

The trade-offs, side by side

Axis	One big partition	Per application	Per app + environment	Per tenant
Blast radius of a compromised CO credential	Every key in the estate	One system’s keys	One system in one environment	One tenant
Policy divergence	Impossible — one policy set must fit all consumers	Policies match each system’s needs	Full flexibility, incl. looser non-prod policies	Full flexibility per tenant
Role sprawl	Minimal (one PO/CO/CU set)	Moderate — one set per system	High — sets multiply by environment	Highest — plus per-tenant custody ceremonies
Partition-count licensing	Base entitlement is plenty	Usually within a mid-tier entitlement	Often needs upgrade packs	Plan licensing before onboarding tenants
HA design impact	One HA group, simple	One HA group per partition, same members	Many groups; non-prod may skip HA	Per-tenant groups, possibly per-tenant domains

Two of those rows deserve expansion. On licensing: the number of application partitions a Luna Network HSM will host is a licensed entitlement, not just a technical ceiling. Base partition counts vary by model, upgrades are sold in packs, and the top of the range supports up to 100 partitions — but the entry model does not accept partition upgrades at all. Check the current datasheet and your entitlement before you promise a partition-per-everything design; the confirmation costs one email to your Thales account team, and the alternative is redesigning your isolation model to fit a licence.

On HA: high availability in the Luna world is configured per partition — an HA group is a set of member partitions on different appliances, synchronised by cloning within a shared domain. Every partition you add is another HA group to build, another synchronisation state to monitor, another failover behaviour to test. Before you multiply partitions, read what actually replicates in a Luna HA group — the answer shapes how expensive each additional partition really is.

How your consumers constrain the choice

Partitioning is not decided in the abstract; the systems consuming the HSM push back. A CyberArk vault holds the single key that unlocks every credential in your privileged-access estate — the server key dependency works in reverse of what most people expect — and that key deserves a partition whose CO credential exists in exactly one place: the vault’s configuration. Sharing that partition with anything else means another system’s credential can reach the key that opens your vault. Don’t.

Microsoft ADCS pulls the same direction for different reasons. An offline root CA’s key wants a partition that is deliberately not in any HA group and possibly not on the same appliance pair at all, while an issuing CA on a Luna HA group wants exactly the opposite: an HA-replicated partition with activation policies tuned for unattended service startup. One partition cannot be both. The consumers, in practice, decide your minimum partition count for you: vault, root CA, issuing CA and code signing already gives you four before any environment split.

A sane default for a regulated mid-size estate

For the estates we typically see in Australian government and regulated-PII organisations — a handful of consumers, two data centres, an IRAP assessment somewhere in the future — the default that ages best is per application, with a production/non-production split for consumers that have a real non-production tier. Concretely: one partition per consuming system in production; one shared non-production partition per consumer type where testing genuinely needs an HSM; no per-developer or per-microservice partitions, ever. That usually lands between six and twelve partitions — comfortably inside a mid-tier licence, small enough that the role register stays maintainable, large enough that no auditor will ever find two unrelated systems behind one Crypto Officer.

Deviate upward to per-tenant partitions only when a boundary is contractual or statutory — separate agencies, separate classification handling caveats, separate customers — and price the role-management overhead honestly before you commit. Deviate downward, towards sharing, only for genuinely co-owned systems in the same trust zone with identical policy needs, and record the shared-fate decision in writing. “The partitions were free to create” is not a design rationale, and neither is “the licence only allowed five”.

How one big partition fails an audit

A composite scenario — assembled from field patterns and community reports, not from any specific engagement. An organisation handling police-check-class PII stood up a Luna pair years ago for its issuing CA. It worked, so the vault went into the same partition. Then the document-signing service. Then the tokenisation layer for an identity-verification platform. By the time an IRAP assessor arrived, one partition held the keys of four systems owned by three teams, and one Crypto Officer challenge secret — stored in four different configuration stores, known to an unknowable number of current and former administrators — could use all of them.

The finding wrote itself, and it wasn’t about the hardware. The ISM’s expectations on key management and separation of duties assume you can say who can use which key and demonstrate that the CA team cannot touch the vault’s key material. The organisation could not. Nobody had breached anything; the architecture simply made “who can access this key?” unanswerable, and unanswerable is a fail. The remediation — migrating live keys out into per-application partitions, re-pointing four production systems, and standing up role ceremonies that should have existed from day one — consumed a change window every month for half a year. Creating four partitions in week one would have taken an afternoon.

---

Where this leaves you

You now have a partition map: which consumers get their own boundary, where the environment splits are, and a licence position to verify before anything is built. The hands-on companion to this chapter walks through provisioning it cleanly — naming, roles and policies included. The next design problem is bigger than the appliance: whether the hardware should be yours at all. On-prem Luna, Thales’s DPoD cloud service and the hyperscalers’ native KMS offerings answer the sovereignty question very differently, and that comparison is the next chapter. The series so far lives at The Luna Field Guide.