How to Evaluate Tenant Crypto Separation on Shared Management Planes

Consider an illustrative diligence session: a vendor demonstrates separate tenant dashboards and encrypted storage. Then a security reviewer asks the management-plane service account to decrypt a test object belonging to another tenant. The request succeeds because the backend trusts a caller-supplied tenant identifier.

The dashboards were separate. The cryptographic authority was not.

For founders evaluating an on-prem GPU pod, that distinction matters more than a slide labeled “tenant isolation.” The review question is concrete: Can any identity acting for Tenant A use, issue, export, or redirect cryptographic material belonging to Tenant B?

1. Map the crypto boundary—not just the tenant label

Start with two synthetic tenants and a diagram showing how each reaches the shared management plane, KMS or HSM, certificate authority, and encrypted resources.

For each tenant, identify:

• Key domains and the policies enforcing them.
• Workload and management-service identities.
• Certificate issuers, issuance profiles, and trust stores.
• Shared administrators, automation, and recovery services.
• Backup or restore paths that can move cryptographic material.

A key-name prefix is not a security boundary. Neither is a separate dashboard. Ask where authorization happens and whether tenant identity comes from authenticated context rather than editable request fields.

On a Supermicro HGX B300 deployment, include the services managing the GPU hosts—not just applications running on them. Hardware choice alone does not establish tenant crypto separation.

Network isolation governs reachability. Crypto separation governs whose authority can be exercised even when services share a reachable management endpoint.

2. Inspect HSM/KMS tenancy and cross-tenant privileges

Ask the operator to show how tenant boundaries are enforced: separate KMS accounts, policy-isolated key domains, HSM partitions, or another documented mechanism. Shared hardware is not automatically disqualifying, but the enforcement model must be explicit.

Review effective permissions, including inherited roles and backend service identities. Test whether a Tenant A principal can:

• Discover or describe Tenant B’s keys.
• Decrypt, unwrap, sign, or generate data keys using them.
• Create grants or change policies permitting later access.
• Export, replicate, back up, or restore key material across domains.

Discovery and cryptographic use are different risks; record both rather than treating them as equivalent.

Pay special attention to the shared orchestrator. A service authorized across tenants can become a “confused deputy” if it accepts a tenant or key reference without validating the caller’s entitlement. Require server-side authorization at the resource boundary.

Keep this review distinct from general GPU pod key-management ownership: knowing who rotates a key does not prove another tenant cannot use it.

3. Trace certificate issuance and trust paths

Keys may be separated while certificate issuance remains dangerously broad.

Request an issuance walkthrough for tenant workloads and management agents. Identify who can request certificates, which identities approve them, and how allowed names, subject alternative names, usages, and lifetimes are constrained.

Then test a specific abuse case: can Tenant A obtain a certificate naming Tenant B’s service or an identity accepted by Tenant B?

Separate intermediate authorities can help define boundaries, but they are not sufficient if every tenant trusts every intermediate without identity restrictions. Conversely, a shared authority needs demonstrable issuance controls and relying-party authorization.

Include renewal and revocation. Check whether shared automation can renew another tenant’s certificate, substitute its public key, or alter trust bundles. Successful TLS authentication should not silently become cross-tenant authorization.

4. Demand negative tests and privileged-path evidence

Run tests in an approved, nonproduction environment using synthetic keys and data. Capture the requesting identity, tenant context, target resource, attempted operation, decision, timestamp, and enforcing component.

A useful evidence packet includes:

• Tenant A attempting decrypt and sign operations against Tenant B’s keys.
• A management API request with a substituted tenant identifier.
• An issuance request for another tenant’s certificate identity.
• A tenant administrator attempting to grant cross-tenant access.
• A restore attempt targeting the wrong tenant domain.

A denied frontend request is insufficient if the backend service can still perform the operation without equivalent checks.

Separately inspect shared platform administrators. Can they rewrite KMS policy, replace an issuer, impersonate workloads, or reassign tenant mappings? If so, document that retained authority and its controls. Do not describe the boundary as cryptographically inaccessible to the operator when administrative changes can defeat it.

For security and ISSM review, request policy exports, identity mappings, test results, and architecture versions. Pacific’s CMMC-focused deployment context can inform the broader evaluation, but these artifacts are inputs to review—not a compliance determination.

5. Turn findings into a bounded pilot decision

Before expanding the pilot, record three outcomes:

• Demonstrated: tenant-scoped identities cannot exercise another tenant’s crypto authority through tested paths.
• Conditional: shared privileged identities retain documented capabilities requiring reviewer acceptance.
• Unresolved: enforcement or evidence is missing; expansion waits for retesting.

Assign an owner and retest trigger to each exception. Changes to orchestrator roles, KMS tenancy, certificate profiles, or restore tooling should reopen the relevant checks.

Review Pacific’s GPU capacity options alongside the proposed management architecture; capacity availability does not establish isolation. For a scoped discussion with Pacific Intelligent Technologies, Inc., schedule a 30-minute evaluation call and bring the boundary diagram and unresolved tests.

FAQ

Does every tenant need a dedicated HSM?

Not necessarily. Evaluate the isolation mechanism, effective permissions, and shared administrative authority. Require evidence rather than inferring separation from physical dedication alone.

Does this replace network-isolation diligence?

No. Tenant network-boundary evaluation addresses reachability and traffic separation. This checklist addresses cryptographic authority across shared services.

Where should we start with Pacific?

Use the Pacific Intelligent Technologies overview for deployment context and the CMMC evaluation context to frame questions for your security and ISSM reviewers. Ask for evidence tied to the specific proposed architecture.