# nCipher / Entrust nShield: PQC Status **Source**: https://quantumsequrity.com/blog/ncipher-entrust-pqc **Category**: Implementations --- [← Back to Blog](../../blog.html) Implementations # nCipher / Entrust nShield: PQC Status 11 min read nShield is one of the most widely deployed network HSM lines in regulated industries. The product line traces back through nCipher to Thales acquisitions and back out to Entrust after a 2019 divestiture. Today Entrust ships and supports nShield Connect, nShield Solo, nShield Edge, and the nShield 5 platform. This post covers where the nShield family stands on post-quantum cryptography, how its CodeSafe sandbox enables custom PQC integrations, and what operators should plan for during migration. ## The nShield Product Family Entrust's HSM portfolio centers on three form factors: - **nShield Connect.** A network-attached 1U appliance, the workhorse of bank PKI and certificate authority deployments. The Connect series sits in racks and exposes its services over IP to client applications. - **nShield Solo.** A PCIe card that installs directly in a server. Used when a single host needs HSM-grade key protection without the overhead of a separate appliance. - **nShield Edge.** A USB form-factor HSM intended for development, lower-volume signing, and point-of-use scenarios. - **nShield 5.** Entrust's latest generation, which includes a redesigned firmware architecture and significantly more compute headroom than earlier generations. All four share Entrust's Security World, a key management abstraction that lets operators replicate keys across multiple HSMs while maintaining the same logical key handles. Security World is the operational glue that makes large nShield deployments manageable. ## Why nShield Customers Care About PQC The customer profile for nShield skews toward applications where PQC migration is mandatory rather than optional: - **Certificate authorities.** Public and private CAs that issue X.509 certificates. CA operators must plan for a multi-year transition during which they issue certificates with both classical and PQC keys, then eventually retire the classical keys. - **Banks and payment processors.** PCI HSM and payment scheme requirements drive these deployments. The payment industry standards bodies are starting to publish PQC roadmaps. - **Government deployments.** Defense and intelligence customers operating under regimes like CNSA 2.0 must adopt PQC on a defined timeline. - **Code signing.** Operating system vendors, OEMs, and software publishers sign their releases with HSM-protected keys. Code signed today must remain verifiable for decades, which makes hash-based signatures attractive. Each of these segments has its own urgency curve. Certificate authorities are at the leading edge because their root keys protect the entire web PKI. ## Algorithm Coverage in Recent Firmware Entrust has been releasing firmware updates that incrementally expose post-quantum algorithms. The release notes for recent nShield firmware versions name ML-KEM and ML-DSA among the algorithms available for new key types. Specific availability depends on the model, the firmware version, and the security world configuration. Operators should consult the Entrust support portal for the exact firmware build that exposes the algorithms they need. Coverage typically rolls out from the nShield 5 platform first because it has the most compute headroom, then to the older Connect and Solo lines as those firmware images are updated. For background on the algorithms themselves see our [ML-KEM explained](ml-kem-explained.md) and [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa.md) posts. ## CodeSafe: Sandboxed Code Inside the HSM A unique feature of the nShield platform is CodeSafe, a sandboxed code execution environment inside the HSM boundary. CodeSafe lets customers deploy custom code that runs with the same tamper-resistance and key protection guarantees as the firmware-blessed crypto operations. For PQC purposes, CodeSafe gives customers a faster path to deploying new algorithms than waiting for Entrust to bake them into the main firmware. A customer can: 1. Compile a vetted PQC reference implementation against the CodeSafe SDK 2. Sign the resulting binary with their CodeSafe signing key 3. Deploy the binary to the nShield, where it runs inside the HSM boundary 4. Expose the new algorithms through application-level APIs without waiting for an Entrust firmware release This is particularly useful for early adopters who need ML-DSA or hybrid signatures before the main firmware exposes them with full FIPS 140-3 validation. The trade-off is that CodeSafe code does not inherit the HSM's FIPS 140-3 validation. The validation covers the firmware and a defined boundary. Custom CodeSafe binaries fall outside the validation scope. For applications that need FIPS-validated PQC, the firmware-blessed path is the only option, and that requires waiting. ## Security World and PQC Key Storage Security World is the glue that makes multi-HSM deployments work. It encrypts keys with a Security World key derived from the operator card set and the HSM hardware roots. Keys stored in Security World are portable across HSMs that share the same Security World. PQC key types fit naturally into the Security World abstraction. The wire format and key handle conventions extend to ML-KEM and ML-DSA without breaking changes. Operators rolling out PQC alongside existing classical keys can use the same Security World configuration, which simplifies operational rollout. For long-lived keys (CA roots, code-signing keys), operators should test the backup and recovery flow with PQC keys before committing production keys to a Security World. The larger key sizes affect backup file sizes and the timing of key ceremony procedures. ## Hybrid Mode Options Entrust's posture on hybrid PQC matches the broader industry direction: hybrid is the recommended migration mode while validations and ecosystem support catch up. The nShield platform supports hybrid construction in two ways: 1. **Application-level composition.** The application generates a classical signature and a PQC signature over the same data, then concatenates them. This works today on any nShield with both classical and PQC algorithms in the firmware. 2. **Native hybrid types.** Where firmware exposes a dedicated hybrid type, the HSM performs both operations as a single API call. This is more operator-friendly but depends on firmware support. Read our [hybrid encryption](hybrid-encryption.md) post for the underlying design rationale. ## FIPS 140-3 Validation Tracking Entrust submits new firmware revisions to NIST CMVP for FIPS 140-3 validation. The validation process takes time. Operators in regulated industries should: - Subscribe to Entrust release notes - Check the NIST CMVP active modules list for the specific firmware version - Verify that the algorithm certificate covers the PQC algorithms they need - Plan deployment to coincide with validation availability The CMVP listings are public. The validation certificate names every algorithm and every test vector that the module passed. For PQC purposes, look for ML-KEM, ML-DSA, and SLH-DSA on the certificate. Falcon (FN-DSA) is on a longer timeline. ## Migration Steps for nShield Operators A staged migration plan for an nShield deployment: 1. **Inventory existing keys.** Catalog every key in every Security World, with its algorithm, usage, and rotation schedule. 2. **Identify high-priority keys.** Long-lived signing keys, especially CA roots and code-signing keys, are at the top of the migration queue because of harvest now decrypt later concerns. See our [harvest now decrypt later](harvest-now-decrypt-later.md) post. 3. **Test PQC firmware in a dev environment.** Stand up a non-production nShield, load the PQC-capable firmware, and exercise the new key types through your application stack. 4. **Plan key ceremonies.** PQC keys require new key ceremonies. The larger key sizes affect printable backup formats and operator card set configuration. 5. **Roll out hybrid first.** For most use cases, hybrid signatures and hybrid KEMs are the right first step. Pure PQC adoption can wait for ecosystem maturity. 6. **Schedule classical key retirement.** Once PQC keys are operationally stable, plan the retirement of classical keys per CNSA 2.0 or your applicable regime. ## CNSA 2.0 Alignment US government deployments under CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) have prescribed algorithm choices for post-quantum cryptography. nShield deployments serving CNSA 2.0 customers must align with the suite: - ML-KEM-1024 for asymmetric key establishment - ML-DSA-87 for digital signatures (or LMS/SLH-DSA for software and firmware signing) - AES-256 for symmetric encryption (already CNSA 2.0 compliant) - SHA-384 for hashing in most contexts Entrust's nShield product line targets these segments, so CNSA 2.0 alignment is a primary roadmap driver. Operators in CNSA 2.0 environments should track the specific firmware versions and FIPS 140-3 algorithm certificates that cover the prescribed parameter sets. For non-US deployments, parallel national programs (the UK's CESG, Germany's BSI, France's ANSSI, etc.) have their own algorithm guidance. nShield deployments serving multiple national regulatory regimes need to track each program separately. ## Network HSM Throughput Considerations A network HSM typically serves many client applications simultaneously. The aggregate throughput across all clients drives the deployment size. PQC migration affects throughput in two ways: 1. **Per-operation cost.** ML-DSA-65 signing is slower than ECDSA P-256 signing on the same hardware. The exact ratio depends on the firmware optimization. 2. **Hybrid operation cost.** Hybrid operations perform both classical and PQC signing or encapsulation. The cost is roughly the sum of both operations. For a deployment that handles 10,000 ECDSA signatures per second across a cluster of nShield Connect units, the migration to ML-DSA-65 hybrid mode might require expanding the cluster to maintain throughput. Operators should benchmark before committing to a migration timeline. ## CodeSafe and Custom Algorithm Variants The CodeSafe sandbox lets customers deploy variants of standard algorithms that are not in the main firmware. Use cases include: - Deterministic ML-DSA where the firmware ships only randomized - Specific hybrid composition rules that match an application protocol - Performance-tuned implementations for very high throughput - Pre-standard algorithms during transition periods CodeSafe binaries are signed by the customer with a CodeSafe signing key. The HSM verifies the signature before loading the binary. This integrity check ensures that only customer-approved code runs in the sandbox. For PQC purposes, CodeSafe is a useful escape valve. If the firmware does not yet expose a specific algorithm or parameter set, a CodeSafe binary can fill the gap. The cost is the loss of FIPS 140-3 validation coverage for the CodeSafe portion. ## Cross-Organization Interoperability Many nShield deployments are part of multi-organization environments where keys need to be exchanged with partners. Examples: - Code-signing keys shared between OEMs and component vendors - Document-signing keys used in cross-organization workflows - Federation root keys shared across multiple organizations PQC migration in these contexts requires coordination across organization boundaries. The participating organizations must: - Agree on the algorithm choice - Agree on the migration timeline - Test interoperability with each other's HSM platforms - Update any contracts or service-level agreements that reference specific algorithms Cross-organization coordination is the slowest part of any large PQC migration. ## Common Operational Pitfalls Operators rolling out PQC on nShield should watch for: - **Backup file size changes.** PQC keys produce larger backup files. Tape and cloud backup procedures may need updating. - **Application client compatibility.** Older PKCS#11 clients may not understand PQC mechanism identifiers. Test the client library version. - **Performance differences.** ML-DSA signing is slower than ECDSA on the same hardware. Code-signing pipelines that assume ECDSA timing may need rebalancing. - **Logging and audit changes.** PQC operations may generate different audit log entries. Update SIEM rules to account for the new event types. ## Frequently Asked Questions **Does Entrust nShield support post-quantum cryptography today?** Recent firmware versions add ML-KEM and ML-DSA as available algorithms for new key types. Specific availability depends on the model and firmware revision. Check Entrust release notes for current status. **Can I run my own PQC code inside the HSM via CodeSafe?** Yes. CodeSafe lets you deploy sandboxed binaries inside the HSM boundary. The downside is that custom CodeSafe code does not inherit FIPS 140-3 validation. **What about FIPS 140-3 validation for the PQC algorithms?** Entrust submits firmware revisions for CMVP validation. Check the NIST CMVP active modules list for the specific firmware version and confirm the algorithm certificate covers what you need. **Should I migrate to nShield 5 to get PQC?** Not necessarily. Older nShield Connect and Solo models receive firmware updates that include PQC algorithms. The nShield 5 platform has more compute headroom but is not strictly required for PQC support. **Can I use hybrid signatures today on nShield?** Yes, either by composing two operations at the application level or, where firmware exposes it, via a native hybrid type. ## Sources 1. Entrust. "nShield HSM Product Documentation." https://www.entrust.com/products/hardware-security-modules 2. Entrust. "CodeSafe Developer Documentation." Entrust support portal. 3. NIST. "FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard." 2024. 4. NIST. "FIPS 204: Module-Lattice-Based Digital Signature Standard." 2024. 5. NIST CMVP. "Cryptographic Module Validation Program Active Modules." https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules 6. NIST. "Post-Quantum Cryptography Standardization." https://csrc.nist.gov/projects/post-quantum-cryptography ## Related Articles - [HSM PQC Overview](hsm-pqc-overview.md) - [ML-KEM Explained](ml-kem-explained.md) - [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa.md) - [Hybrid Encryption](hybrid-encryption.md) - [Harvest Now Decrypt Later](harvest-now-decrypt-later.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)