Mandatory Integrity Control is a Windows mechanism that labels processes and objects with integrity levels such as low, medium, and high. It is designed to restrict how lower-trust code interacts with higher-trust resources, but it does not by itself govern every launch, activation, or protocol path across the operating system.
Expanded Definition
Mandatory Integrity Control, or MIC, is a Windows trust-boundary feature that assigns integrity labels to processes and securable objects, then blocks lower-integrity code from writing to or modifying higher-integrity targets. In practice, it is one layer in a broader access model rather than a complete authorization system.
In NHI and agentic environments, MIC matters because service hosts, automation runners, and browser-based control planes may execute code at different trust levels on the same system. That makes MIC useful for reducing write-up risk, but it does not replace NIST Cybersecurity Framework 2.0 discipline around identity, access, and recovery. Definitions vary across vendors when MIC is discussed alongside sandboxing, User Account Control, or application hardening, so it is best treated as a privilege boundary with a narrow enforcement scope. For background on how this fits into broader NHI risk reduction, see Ultimate Guide to NHIs — Standards.
The most common misapplication is assuming MIC prevents all risky launches or protocol paths, which occurs when teams confuse integrity labels with full application control or network authorization.
Examples and Use Cases
Implementing MIC rigorously often introduces operational friction, because lower-trust automation may lose the ability to write logs, update files, or trigger follow-on tasks, forcing teams to weigh containment against workflow breakage.
- A browser helper process runs at low integrity so injected content cannot modify the signed desktop automation agent, limiting the blast radius of a compromised session.
- A build runner writes artifacts to a medium-integrity staging area while a higher-integrity signing service keeps release keys isolated from direct modification.
- A Citrix or remote desktop session opens untrusted attachments in a low-integrity viewer, reducing the chance that the content can tamper with the host profile.
- An internal service account launches a helper process with lower integrity to handle untrusted inputs before handing sanitized output back to the main workflow.
- Teams map MIC behavior to NHI governance patterns when application trust tiers and credential handling need to be separated on the same endpoint.
MIC is most effective when paired with platform guidance such as NIST Cybersecurity Framework 2.0, because the control is about containment, not identity lifecycle or privilege assignment.
Why It Matters in NHI Security
MIC becomes relevant when non-human identities operate on shared Windows hosts that also process untrusted inputs, because integrity boundaries can limit how far a compromised automation component can reach. That matters in environments where secrets, tokens, and signed binaries coexist on the same machine, since a low-integrity process should not be able to alter higher-trust configuration or credential material.
The broader NHI risk context is severe: NHIs outnumber human identities by 25x to 50x in modern enterprises, and 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs — Standards from NHI Mgmt Group. MIC does not fix privilege sprawl, secret exposure, or missing rotation, but it can reduce the damage path when one process is compromised and attempts to write upward into a more trusted workflow. For that reason, it should be viewed as a compensating control inside a larger zero trust program, not as a substitute for identity hardening, JIT access, or secret hygiene.
Organisations typically encounter the need for MIC only after a low-trust process has already modified a privileged automation path, at which point integrity separation becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-04 | MIC supports limiting what lower-trust code can modify, but it is not a full access model. |
| NIST Zero Trust (SP 800-207) | PA-1 | Zero Trust requires explicit trust boundaries; MIC is one local boundary control. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Integrity boundaries help reduce blast radius when NHI processes are over-privileged. |
Treat MIC as endpoint segmentation and continue enforcing explicit verification for every access path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
