How to Evaluate Key Management for an On-Prem GPU Pod

The ISSO was told the pod would be air-gapped. The diagram said disks unwrap through a cloud KMS in another region. Another vendor kept a recovery key. Neither fact automatically disqualifies the design. Both change the trust boundary.

An on-prem GPU pod can still depend on keys the customer does not hold. Evaluate who creates, uses, rotates, disables, exports, recovers, and destroys the keys that unlock datasets, model weights, disks, backups, and recovery paths. “Private” is not a key-management answer.

Map the key hierarchy, not the encryption checkbox

A slide that says “encryption at rest enabled” is not a hierarchy. Name the keys for disks, NVMe namespaces, datasets, model weights, backups, scheduler secrets, and the key-encryption keys that wrap them. For each class, record who can create, use, rotate, disable, export, recover, and destroy it.

Separate those classes on purpose. A disk key that unwraps a boot volume is not the same object as a dataset key, and a dataset key is not a weights key. If one recovery material unlocks all three, you have a single vault with three labels, not a hierarchy.

Ask where each key lives at rest, what unwraps it at boot or job start, and what still works if the pod is disconnected. If the answer depends on a service the customer does not operate, write that dependency on the map before you argue architecture.

Compare customer-held HSM with cloud KMS dependencies

Customer-held keys in an on-prem HSM and keys in a cloud KMS can both be operated well. They are not the same trust boundary. The evaluation questions differ.

For an on-prem HSM: can the pod boot and unwrap disks if the building is disconnected? What quorum is required to use or recover keys? Is there a bypass recovery path the HSM vendor or integrator still holds? For a cloud KMS: which account, identity provider, region, and network path must be alive for unwrap to succeed?

If a Supermicro HGX B300 pod cannot decrypt without a hyperscaler KMS, record that. It may still be the right design. It is not an air-gapped design, and it is not customer-held key control. Bring-your-own-key that still unwraps inside a vendor KMS is also not customer-held control.

Evaluate this alongside on-prem GPU infrastructure for CUI and ITAR and the mothership comparisons index. Pacific Intelligent Technologies, Inc. does not make a customer CMMC certified. A key map is evidence of a trust boundary, not a certification claim.

Require ceremony, dual control, and a recovery design

Keys that matter should be born in a ceremony you can describe. Initialization, two-person control, and a rotation path that does not require re-encrypting every dataset on every rotation are operational facts, not ceremony theater.

Name the recovery materials: where they live, who can assemble them, what break-glass looks like when the primary HSM or KMS is unavailable, and how personnel changes revoke a person’s ability to reconstruct a key. If one departed contractor still holds a recovery share, the ceremony already failed.

Destruction is part of the same design. Cryptographic destruction means the key material is gone and the wrapped objects cannot be unwrapped by a leftover copy. Deleting a pointer in a console is not destruction if a backup, HSM clone, or vendor escrow still holds the key.

Ask who can unwrap after you leave

Offboarding sanitization evidence is a different post. This question is narrower: after the engagement ends, who can still unwrap disks, datasets, weights, or backups? If the vendor retains a recovery key, the customer has not left.

Write the exit of key control before workloads arrive. Name which keys the customer holds, which the vendor holds, which a cloud KMS holds, and what destruction or transfer happens at the end of the engagement. Teams evaluating reserved GPU capacity should treat key custody as part of the capacity boundary, not as a later security add-on.

If you are evaluating an on-prem GPU pod and want to walk the key hierarchy with Pacific, start from Pacific Intelligent Technologies, Inc. and book 30 minutes with Harper. Bring the intended unwrap path, the recovery design, and one representative workload. Do not put controlled details in a website form.

FAQ

Is an on-prem HSM always required?

No. An on-prem HSM is one way to keep unwrap inside a declared boundary. A cloud KMS can be acceptable if the dependencies are written down and the program can accept them. The fail is claiming air-gap or customer-held control while unwrap still requires another region’s KMS.

Is BYOK the same as customer-held keys?

No. Bring-your-own-key often still means the vendor or a cloud KMS performs unwrap. Customer-held means the customer controls create, use, rotate, export, recover, and destroy—and can refuse unwrap. If the vendor can still recover the data after you leave, the keys were not customer-held.

Should disks, datasets, and weights share one key?

Usually no. Separate keys let you rotate, revoke, or destroy one class without unlocking the others. Shared recovery material that unwraps all three collapses that separation. Map the hierarchy before you accept a single “cluster key.”

Where does this evaluation sit relative to capacity and architecture choice?

Key custody is a trust-boundary question. Capacity availability is a commercial question on Pacific's GPU capacity page. Architecture comparisons live on the comparisons index. Start from Pacific Intelligent Technologies, Inc. if you need both in one conversation, then book 30 minutes with Harper.

The evaluation rule is straightforward: map the hierarchy, record HSM and KMS dependencies, require ceremony and dual control, and name who can unwrap after you leave. Private racks do not substitute for those four artifacts.