How to Evaluate Remote Support Access to an On-Prem GPU Pod

During one security evaluation, operations said that if the on-prem GPU pod failed, the vendor would open a tunnel. The ISSM asked who approves the tunnel, whether the session is recorded, and what files can leave. Nobody had a complete answer.

Day-to-day administration is a different review. This post is about exceptional vendor, OEM, and break-glass access: the paths that appear only when something is already broken.

An on-prem GPU pod can still have a support plane that reaches outside the room. If you cannot name who enters, what they can do, and what can leave, the support-boundary review is unfinished.

Map every remote-support path

Do not begin with a vendor slide that says “secure remote support.” Begin with a path inventory. For every way an outside engineer can reach the pod, record the initiator, whether the path is inbound, outbound, or brokered, who controls the jump host, which identity is used, which planes become reachable, whether a customer must be present, and how the path is disabled after the incident.

Map OEM escalation separately. A Supermicro HGX B300 fault may require a manufacturer session that is not the same as the integrator’s ordinary support tunnel. That escalation must not silently extend access to additional hosts, BMCs, storage, or identity systems. If the OEM path is undocumented, treat it as an open control until it is written down.

Evaluate this inventory alongside on-prem GPU infrastructure for CUI and ITAR. Pacific Intelligent Technologies, Inc. does not make a customer CMMC certified.

Make break-glass a workflow, not a shared credential

Break-glass exists because the normal identity path can fail. The failure mode is turning that emergency into a standing shared password, a vendor-held local account, or an after-hours habit nobody can reconstruct.

Walk a Sev-1 before production. The workflow should name the request, the severity, the customer approver, the time limit, the individual identity used, the immediate terminate action, and the cleanup verification that follows. If two people share one emergency account, you cannot later say who entered.

Test the after-hours path. A workflow that only works when the ISSM is in the building is not a Sev-1 workflow. Decide in advance what happens if session recording is unavailable. If recording cannot start, is the session refused, delayed, or allowed under a written exception? That decision belongs in the runbook, not in the first outage.

Inspect session controls

A recorded session is not a controlled session. Inspect what is recorded—commands, GUI activity, identity, timestamps, and file transfers—and who can access, pause, or delete that recording. Then inspect what the session can actually do.

Ask about clipboard, drive mount, file transfer, shell escape, port forwarding, screen capture, printing, concurrent users, and unmanaged endpoints. A vendor laptop with clipboard and transfer enabled is a different risk than a time-limited session through a customer-controlled jump host.

Prefer a jump host the customer controls, individual identities over shared vendor logins, and a session the customer can terminate immediately. Teams comparing deployment models can keep the mothership comparisons index in view while this review stays on the support plane.

Define what may leave the boundary

Crash dumps, logs, screenshots, telemetry, and support bundles can leave the room even when no one opens a shell. Those artifacts may contain hostnames, user names, job metadata, memory contents, or workload fragments. Treat them as data leaving the boundary, not as vendor housekeeping.

Write an export rule before the first Sev-1. The customer should inspect and approve what leaves. Name who reviews a support bundle, what must be redacted, where the copy is stored, and when it is destroyed.

This is the same boundary question that appears when teams evaluate reserved GPU capacity. The compute may sit on-prem. The support artifacts may not.

Review live evidence, not the sales description

Run a tabletop Sev-1. Watch who requests access, who approves it, which identity is used, which systems become reachable, what can be copied out, and how the path is closed. Disable the tunnel and confirm that access actually disappears. If recording is part of the control, produce a sample recording from the exercise.

If you are evaluating an on-prem GPU pod and want to walk the support-boundary map with Pacific, book 30 minutes with Harper. Bring the proposed vendor paths, the break-glass workflow, and one sample support-bundle policy. Do not put controlled details in a website form.

FAQ

Does a vendor need standing remote access to support an on-prem GPU pod?

No. Standing access should be a specific risk decision, not the default. Prefer customer-authorized, time-limited sessions with an individual identity, a named approver, and an immediate terminate path. If standing access is required, document why and constrain the reachable planes.

Is session recording enough to approve a support tunnel?

No. Recording without clipboard, transfer, port-forward, and jump-host controls still leaves a wide capability. Recording that can be paused or deleted by the vendor is also incomplete. Treat recording as evidence, not as the control itself.

Are crash dumps and support bundles “data leaving”?

They can be. Dumps, logs, screenshots, telemetry, and bundles may contain hostnames, users, job metadata, memory, or workload fragments. Require customer inspect-and-approve before export, and name how those copies are destroyed afterward.

Does placing the GPUs on-prem eliminate remote-support risk?

No. On-prem compute can still be reached through vendor tunnels, OEM escalation, BMC paths, and exported artifacts. Evaluate those paths the same way you would evaluate any other privileged entry. Start from Pacific Intelligent Technologies, Inc. if you need the broader infrastructure model behind the pod.

Does this evaluation make an organisation CMMC certified?

No. A documented support boundary can help you operate inside a declared environment, but certification depends on the customer’s systems, policies, people, scope, evidence, and assessment. Pacific Intelligent Technologies, Inc. provides infrastructure, including on-prem GPU infrastructure for CUI and ITAR, not certification itself.

Map every remote-support path, turn break-glass into a workflow, inspect session controls, define what may leave, and prove the path with a live Sev-1. A vendor tunnel that nobody can explain is an open boundary.