MIG, or Multi Instance GPUs, is NVIDIA’s hardware feature for partitioning supported GPUs into discrete instances with compute and memory isolation. It is designed for stronger separation than time slicing. The article notes it is available on A100 and H100 GPUs, and each workload receives a configured slice rather than arbitrary fractional sharing.
What MIG Does in GPU Infrastructure
MIG, or Multi Instance GPUs, is a hardware partitioning feature that splits a supported NVIDIA GPU into discrete instances with isolated compute and memory resources. The practical value is that one workload gets a defined slice of the device instead of competing in a shared pool, which improves separation and predictability compared with time slicing.
That makes MIG a capacity and isolation control, not just a scheduling convenience. It is most relevant where multiple tenants, projects, or workloads share high-value GPU infrastructure and the operator wants stronger boundaries between workloads without dedicating a full card to each one.
How MIG Partitioning Changes the Security Model
MIG changes the security model by reducing the blast radius of a noisy or compromised workload on the same physical GPU. Each slice has its own assigned resources, so accidental contention, performance interference, and some cross-workload exposure risks are reduced relative to a purely shared execution model.
It also changes how operators think about isolation. MIG is stronger than simple fractional sharing, but it is still a hardware feature inside a broader platform stack, so the surrounding driver, orchestration layer, and workload permissions still matter. The isolation is granular, yet it does not replace host hardening, tenant separation, or workload governance.
Operational Use Cases and Trade-Offs
MIG is useful when you need repeatable GPU allocation for inference, analytics, simulation, or other workloads that do not need a whole GPU but still need predictable access. It helps operators standardise slices so capacity planning is clearer and oversubscription is less likely to create unpredictable interference.
The trade-off is flexibility. Once a GPU is partitioned, the available slice sizes and placement rules constrain how you pack workloads. That can improve control, but it can also leave fragments of capacity that are harder to use efficiently if demand is uneven or rapidly changing.
In practice, MIG is best understood as part of a resource-isolation strategy. It improves separation at the GPU layer, but it does not solve application-level trust, data handling, or identity and access decisions around who may submit or control workloads.
Why MIG Matters for Shared GPU Environments
For shared GPU platforms, MIG is important because the GPU is often a concentrated asset: many teams, jobs, or services may depend on it at once. Partitioning reduces the chance that one workload can monopolise the full device or create unpredictable interference for others, which is especially valuable in multi-tenant or platform-as-a-service environments.
It also helps security and operations teams reason about separation of duties. By making the allocation explicit, MIG supports clearer ownership of GPU slices, more consistent scheduling policy, and a narrower operational scope when troubleshooting performance anomalies or workload interference.
Risk and Threat Considerations
MIG lowers exposure from shared GPU contention, but it does not eliminate all cross-workload risk. The main concerns are misconfiguration, weak tenant isolation around the GPU stack, and assumptions that hardware partitioning alone is sufficient to protect sensitive workloads.
Failure mechanism: A workload is placed in a partitioned GPU environment with the wrong slice size, placement, or surrounding access controls, allowing interference, capacity starvation, or broader isolation failure at the platform layer.
Impact: Sensitive workloads may experience degraded performance, reduced availability, or unwanted proximity to other tenants, and operators may incorrectly trust the hardware boundary while overlooking the rest of the control plane.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-3 — Security Function Isolation | MIG is a hardware isolation mechanism that separates GPU workload execution paths. |
| CM-6 — Configuration Settings | MIG depends on correct device and platform configuration to enforce partitioning safely. | |
| AC-6 — Least Privilege | GPU slice allocation should limit which workloads and operators can access shared GPU capacity. | |
| Recommendation — Use SC-3 to isolate GPU workloads with partitioning and containment boundaries. Apply CM-6 to standardise MIG configurations and prevent unsafe GPU partition settings. Apply AC-6 to restrict who can allocate, attach, and operate MIG partitions. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | MIG requires governance over who may provision and use shared GPU capacity. |
| Recommendation — Use CIS-6 to control assignment and use of partitioned GPU resources. | ||
| NIST CSF 2.0 | PR.AA-05 — Asset Management and Access Enforcement | MIG is about enforcing access boundaries over a shared compute asset. |
| Recommendation — Map GPU partitions and enforce access rules for each MIG-enabled asset. | ||
Practitioner Guidance
Why practitioners should care: Treat MIG as one control in a larger GPU governance model. It is most effective when the organisation also defines who can allocate slices, how workloads are mapped to partitions, and what platform controls enforce tenant separation above the hardware layer.
What to watch for: Confirm that your deployment model, scheduler, and monitoring stack understand MIG-aware placement and reporting. If those layers are blind to partitioning, you can end up with good hardware isolation on paper but weak operational visibility in practice.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org