smartenterprisewisdom

Accutive Security

The Cryptography, Data Protection and Identity Security Center of Excellence

Articles What Are Entrust nShield HSMs? A Guide to Entrust HSMs for Enterprise Key Protection
A Complete Guide to Entrust nShield HSMs

What Are Entrust nShield HSMs? A Guide to Entrust HSMs for Enterprise Key Protection

Paul Horn

Chief Technical Officer

Posted on 06/11/2026
Paul Horn is the Chief Technical Officer (CTO) of Accutive Security; he has over 30 years of cybersecurity and software development experience with a focus on data protection and cryptography
Posted on 11/06/2026

Encryption is only as strong as the protection around the keys it depends on. Organizations across industries manage large inventories of cryptographic keys that are foundational to certificate infrastructure, code signing, application encryption, cloud access controls, and identity systems. If those keys are inadequately protected, the security controls built on top of them are exposed regardless of the algorithm used.

As environments become more hybrid, cloud-connected, and AI-driven, organizations need stronger control over how keys are generated, stored, accessed, used, and retired.

Hardware security modules (HSMs) address this by providing a dedicated, hardware-rooted environment for cryptographic key protection, one that exists outside the reach of general-purpose server software and the processes that run on it.

Entrust HSMs, including the Entrust nShield HSM family, are widely deployed HSMs to protect cryptographic keys and support high-assurance security use cases across a range of environments and applications.

This guide explains what Entrust nShield HSMs are, how the nShield family is structured, where they are most commonly deployed, and why organizations need an expert partner for implementation and integration.

What Is an HSM?

A hardware security module (HSM) is a dedicated, tamper-resistant device or cloud-hosted service used to generate, protect, and manage cryptographic keys. The core design principle is that private key material stays inside the device. When an application needs a cryptographic operation, like signing a certificate, encrypting data, or generating a key pair, it sends the request to the HSM. The result is returned to the application, but the key stays protected inside the hardware boundary.

This is crucial because software-based key storage exposes keys to the same attack surface as the systems hosting them. A private key on a general-purpose server can be read from memory, extracted from disk, or accessed by an overly permissioned process. An HSM eliminates that exposure surface by keeping key material within a physically and logically isolated boundary that the host operating system cannot reach.

Beyond key storage, HSMs are purpose-built cryptographic systems that help enforce access control policies, enable key protection, support separation of duties between administrators and key custodians, and maintain auditable logs of key usage events. These control and governance capabilities are what make HSMs relevant to compliance programs, not just the hardware protection alone.

Your Encryption Is Only as Strong as Your Keys

Protect critical cryptographic keys with a security architecture built for modern enterprise environments.

What Are Entrust nShield HSMs?

Entrust nShield HSMs are Entrust’s family of general-purpose hardware security modules, built to provide cryptographic key services for enterprise applications, PKI environments, and cloud or hybrid architectures. They are designed to help organizations store and protect high-value cryptographic keys and perform sensitive cryptographic operations in a dedicated, security-hardened environment, providing a hardware root of trust for the applications and systems that depend on them.

nShield is not a single product. It is a family spanning network-attached appliances, PCIe cards, a portable USB device, and a cloud subscription service, all sharing a common key management architecture.

The nShield family supports key generation and protection, encryption, digital signing, and certificate authority operations.  The current generation nShield 5 product family (nShield 5s and 5c) has achieved both FIPS 140-3 Level 3 certification and Common Criteria EAL4+ (EN 419 221-5) certification, positioning Entrust among a small group of vendors meeting the current cryptographic module standards in both US and EU markets.

Overview of the Entrust nShield HSM Family

Entrust nShield 5c

  • What it is
    Entrust nShield 5c is a network-attached HSM appliance delivering cryptographic services to applications across the network, in the cloud, and in hybrid environments, performing encryption, digital signing, key generation, and protection.
  • Good fit for
  • Centralized HSM infrastructure serving enterprise applications, PKI, and signing workflows.
  • Hybrid and cloud-connected environments where multiple hosts or applications share HSM access.
  • Supports
  • Encryption, digital signing, key generation, and key protection.
  • Network, cloud, and hybrid deployment models.
  • Certified by
  • FIPS 140-3 Level 3
  • Common Criteria EAL4+ (EN 419 221-5)

Entrust nShield 5s

  • What it is
    Entrust nShield 5s is a PCIe card-based HSM installed directly inside a host server or appliance. It performs encryption, digital signing, and key generation for commercial and custom-built applications, including certificate authorities and code signing.
  • Good fit for
  • Environments where cryptographic services need to be co-located within a specific host.
  • Certificate authority and code signing applications.
  • Supports
    Encryption, digital signing, and key generation for commercial and custom-built applications
  • Certified by
  • FIPS 140-3 Level 3
  • Common Criteria EAL4+ (EN 419 221-5)

Entrust nShield Edge

  • What it is
    Entrust nShield Edge is a portable, USB-connected HSM for lower-volume, offline, or controlled key operations.
  • Good fit for
  • Offline root CA key generation ceremonies.
  • Development and testing environments.
  • BYOK-related workflows.
  • Available as
  • FIPS 140-2 Level 2 variant.
  • FIPS 140-2 Level 3 variant.
  • Non-FIPS developer edition.

Entrust nShield as a Service (nSaaS)

  • What it is
    Entrust nShield as a Service (nSaaS) is a subscription-based cloud HSM service that provides dedicated HSM capabilities without requiring organizations to manage physical appliances on-premises.
  • Good fit for
  • Organizations reducing on-premises hardware footprint.
  • Teams migrating from an existing nShield estate to a cloud-delivered model.
  • How it works
  • Delivered on dedicated FIPS 140-2 Level 3 certified nShield Connect HSMs hosted in Entrust-operated data centers.
  • Provides the same functionality as on-premises nShield HSMs under a cloud service model.
  • Entrust’s Cloud Concierge service supports migration from an existing on-premises nShield deployment to nSaaS.

Solo XC and Connect XC: End-of-Sale and Migration

In October 2024, Entrust set a formal transition timeline for its previous-generation nShield hardware.

  • Key dates
  • End-of-sale for nShield Solo XC and Connect XC: October 31, 2025 (excluding Common Criteria-specific versions)
  • End-of-maintenance: December 31, 2027
  • nShield Solo+ and Connect+ have already reached end-of-support and are not viable long-term platforms
  • Replacement path
  • nShield 5s replaces Solo XC
  • nShield 5c replaces Connect XC
  • Entrust publishes a dedicated nShield 5 Adoption Guide for customers transitioning from Solo XC and Connect XC
  • What makes migration manageable
    The nShield 5 family uses the same Security World architecture as previous generations. That means nShield 5 HSMs can be added into an existing Security World alongside legacy hardware, supporting a phased migration rather than a hard cutover.
  • Bottom line
    Organizations still running Solo XC or Connect XC hardware are now on a defined timeline. Migration planning should be active, not exploratory.

HSMs Protect Keys. PKI and CLM Help Manage Trust.

Build a stronger foundation for certificate security, lifecycle management, and machine identity protection.

How Entrust nShield HSMs Protect Enterprise Keys

  • Key generation inside the hardware boundary: Cryptographic keys generated inside an nShield HSM are created within the device’s secure perimeter and stay there. Applications receive the output of a cryptographic operation, such as a signed value or an encrypted payload, but the raw key material itself is never exposed to the host operating system or the application layer.
  • Access control and separation of duties: nShield HSMs enforce role-based access controls that distinguish between administrative and operational permissions. Administrators who configure the HSM operate separately from those invoking key operations, and both are separate from the applications using the HSM for cryptographic work. Policy controls define which keys can be used for which operations, by whom, and under what conditions.
  • Auditability and operational governance: All key usage events are logged, producing an auditable record that supports compliance reviews, access certification, and incident investigations. For regulated organizations, this visibility is often as important as the hardware protection itself.
  • Strong third-party assurance: The nShield 5 family’s FIPS 140-3 Level 3 and Common Criteria EAL4+ (EN 419 221-5) certifications provide documented, independent verification of the security boundary, giving security teams, procurement teams, and auditors evidence beyond vendor claims.
  • nShield Security World: Security World is the key management architecture and software framework that spans the nShield product family. It manages keys and HSM environments across a deployment, supports unlimited key storage, and applies consistent policy across different nShield form factors. A network appliance, a PCIe card, and the cloud service can all operate within the same Security World.

Security World configuration is one of the more consequential decisions in an nShield deployment. Entrust provides installation and setup documentation for nShield 5s, 5c, and Edge, but organizations working in complex environments typically benefit from implementation expertise that goes beyond published documentation.

Common Use Cases for Entrust nShield HSMs

PKI and Certificate Authority Key Protection

Root CA and issuing CA private keys are among the highest-value targets in enterprise infrastructure. A compromised CA key invalidates trust across every certificate that CA has issued.

nShield HSMs protect these keys inside a hardware boundary and support offline root CA designs, where the root key is brought online only during controlled signing ceremonies with defined quorum and administrative controls. This enforcement of key ceremonies and separation of duties is central to how well-designed PKI programs manage CA risk.

Code Signing

Code signing keys authorize software releases. A stolen or misused signing key can be used to distribute malware carrying a trusted publisher’s identity, bypassing endpoint and supply chain controls.

nShield HSMs protect signing keys and support auditable signing governance across software, firmware, scripts, containers, and DevOps pipelines. Entrust positions nShield specifically for code signing use cases, including key protection and controlled signing operations.

Data Encryption and Application Security

nShield HSMs protect encryption keys for databases, applications, file systems, and sensitive workloads. Applications invoke cryptographic operations through the HSM without directly handling the underlying key material, keeping that material inside the hardware boundary.

For organizations managing broader key and secrets lifecycle requirements, Entrust KeyControl provides a key management layer that integrates with nShield HSMs for more comprehensive governance across the key lifecycle.

Cloud Key Management

Cloud adoption often increases pressure on key governance. BYOK and HYOK models allow organizations to generate and retain keys in hardware under their own control, rather than delegating that responsibility to the cloud provider’s key management infrastructure.

In hybrid and multi-cloud environments, a defined HSM strategy supports consistent key protection policies across platforms, preventing governance from fragmenting as the infrastructure expands.

Digital Signing and Identity Trust

nShield HSMs support document signing, transaction signing, and device identity use cases where high-assurance cryptographic operations are required. The Common Criteria EAL4+ (EN 419 221-5) certification on the nShield 5 family is specifically relevant for organizations operating in eIDAS-regulated contexts, where qualified electronic signatures and trust services require cryptographic hardware that meets defined EU standards.

Compliance-Driven Key Protection

Regulated organizations across financial services, healthcare, and government commonly deploy HSMs to support compliance requirements around key protection, access control, and auditability. Frameworks frequently associated with HSM deployments include PCI DSS, HIPAA, GDPR, eIDAS, and FIPS 140-3.

HSMs support compliance programs, but configuration, access policy, and operational governance determine whether a deployment actually meets the intent of a given requirement. Organizations working toward specific compliance outcomes benefit from implementation expertise alongside hardware procurement.

Entrust HSMs vs. Cloud KMS: When Is an HSM Needed?

Cloud key management services (KMS) from AWS, Azure, and Google Cloud are appropriate for many workloads. They are scalable managed services integrated with cloud-native application architectures, and for general encryption needs they are often a practical default.

The relevant question is not whether cloud KMS tools are useful, but whether they provide the control, isolation, and assurance that specific use cases require. The following framework helps identify when a dedicated HSM is the better fit.

   Decision Factor

             Cloud KMS

                                                     Dedicated HSM

Key sensitivity

Suitable for general workloads

High-value keys such as CA, code signing, and payment warrant dedicated hardware

Compliance requirements

May satisfy baseline requirements

FIPS 140-3, PCI DSS HSM mandates, eIDAS, or government frameworks may require validated hardware

FIPS validation level

Often FIPS 140-2 Level 2 or Level 3, varies by provider

nShield 5 is FIPS 140-3 Level 3; FIPS 140-2 certificates move to the historical list after September 2026

Dedicated hardware boundary

Shared infrastructure with logical isolation

Physical, dedicated cryptographic boundary

Offline or controlled key ceremonies

Not supported

Supported, including quorum-enforced CA ceremonies

Multi-cloud consistency

Typically provider-specific

Security World enables consistent key management across on-premises and cloud

Root of trust use cases

Limited

CA key protection, PKI roots, payment security

Quantum-resistant algorithms

Mixed support that is provider-specific, partly TLS layer

nShield 5 natively supports ML-DSA, ML-KEM, and SLH-DSA in firmware with CAVP-validated implementations and hardware PQC acceleration; FIPS 140-3 module validation of PQC firmware in progress

For a deeper comparison of HSM and cloud KMS architectures, read our dedicated guide on HSM vs KMS.

Deployment Models: On-Premises, Cloud, and Hybrid

Entrust nShield HSMs can be deployed in different ways depending on where an organization’s applications run, what compliance frameworks apply, and how much operational overhead the team can absorb.

  • On-premises nShield HSMs

On-premises nShield HSMs provide direct control over the physical hardware environment. This is the natural fit for organizations running data center infrastructure, offline PKI, or environments where regulatory or internal policy requires physical custody of cryptographic hardware.

  • Cloud HSM / nShield as a Service (nSaaS)

nSaaS removes the need to procure and manage physical appliances. Dedicated FIPS 140-2 Level 3 certified nShield Connect HSMs, hosted in Entrust-operated data centers, deliver the same nShield functionality under a subscription model. This appeals to organizations reducing their data center footprint or migrating an existing on-premises nShield estate to a cloud-delivered model.

  • Hybrid HSM architecture

Many large enterprises, financial institutions, and government organizations maintain hybrid HSM environments, with on-premises hardware for legacy and controlled workloads alongside cloud-connected HSM services for modern applications. The nShield Security World architecture allows on-premises nShield 5 HSMs and nSaaS to operate under the same key management framework, making hybrid deployments within the nShield ecosystem more manageable during phased transitions.

Choosing the Right Model

The appropriate model depends on a combination of risk tolerance, key sensitivity, compliance requirements, operational capacity, latency, application integration needs, and long-term cloud strategy. These factors often interact, and organizations with complex environments benefit from mapping requirements before committing to a deployment architecture.

What to Consider Before Implementing Entrust nShield HSMs

The success and failure of HSM projects is decided in the planning phase. The appliance itself is the straightforward part. The decisions made before it arrives shape how well it integrates, performs, and holds up operationally. Below are some considerations that need to be addressed before implementing Entrust nShield HSMs:

Current state and requirements

  • Inventory of cryptographic keys in scope and the applications or systems that need HSM integration
  • Relevant use cases: PKI, code signing, cloud key management, data encryption, digital signing
  • Required form factor based on application architecture and data center or cloud environment
  • FIPS 140-2 versus FIPS 140-3 requirements based on regulatory frameworks, government contracts, or customer expectations
  • Organizations still running Solo XC or Connect XC should factor migration scope and timelines into this assessment given the announced end-of-maintenance date of December 31, 2027

Architecture and design

  • Security World design, including key backup and restore strategy
  • High availability and disaster recovery requirements
  • Key ceremony planning, administrator roles, and quorum controls
  • Firmware and software lifecycle planning for the deployment

Integration planning

  • Certificate authorities, CLM platforms, code signing tools, KMS solutions including KeyControl, PAM and IAM systems, and custom applications that will connect to the HSM

Operational readiness

  • Documentation, operational runbooks, and staff training before go-live

Common Implementation Challenges

Even well-resourced teams run into predictable problems when deploying HSMs without adequate preparation.

  • Treating it as a hardware install. An nShield deployment is a cryptographic architecture project. Security World design, HA configuration, and integration planning require deliberate effort before the first key is generated.
  • Underestimating planning time. Key ceremony procedures, quorum controls, and backup strategies take longer to define correctly than most teams anticipate.
  • Unclear ownership. Security, infrastructure, PKI, application, and compliance teams all have a stake. When ownership is ambiguous, gaps appear in integration and governance.
  • Incomplete backup and recovery planning. A Security World without a tested backup and recovery procedure is a liability, not an asset.
  • Undocumented key ceremonies. Ceremonies that are not formally documented become difficult to repeat, audit, or hand off.
  • Application integration misalignment. HSM design that does not account for how applications will connect via PKCS#11, JCE, CNG, or custom integrations creates rework after deployment.
  • Legacy migration complexity. Moving from Solo XC, Connect XC, or non-Entrust HSM platforms without disrupting dependent systems requires careful sequencing and a tested migration plan.
  • Insufficient documentation and training post go-live. Teams that inherit an HSM environment without adequate documentation and training tend to make conservative, uninformed decisions that accumulate as operational debt.

How Accutive Security Helps With Entrust nShield HSMs

Accutive Security is an Entrust services and resale partner. We help organizations evaluate, purchase, implement, integrate, migrate, and support Entrust nShield environments.

Accutive Security’s experts can help you with

  • HSM advisory and solution planning
  • Entrust nShield product selection and procurement support
  • nShield implementation and Security World design
  • PKI and CA integration, including offline root CA and key ceremony support
  • Code signing platform integration
  • Cloud and hybrid key management design, including KeyControl integration where applicable
  • Migration from Solo XC and Connect XC to nShield 5s and 5c ahead of the December 2027 end-of-maintenance date
  • Migration from non-Entrust HSM platforms
  • HSM health checks for existing deployments
  • Documentation, operational runbooks, and training
  • Managed support and staff augmentation

A successful HSM deployment depends on architecture, integration, governance, and operational readiness. The hardware is the starting point. Accutive Security also works across Thales and other HSM platforms, which means organizations evaluating multiple HSM options can work with us to identify the right fit for their environment before committing to a deployment path.

If your organization is evaluating Entrust HSMs, planning an Entrust nShield HSM implementation, or migrating from Solo XC or Connect XC to the nShield 5 family, Accutive Security can help you assess requirements, select the right deployment model, and implement a secure, operationally sustainable HSM environment.

Choosing an HSM Is Only the First Step

Expert guidance on architecture, integration, migration, and long-term key management.

Frequently Asked Questions

Entrust HSMs are hardware security modules used to generate, protect, and manage cryptographic keys for enterprise security use cases such as PKI, code signing, encryption, and digital signing.

An Entrust nShield HSM is part of Entrust’s nShield family of hardware security modules, which includes network-attached (nShield 5c), PCIe (nShield 5s), USB (nShield Edge), and cloud subscription (nShield as a Service) deployment options.

Entrust nShield HSMs are used for cryptographic key protection, certificate authority security, code signing, encryption, cloud key management, and other high-assurance digital trust use cases.

nShield 5c is a network-attached HSM appliance, while nShield 5s is a PCIe HSM card installed in a server or appliance. Both are FIPS 140-3 Level 3 and Common Criteria EAL4+ certified.

Entrust announced end-of-sale for Solo XC and Connect XC on October 31, 2025, and end-of-maintenance on December 31, 2027 (excluding Common Criteria-specific versions). Customers on these platforms should plan migration to nShield 5s and 5c.

Yes. Accutive Security provides Entrust HSM services including advisory, resale support, implementation, integration, migration (including Solo XC / Connect XC to nShield 5), health checks, and operational support.

Share Article

Leave a Reply

Comment

No Comments Found.
Gartner Peer Insights badge with five stars and 'Verified customer reviews' text, indicating trusted reviews.

Ready to start or accelerate your quantum readiness journey?

Connect with a Quantum Readiness Expert

Step up your cybersecurity posture with Thales Hardware Security Modules

Seamless integrate HSMs into your cybersecurity stack

Download this Resource