Mapping ISM cryptography controls to HSM capability

“We bought an HSM for ISM compliance” is a sentence that should worry you, because the ISM never tells you to buy an HSM. What the Australian Government Information Security Manual actually asks for is a set of demonstrable properties around cryptographic keys — how they are generated, stored, accessed, recovered, destroyed, and what happens when they are compromised. A hardware security module is the strongest available way to satisfy several of those properties, a partial answer to others, and completely irrelevant to a few. Knowing which is which is the difference between an IRAP assessment where the HSM carries its weight and one where it sits in the rack as an expensive decoration next to a pile of findings.

This chapter maps ISM cryptographic key-management expectations against what a Thales Luna HSM can actually evidence, for organisations handling identity-verification data, police-check-class PII or other regulated holdings. It builds on the platform detail in our Luna HSM design and operational guide, and it is deliberately honest about the gaps — because your assessor will be.

What the ISM actually asks for

The ISM’s cryptography guidelines are outcome-shaped, not product-shaped. The anchor control for this chapter is ISM-0507: cryptographic key management processes, and supporting cryptographic key management procedures, are developed, implemented and maintained. The guidance around it sketches the lifecycle those processes must cover — generation, registration, distribution, installation, usage, protection, storage, access, recovery and destruction. Two companions deal with the failure case: keying material is changed when compromised or suspected of being compromised (ISM-1091), and the compromise or suspected compromise of cryptographic equipment or keying material is reported to the CISO or delegate as soon as possible (ISM-0142).

Around that core sit control families we will reference in prose rather than by number, because their identifiers shift between ISM releases and you should map against the current published version: the requirement to use ASD-approved cryptographic algorithms and protocols; event-logging and monitoring expectations that apply to cryptographic infrastructure as much as any other system; privileged-access controls requiring that administrative access is validated, minimised and separated; and physical-security expectations for the facilities where cryptographic equipment lives. An IRAP assessment of your cryptographic estate is really an assessment against that whole constellation — the key-management controls are just where it starts.

Where an HSM satisfies the intent — and a software keystore doesn’t

ASD’s published guidance on managing cryptographic keys expresses a preference for generating keys in hardware security modules, with software security modules as the fallback where an HSM is not available. That preference is not fetishism about metal; it maps directly onto lifecycle properties the ISM asks you to demonstrate:

• Generation. Keys are generated inside validated hardware by an approved random source, and the audit trail of that generation is produced by the device itself. A software keystore generates keys in general-purpose memory on a general-purpose OS, and its story about randomness and non-observation depends on the whole host stack behaving.
• Storage and protection. A Luna partition can hold keys as non-exportable objects inside tamper-responding hardware. The claim “this key has never existed outside the boundary” is a property you can point at. A file-based keystore’s equivalent claim is “nobody with admin rights ever copied the file”, which is not a property — it is a hope backed by logging.
• Access. The HSM enforces role separation in hardware: Security Officer, Crypto Officer, Crypto User and Auditor are distinct authentication domains, quorum-controllable with PED keys — the custody architecture we walked through in the key-ceremony and separation-of-duties chapter. Software keystores mostly inherit whatever access control the host OS offers, which collapses at the domain-admin tier.
• Recovery and destruction. Cloning-domain-bound backup to a Backup HSM gives you key recovery that never exposes plaintext material; zeroisation on tamper or decommission gives you destruction you can evidence rather than assert.

The honest comparison is not “HSM good, software bad” — it is that the HSM converts several ISM expectations from procedural claims you must argue into device properties you can demonstrate. That conversion is what you are paying for.

The certification chain an assessor will actually check

“It’s FIPS-validated” is the start of a conversation with an assessor, not the end of one. The chain that has to hold together:

• The certificate matches your firmware. FIPS 140 validation attaches to specific module versions. Luna 7 appliances have validations across the FIPS 140-2 and, on newer firmware, FIPS 140-3 programmes — but the certificate names exact firmware versions, and running firmware outside the validated set means running outside the validation. Check the NIST CMVP entry against hsm showinfo output, not against the brochure.
• The HSM is operating in its validated mode. Luna exposes a policy that restricts the HSM to FIPS-approved algorithms. A validated module running with that policy off is evidence of the opposite of what you intend. Export the policy state and keep it with your assessment pack.
• Common Criteria and eIDAS-type certifications, where claimed, match the deployment. If your accreditation argument leans on a CC evaluation, the evaluated configuration in the security target needs to resemble the configuration you actually run.

None of this is onerous, but all of it is version-dependent — treat the certificate lookup as a standing step in your firmware-upgrade change template, because an upgrade can silently walk you out of a validation months before anyone notices.

The evidence an IRAP assessor wants to see

Controls are tested through artefacts. For a Luna estate protecting regulated PII, the pack that answers most first-round questions looks like this:

• Key custody records. The keyholder register: who holds which PED key or split, against which position, with transfer history and safe locations. This is the primary evidence that key access is controlled and separated.
• Ceremony records. Scripted, witnessed, signed records of initialisation, partition creation, key generation and backup ceremonies — the point-in-time proof that the lifecycle started under control.
• HSM audit trails. Luna’s dedicated Auditor role produces signed, verifiable logs of key-lifecycle and administrative events, independent of the Security Officer. Exported, centralised and reviewed, these are your continuous evidence — the register proves who could act; the audit trail proves who did.
• Configuration state. HSM and partition policy exports, firmware versions, FIPS-mode status, client registration inventory — the machine’s own statement of how it is configured, dated and re-captured after every change.
• Recovery and destruction evidence. Backup ceremony records plus — the one most estates are missing — a dated, witnessed restore test, and zeroisation records for decommissioned or tampered units.

Mapping table: control theme to HSM capability to artefact

Control themes below are stated as lifecycle outcomes rather than exhaustive control citations; map them onto identifiers from the ISM release current at your assessment.

ISM control theme	HSM capability that satisfies the intent	Evidence artefact
Key management lifecycle governed by process and procedure (ISM-0507)	Enforced role model and quorum authentication give the procedures something rigid to attach to	Key management plan; ceremony records; keyholder register
Keys generated using approved cryptography, in hardware by preference	Onboard key generation with approved random source inside a validated boundary	FIPS/CC certificate matching firmware; generation entries in HSM audit log
Keying material protected in storage	Non-exportable key objects; tamper detection and response; FIPS 140 Level 3 physical protections	Partition policy export showing export disabled; validation certificate
Access to keying material controlled and separated	SO / CO / CU / Auditor role separation; PED-based multifactor quorum (M of N)	Keyholder register; partition role configuration; quorum drill records
Keys recoverable when equipment fails	Cloning-domain-bound backup to Backup HSM; HA group replication	Backup ceremony record; dated restore-test evidence
Keying material destroyed when no longer required	Partition and HSM zeroisation; zeroise-on-tamper behaviour	Decommissioning record; zeroisation entry in audit log
Compromise reported and keys changed (ISM-0142, ISM-1091)	Tamper events and audit alerts provide detection triggers; re-key supported without exposing material	Incident procedure referencing HSM events; audit log exports; re-key ceremony record
Cryptographic events logged and reviewed	Independent Auditor role; signed, verifiable audit logs	Centralised HSM audit trail; log review records

What the HSM does not fix

Now the honest column. An HSM does nothing for the controls that live in process and people, and an assessor will not let the hardware answer questions it cannot answer:

• ISM-0507 is a process control, and the HSM is not a process. The device enforces whatever custody model you configured — including a bad one. One engineer holding every PED key is fully HSM-enforced and fails the control completely.
• Application-layer key handling is out of scope of the boundary. If an application exports data-encryption keys from the partition and caches them on disk, the HSM protected exactly nothing about that workflow. The boundary only covers what stays inside it.
• Unreviewed logs are not monitoring. Signed audit trails nobody exports or reads satisfy no logging control. The Auditor role generates evidence; only your operating rhythm turns it into a control.
• Untested recovery is a hypothesis. A shelf of backup HSMs with an unknown cloning domain is the field’s most common quiet failure. Until a restore test has happened, dated and witnessed, your recovery control is an assertion.

The pattern across all four: the HSM narrows the set of things that can go wrong to the things you do around it. That is a genuinely enormous win — but it relocates the assessment onto your procedures, custody and evidence discipline, which is exactly where an under-resourced estate gets found out.

Where this leaves you

You now have the mapping: which ISM expectations the HSM converts into demonstrable device properties, which artefacts prove it, and which controls remain stubbornly yours. The next question is where that HSM capability should physically live — an appliance in your rack, Thales’s DPoD service, or a cloud provider’s KMS — because sovereignty, control boundaries and assessor expectations differ sharply between them, and for Australian government workloads that choice is a chapter of its own: the Luna versus DPoD versus cloud KMS decision. The full series lives at The Luna Field Guide.