Windows Integrity Levels are Mandatory Integrity Control labels that restrict how processes and objects interact on a Windows system. Lower-integrity processes should not modify higher-integrity objects, so defenders use them to limit browser, document, and app impact. Misconfigurations or bypasses can let low-trust code write to protected resources or escalate actions.
What Windows Integrity Levels Do
Windows Integrity Levels are part of mandatory integrity control, a Windows mechanism that adds a trust boundary on top of normal permissions. They help stop lower-trust processes from writing into higher-trust objects, which makes them especially useful for protecting browsers, document handlers, and other user-facing apps from unintended influence.
In practice, integrity levels are about write-up prevention: a low-integrity process can often read shared resources, but it should not be able to change a higher-integrity object unless an explicit exception exists. That simple rule helps contain code that comes from the web, attachments, preview panes, scripts, or sandboxed application contexts.
How Mandatory Integrity Control Works
Integrity labels sit alongside the access checks Windows already performs. A process may have the right user token, group membership, or file permission and still be blocked if its integrity level is too low for the target object. This is why MIC is useful as a second layer rather than a replacement for ACLs.
The model is easiest to understand as a hierarchy. Higher-integrity contexts can generally interact with lower-integrity resources more freely than the reverse. That asymmetry is what makes the control valuable for limiting accidental modification, privilege crossing, and some classes of post-exploitation movement.
Because the mechanism is label-based, it only works well when applications and administrators apply those labels consistently. If important objects are left at an unexpectedly low level, or if a process is launched with a higher label than intended, the control can lose much of its containment value.
Where Integrity Levels Matter Most
Windows integrity levels are most useful where a trusted desktop environment needs to absorb untrusted content without letting that content steer the host. Common examples include browser sandboxes, document viewers, download folders, temporary workspaces, and application components that handle externally supplied data.
They also matter in environments that rely on layered defenses. Integrity levels are not a full sandbox, not a malware prevention system, and not a substitute for application hardening. They are one control in a broader containment strategy that reduces the blast radius of code that already has some execution capability.
For readers building Windows hardening baselines, Windows Endpoint Hardening Guide shows how integrity controls fit alongside ASR rules, Credential Guard, tamper protection, and other endpoint protections.
Common Failure Modes and Operational Limits
Integrity controls can be undermined by misconfiguration, overly broad exceptions, or application components that are allowed to interact with objects at a higher trust level than necessary. They can also be bypassed indirectly when a higher-integrity helper process exposes a writable interface to lower-trust code.
Another important limit is that MIC protects object modification, not every possible abuse path. A low-integrity process may still be able to read information, trigger allowed actions, or influence higher-trust software through channels that do not depend on direct writes. That means defenders should treat integrity levels as containment, not as a complete trust model.
Application control can reinforce this boundary. If you are deciding how to keep untrusted code from running at all, Application Allowlisting Guide provides a complementary path through WDAC, AppLocker, and managed installer controls.
Risk and Threat Considerations
Windows Integrity Levels reduce the impact of low-trust code, but they become dangerous when defenders assume the label alone is enough. If a low-integrity browser, script, or document preview process can still reach a writable protected object, the attacker gains a path to persistence, tampering, or controlled escalation within the user session.
Failure mechanism: Weak label assignment, overly permissive helper processes, or a bypass that crosses the integrity boundary can turn a containment control into a false sense of isolation. Once that boundary fails, the attacker can modify files, alter settings, or stage follow-on actions from a foothold that was supposed to be constrained.
Impact: The main consequence is blast-radius expansion. A compromise that should have stayed confined to low-trust content can reach higher-value objects, user workflows, or sensitive local state, increasing the chance of persistence, privilege abuse, or broader host compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-10 — Malware Defenses | MIC helps contain malicious code execution and limit post-infection impact on Windows endpoints. |
| Recommendation — Apply CIS-10 safeguards to reduce malware execution paths and contain impact with layered endpoint defenses. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Integrity levels enforce a practical write-restriction layer that supports least-privilege access decisions. |
| SI-3 — Malicious Code Protection | MIC is relevant where containment reduces the effect of untrusted or malicious code on Windows objects. | |
| Recommendation — Enforce AC-6 to restrict process capabilities and minimize write access across trust boundaries. Use SI-3 to limit malicious code impact and block unsafe modification of protected resources. | ||
| ISO/IEC 27001:2022 | A.8.7 — Protection against malware | Integrity levels support host hardening against malicious or untrusted code modifying protected assets. |
| Recommendation — Implement A.8.7 to reduce malware impact through layered host protection and containment. | ||
| NIST CSF 2.0 | PR.AA-05 — Least privilege | MIC operationalizes least-privilege behavior by preventing lower-trust processes from writing upward. |
| Recommendation — Apply PR.AA-05 to constrain process and application actions to the minimum required trust level. | ||
Practitioner Guidance
Why practitioners should care: Integrity levels are most effective when they are treated as part of endpoint containment design, not as a standalone security feature. Their value comes from making the default path safer for untrusted content while preserving normal productivity for trusted code.
What to watch for: Review whether applications that handle web content, attachments, or previews are running with the lowest practical integrity level and whether any object they touch needs a higher trust label. Pay special attention to exception paths, shared folders, helper processes, and administrative workflows that may silently defeat the boundary.
Practitioner takeaway: Use integrity levels to constrain what low-trust code can change, then verify that higher-trust helpers and writable resources do not reopen the same attack path you were trying to close.
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 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org