Entrust nShield HSM - Security World Operations Runbook

1. Lock the Entrust operating model before commands

Entrust nShield HSM is not just a device name on a bill of materials. For an administrator, it is a certified network HSM platform where the Security World model controls key lifecycle, recovery, card-set governance, module trust, and application access.

Request-to-evidence path: application owner raises a use case for PKI, code signing, TLS private-key protection, database encryption, payment support, and high-assurance application signing; security approves purpose and lifecycle; the HSM admin maps Security World, Administrator Card Set, Operator Card Set, RFS, hardserver, module state, and application key protection mode; the app integrates through Security World software, PKCS #11, JCE, CNG/CAPI, and OpenSSL integrations; and the change closes only when audit evidence proves the operation.

Weak answer: "I know HSM stores keys." Strong answer: "I can onboard a Entrust HSM workload with owner, key purpose, interface, access path, HA/recovery plan and audit proof."

2. Entrust architecture objects you must name

Good HSM troubleshooting starts with exact object names. Do not say "the HSM is down" when the failure might be role, partition, key version, provider, network, HA state or audit path.

• Security World: The vendor-specific trust framework that protects keys across creation, use, distribution, and recovery.
• ACS and OCS: Administrator and Operator Card Sets enforce split control for administration and application key use.
• RFS: The Remote File System stores Security World data that clients and modules rely on during recovery and operations.
• hardserver: Client-side service that brokers application requests to nShield modules.
• HSM Pool: PKCS #11 pooling/load-sharing pattern that must be tested for key visibility and failover behavior.
• Audit Log Service: Evidence path for administrative, key-lifecycle, and optional key-usage activity.

Interview signal: name the Entrust-specific control objects first, then explain how they protect key material and separate application responsibility.

3. Onboard one application without guessing

Start with scope: application owner, environment, key purpose, approved algorithm, interface, source host or identity, destination service, firewall or private path, recovery owner, and audit target. For Entrust, the highest-value checks are Security World ID, card-set quorum, RFS path, and hardserver module list.

Integration checklist: install or select the right client/provider, bind the application identity, confirm the key boundary, test one crypto operation, capture the audit record, and document rollback. Connectivity alone is not success.

Production note: if the app can authenticate but cannot use a key, resist creating a replacement key. First prove object ownership, interface compatibility, permission scope, key attributes and audit path.

4. HA, backup and compliance without outage drama

Security World can span multiple nShield modules, and PKCS #11 HSM Pool or load-sharing designs must be validated with module state, key availability, client configuration, and recovery evidence.

Change guardrail: Before firmware, Security World, card-set, or RFS work, capture module status, card-set availability, backup/recovery proof, application test plan, and rollback owner.

Compliance angle: the auditor does not only want a FIPS or PCI phrase. They want key ownership, access approval, dual-control or identity control where required, backup/recovery proof, monitoring, and immutable or signed evidence for sensitive operations.

5. Incident and interview evidence

Certificate authority cannot sign after RFS recovery: The CA host reaches the nShield appliance, but the signing key is not usable after a recovery-server change.

Likely cause: The client is attached to the appliance but not to the expected Security World state, card-set context, or key protection mode.

Evidence ladder: Check hardserver status, module list, Security World identity, card-set availability, key file location, PKCS #11 slot view, and audit-log service output.

Strong interview close: "I would prove the failing layer, make the smallest reversible fix, capture before/after audit evidence, and brief app, security and audit owners." That is the HSM administrator mindset.