---

This blog is part of the VTPP (VNET Threat Perception Platform) project, a three-year programme co-funded by the European Commission under the DIGITAL-ECCC-2022-CYBER-03 call. The project covers DDoS mitigation with FastNetMon, vulnerability scanning with OpenVAS, custom AI/ML detection plugins for Zeek, HSM-backed key management, RPKI validation and a Krill CA, and a full-scale deployment of Security Onion as the IDS/SIEM/NSM backbone.

---

Introduction

In the previous installment, we looked at why cryptographic security matters, the role HSM and KMS technologies play, and how they help protect organizations against ransomware and data breaches. Theory, however, is only half the story. The real value of a security infrastructure shows up only when you deploy concrete technologies in production.

One of the most widely adopted enterprise HSM solutions on the market today is the Thales Luna Network HSM platform — specifically the Luna Network HSM A750 model. This appliance sits at the high end of hardware cryptographic protection and is used across banking, government, critical infrastructure, cloud services, and PKI environments.

The Luna Network HSM A750 is engineered to deliver high availability, extremely strong protection of cryptographic keys, and the flexibility to integrate into modern IT infrastructures. Its core job is to perform cryptographic operations securely, without sensitive keys ever leaving the appliance’s security boundary.

In this installment we take a detailed look at how a network HSM works, how it is initialized and configured, its security mechanisms, user management, auditing, and logging. We then focus on the LunaCM client utility, the primary administration and integration tool for communicating with the HSM infrastructure.

What Is a Network HSM?

A network HSM is a dedicated cryptographic appliance attached to the network that provides cryptographic services to remote clients and applications. Unlike PCIe HSM modules, which are installed physically inside a server, a network HSM operates as a standalone appliance reachable over the network.

This model brings several significant advantages. The HSM can be centrally managed, shared by multiple applications, and located in a secure data-center environment that is separated from the production servers. As a result, the risk of cryptographic keys being compromised when the application infrastructure is attacked is substantially reduced.

The Thales Luna Network HSM A750 is aimed primarily at enterprise environments with stringent security requirements. It supports a broad range of cryptographic algorithms — including RSA, ECC, AES, and the SHA family — and integrates with PKI systems, databases, cloud platforms, VPN solutions, and certificate authorities.

A major benefit of the network HSM architecture is the ability to build highly available (HA) clusters. Multiple HSM appliances can work together in a redundant configuration, ensuring continuity of cryptographic services even if individual components fail.

Architecture of the Luna Network HSM A750

The Luna Network HSM A750 is a physical, rack-mounted appliance built for data-center environments. It ships with its own hardened operating system, dedicated cryptographic processors, and tamper-resistant security mechanisms.

One of its most important characteristics is FIPS 140-3 Level 3 validation. This level of assurance guarantees that the appliance meets strict requirements for protecting cryptographic operations, storing keys securely, and detecting tampering attempts.

The appliance supports multiple logical partitions, which allow you to separate cryptographic environments for different applications or tenants. Each partition behaves as an independent security domain with its own users, policies, and cryptographic objects.

Communication between clients and the HSM takes place over a secured network connection. Clients access the HSM through standard cryptographic interfaces such as PKCS#11, the Java JCE provider, Microsoft CNG, and the OpenSSL engine integration.

Installing the HSM in the Data Center

When deploying the Thales Luna Network HSM A750 in a data center, the appliance is typically mounted as a 1U unit in a standard 19-inch rack. Use the manufacturer’s sliding rails rather than rack ears alone, because the unit is fairly heavy. Place it in a locked rack or security cage, since this is a critical cryptographic appliance carrying FIPS 140-3 Level 3 protection.

The Luna A750 has redundant, hot-swappable power supplies, so in production it is usually connected to two independent UPS units or power feeds. On the network side, separate management traffic from production traffic — ideally over a dedicated management VLAN or an out-of-band segment. The appliance provides four Gigabit Ethernet ports and supports both interface bonding and IPv4/IPv6, so it is often connected redundantly to two switches.

After physical installation, the first step is to verify the integrity of the appliance and its security seals, because new units arrive in Secure Transport Mode. In enterprise environments, two A750 units are typically deployed in separate data centers for high availability and disaster recovery. It is equally important to forward audit logs to a SIEM system over syslog and to monitor the appliance via SNMP. Firmware upgrades should be performed carefully and always on UPS power, because interrupting power during an update can damage the appliance.

HSM Initialization and Initial Configuration

Once the appliance is racked and connected, the first step is to initialize the HSM. This process establishes the appliance’s baseline security state.

Initialization includes:

• Configuring administrative roles
• Generating the HSM’s internal cryptographic secrets
• Creating partitions
• Defining security policies
• Configuring authentication mechanisms

Initial configuration centers on the Security Officer (SO) account, the highest administrative authority over the appliance. This account is responsible for security settings, partition management, and user-permission control.

Strong emphasis is placed on securely storing authentication credentials and backup tokens. In enterprise environments it is common to apply dual-control, where appliance initialization must be confirmed by more than one administrator.

hsm login
hsm init -label HSM_LABEL
sysconf regencert -keytype ecc -d 3653 -country SK -state Slovakia \
 -location Bratislava -organization Organisation -orgunit "IT" \
 -email security@example.com -san "DNS:hsm.example.com"
sysconf timezone set Europe/Bratislava
sysconf ntp addserver ntp.example.com
sysconf ntp ntpdate ntp.example.com

Network Configuration

Because this is a network appliance, correct network configuration is a critical part of a secure deployment.

Administrators define:

• IP addressing
• Routing
• DNS configuration
• The management network
• The production interface
• Firewall rules
• Network segmentation

The recommended practice is to separate the management network from the production cryptographic traffic. The HSM should sit in a dedicated security zone with tightly defined access rules.

From a security standpoint, it is especially important to minimize the number of open ports and enabled services.

network interface bonding config -ip 192.168.0.10 -netmask 255.255.255.0 \
 -name bond0 -mode lacp
network interface bonding enable -name bond0
network interface bonding config -ip 192.168.1.10 -netmask 255.255.255.0 \
 -gateway 192.168.1.1 -name bond1 -mode lacp
network interface bonding enable -name bond1
network hostname hsm.example.com
network dns add nameserver 8.8.8.8 -device bond1
network dns add searchdomain example.com -device bond1

Open Ports and Security Interfaces

The Luna Network HSM typically uses only a limited set of network ports. The most important are:

• The SSH port for administration
• The NTLS / PKCS#11 client connection port used by applications
• Management services
• Synchronization ports for HA configurations

SSH is used for appliance administration and administrative access. In production it is often restricted to the management subnet and to specific administrator workstations.

The PKCS#11 interface is the principal cryptographic API used by client applications. It is a standardized interface for generating keys, encrypting, signing, and managing cryptographic objects. On the Luna appliance, client applications reach the HSM through Network Trust Links (NTLS), which provide mutually authenticated, TLS-protected channels.

The security philosophy behind HSM appliances is to minimize the attack surface. For that reason, the appliance does not run the everyday services you would find on a general-purpose Linux server.

ntls bind bond1
service restart ntls
sysconf ssh device bond0

How a Client Communicates with the HSM

To make the previous sections concrete, it helps to trace a single cryptographic request from a client application through to the appliance. The diagram below shows the two communication paths that every Luna Network HSM deployment keeps deliberately separate: the crypto (data) plane, over which applications request cryptographic operations, and the management plane, over which administrators configure the appliance.

On the data plane, a client application never talks to the HSM directly. It calls a standard cryptographic API — PKCS#11, Java JCE, or Microsoft CNG — which is serviced by the locally installed Luna HSM Client library. That library opens a Network Trust Link (NTLS) to the appliance: a mutually authenticated, TLS-protected channel on TCP port 1792. “Mutually authenticated” is the important part — during NTLS registration the appliance and the client exchange certificates, so each end cryptographically verifies the other before any traffic flows. A client that has not been registered with a given partition cannot establish a link to it at all.

Once the link is up, the application issues operations — generate a key, sign a digest, unwrap a key, encrypt a block — against a specific partition. The request crosses the network, the appliance performs the operation inside its FIPS 140-3 Level 3 cryptographic boundary using keys that live only in that partition, and only the result travels back. This is the defining property of an HSM deployment: the private and secret keys never leave the appliance. Even a fully compromised application server yields no key material, because the host only ever holds handles to objects, not the objects themselves.

Partitions enforce isolation on the appliance side. Each partition is a self-contained security domain with its own Crypto Officer and Crypto User roles, its own objects, and its own policies; an application authenticated to Partition A has no visibility into Partition B. This is what allows a single A750 to serve multiple applications, teams, or tenants from one piece of hardware without their keys ever mixing.

The management plane is intentionally a separate path. Administrators connect from a management workstation over SSH (TCP port 22) to LunaSH, the appliance shell, to handle configuration, policy changes, user management, and audit. In production this path is normally restricted to an out-of-band management VLAN and to specific administrator hosts. Separating it from the data plane means that day-to-day cryptographic traffic and privileged administration never share the same network exposure — a key part of minimizing the appliance’s attack surface. In a high-availability setup, a client is registered with two or more appliances and the HSM Client library load-balances and fails over across the NTLS links automatically, so the loss of one appliance does not interrupt cryptographic service.

Security Policies and Hardening

One of the strongest features of the Luna HSM is the ability to define security policies in fine detail.

Administrators can define:

Permitted algorithms

• Minimum key sizes
• Object-export rules
• Authentication policies
• Limits on user permissions
• Audit rules

Many policies are one-way (destructive): once enabled, they cannot be disabled again without re-initializing the appliance. This approach prevents the security posture from being weakened after the system is in production. One such example is disabling non-FIPS-approved algorithms by changing the appliance’s policy to FIPS-only mode.

hsm changePolicy -policy 12 -value 0

Note: policy numbers depend on the appliance and firmware version, so always confirm the correct policy index against the security policy and the output of hsm showPolicies before changing it. Regular firmware updates, network segmentation, and monitoring of cryptographic operations are also essential parts of hardening.

User Accounts and Roles

The Luna HSM implements a strictly defined role model.

The most commonly used roles include:

• Security Officer (SO)
• Crypto Officer (CO)
• Auditor
• Partition User / Crypto User
• Backup Operator

Each role has precisely defined permissions and access only to the operations it is meant to perform. This model strongly supports the principle of separation of duties.

Logging and Auditing

Auditing is one of the key security features of an enterprise HSM infrastructure.

The Luna HSM records:

• Authentications
• Configuration changes
• Cryptographic operations
• Unauthorized-access attempts
• System events
• Administrative operations

Logs can be exported to SIEM platforms such as Splunk or QRadar, where they can be analyzed as part of security monitoring.

Audit records play a critical role in:

• Incident response
• Forensic analysis
• Compliance audits
• Insider-threat investigations

To forward logs to a remote collector, the appliance can be configured with a remote syslog host — for example, over RELP with mutual TLS:

user list
user add -userName syslog
user role add -userName syslog -role operator
syslog remotehost add -host syslog.example.com -protocol relp -port 2514 \
    -tls -name syslog.example.com -mode mutual

User Partitions on the Luna Network HSM

A key part of the Thales Luna Network HSM architecture is its user partitions — logically isolated security domains inside a single physical HSM appliance. Their purpose is to securely separate cryptographic operations, keys, and users across different applications, teams, or tenants, without deploying a separate HSM for each environment.

Think of a user partition as a self-contained cryptographic container with its own set of objects, security policies, and user roles. Each partition operates in isolation from the others, which means that applications or administrators working in one partition have no access to cryptographic objects stored in other partitions. This model significantly increases security while also making more efficient use of the HSM’s capacity.

In enterprise environments, partitions are frequently used to separate:

• Production and test environments
• Different internal systems
• PKI infrastructures
• Database encryption services
• Different customers’ environments in a multi-tenant architecture

A major advantage of user partitions is the ability to define separate security policies for each environment. An organization can, for example, set different rules for key export, minimum algorithm key sizes, or authentication mechanisms depending on the sensitivity of a given application. Partitions can be created, deleted, backed up, or restored independently of the rest of the system, which greatly simplifies the administration of larger cryptographic infrastructures.

Each user partition has its own roles, typically:

• Partition Security Officer (PO / PSO)
• Crypto Officer (CO)
• Crypto User (CU)

The Partition Security Officer is responsible for initializing the partition and managing its security settings. The Crypto Officer then manages the cryptographic objects and the applications that use the partition. This model supports separation of duties and minimizes the risk of unauthorized access to cryptographic keys.

The administrator first creates a partition at the HSM level. The partition is then initialized and a PSO role is created, taking control of that cryptographic domain. After initialization, clients can be added to the partition, trust relationships established, and cryptographic objects created. Each application then connects to a specific partition through PKCS#11.

partition create -partition PART_INTERNAL
partition init -partition PART_INTERNAL -label INTERNAL \
    -password PSO_SECRET -domain DOMAIN

Partitions also support backup and restore operations, which are critically important in disaster-recovery scenarios and infrastructure migrations. Cryptographic objects can be securely cloned between compatible partitions, provided they share the same security (cloning) domain and policies.

slot set -s 0
role login -n co -password CO_SECRET_SLOT0
partition clone -slot 1 -password CO_SECRET_SLOT1 -objects all

Summary

The Thales Luna Network HSM A750 is a FIPS 140-3 Level 3 network appliance that performs cryptographic operations on behalf of remote clients while keeping the underlying keys permanently inside its security boundary. Deploying it well is less about any single command and more about discipline: rack it in a locked, redundantly powered environment; separate the management network from the production crypto traffic; initialize it under dual control; and lock down its security policies before it goes live, remembering that many of those policies are one-way.

Clients reach the appliance over Network Trust Links — mutually authenticated, TLS-protected channels carrying PKCS#11, JCE, or CNG calls — while administrators work over a separate SSH/LunaSH management path. Partitions provide cryptographic isolation, letting one appliance safely serve many applications or tenants, and HA clustering keeps services running through individual failures. Combined with thorough audit logging into a SIEM, this architecture gives an organization a hardware root of trust whose keys remain protected even if the surrounding application infrastructure is compromised. In the next installment we will move from the appliance itself to the LunaCM client utility and walk through integrating real applications with these partitions.

---

Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre. Neither the European Union nor the granting authority can be held responsible for them.

---