A Windows security mechanism that limits what processes can do based on integrity level, such as low, medium, or high. It adds a trust boundary inside the same user session so sandboxed applications cannot freely interact with more trusted objects or processes.
How Windows Mandatory Integrity Control Works
Windows mandatory integrity control, or MIC, is a process isolation mechanism that assigns integrity levels to objects and processes, then blocks lower-trust code from writing to or controlling higher-trust targets. It creates a trust boundary inside a single Windows session, so a browser tab, preview pane, or other sandboxed component cannot freely act on more sensitive content.
MIC is not the same as permissions in the usual access-control sense. A user may still have credentials to open a file or start a process, but the integrity check adds a second rule: low-integrity code can be prevented from modifying medium- or high-integrity resources even when the user context would otherwise allow it. That makes MIC especially important for reducing the blast radius of untrusted code.
Integrity Levels and Trust Boundaries
Integrity levels express relative trust, not user rank. In practice, low integrity is commonly used for sandboxed internet-facing code, medium integrity for standard desktop applications, and high integrity for elevated administrative processes. The key idea is that trust flows upward only in tightly controlled ways, while write-up or action-on-higher-trust-object is blocked by default.
This design is useful because many attacks do not need full compromise of the operating system. They only need a foothold in a less trusted process, then a path to tamper with a more trusted one. MIC narrows that path by making the trust boundary explicit and enforced at the object interaction level.
Because MIC is a boundary inside the same logon session, it works best when paired with other Windows protections, such as application sandboxing and privilege separation. It is a containment control, not a replacement for authorization or administrative discipline.
Where MIC Adds Security Value
MIC matters most when different classes of code coexist on the same desktop or server and not all of them deserve the same level of trust. That includes browsers, document viewers, plugins, automation helpers, and other software that may process untrusted input but still needs limited access to the local system.
It also helps explain why some compromise chains stop at limited impact. If malware lands in a low-integrity context, MIC can prevent it from altering higher-integrity objects, injecting into more trusted processes, or writing to locations that would enable persistence or escalation. For a broader view of how attackers try to cross that boundary, see MITRE ATT&CK Enterprise Matrix.
MIC is often most visible when users notice that a process can read something but cannot save back to it, or when a sandboxed feature works normally until it tries to interact with a protected object. That behavior is deliberate, and it is one of the ways Windows reduces unintended trust between components.
Common Limitations and Failure Modes
MIC is only one layer in the Windows security model, so it does not stop every kind of abuse. If a trusted process itself is compromised, MIC may do little to help because the attacker is already operating from the higher-integrity side of the boundary. Likewise, if a design wrongly places powerful functionality in a medium or high integrity context, MIC cannot compensate for excessive trust in the application architecture.
It can also be misunderstood as a generic permission system. In reality, MIC is about controlling which integrity level may influence which object, not about replacing file ACLs, least privilege, or careful elevation management. For practical defense, treat it as a containment control that complements broader privilege boundaries.
Risk and Threat Considerations
Windows Mandatory Integrity Control reduces the damage a lower-trust process can do, but weak sandbox design or a compromised high-integrity process can still defeat the intended boundary. The main risk is assuming that a low-integrity label alone makes software safe, when the real exposure depends on what the process can reach, invoke, or trick into acting on its behalf.
Failure mechanism: An attacker gains code execution in a constrained process, then looks for trusted helpers, writable higher-integrity targets, or confused-deputy paths that let the lower-trust component influence a more privileged one.
Impact: If the boundary is bypassed or misapplied, the result can be tampering, persistence, privilege escalation, or broader compromise of objects that were meant to remain isolated from untrusted code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | MIC enforces reduced authority between integrity levels, reinforcing least privilege. |
| IA-9 — Service Identification and Authentication | MIC often protects interactions among processes and services with differing trust. | |
| Recommendation — Apply AC-6 to limit what lower-trust processes can do to higher-trust objects. Use IA-9 to authenticate trusted process-to-process interactions before they cross trust boundaries. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | MIC is a trust-boundary control that supports enforced access separation. |
| Recommendation — Map integrity boundaries into access-control design so low-trust code cannot act as higher-trust code. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | MIC is a Windows access-control mechanism that constrains write and interaction paths. |
| Recommendation — Use CIS-6 to separate trust levels and restrict access paths between them. | ||
| MITRE ATT&CK | T1068 — Exploitation for Privilege Escalation | MIC is relevant where attackers seek to break out of lower trust into higher privilege. |
| Recommendation — Map MIC bypass attempts to privilege-escalation detection and hardening efforts. | ||
Practitioner Guidance
What to watch for: Treat MIC as effective only when the application architecture matches the intended trust boundary. Sandboxed components, helper processes, and elevation paths should be reviewed together so a low-integrity process cannot rely on an overly trusted companion to perform unsafe actions on its behalf.
Practitioner takeaway: MIC is strongest when it is used to enforce real separation of trust, not as a substitute for secure design or least privilege elsewhere in the stack.