| Mandatory Integrity Control | |
|---|---|
| Name | Mandatory Integrity Control |
| Introduced | Windows Vista |
| Developer | Microsoft |
| Operating systems | Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 10, Windows 11 |
| Type | Process and object access control |
| Influenced by | Windows NT architecture, Access Control List, Security Account Manager |
Mandatory Integrity Control
Mandatory Integrity Control is a security mechanism introduced in Windows Vista to provide an additional layer of access restriction by assigning integrity levels to processes, objects, and tokens. It complements Discretionary Access Control models used by Windows NT architecture and interacts with features such as User Account Control and Security Account Manager to limit the ability of lower-integrity subjects to modify higher-integrity objects. Designed to mitigate privilege escalation and untrusted code risks, it is implemented across multiple Windows releases and interacts with kernel subsystems, the Security Reference Monitor, and Windows API surfaces.
Mandatory Integrity Control augments traditional Access Control List mechanisms by introducing integrity labels that are checked by the Security Reference Monitor at access time. Instead of relying solely on identity-based permissions stored in Security Descriptors, integrity labels represent trustworthiness tiers such as low, medium, high, and system. The model is mandatory because the operating system enforces checks regardless of owner-desired settings, similar in spirit to Mandatory Access Control schemes used in SELinux and AppArmor but tailored to the Windows NT architecture and its compatibility goals. Its introduction coincided with broader security initiatives in Windows Vista and later refinements across Windows 7 and Windows 10.
The architecture places integrity labels into the integrity field of a subject's token and into object's Security Descriptor through a special integrity ACE. The Security Reference Monitor evaluates integrity levels during handle creation, access checks, and privilege escalation attempts. Processes inherit integrity from their parent or are assigned by launch policies such as User Account Control elevation prompts; services launched by Service Control Manager may receive elevated labels. Object types impacted include files, registry keys, named pipes, and processes—managed by kernel components like the I/O Manager and Object Manager. The enforcement policy typically denies write or modify access when a subject's integrity is lower than the object's, implementing a "no-write-up" rule analogous to classic Bell–LaPadula properties adapted for Microsoft platforms.
Default integrity levels include Low, Medium, High, and System; supplemental labels such as Untrusted and Protected Process light augment policy. Low is used for sandboxed contexts like Internet Explorer Protected Mode or Microsoft Edge sandboxed processes; Medium is typical for standard interactive users authenticated via Security Account Manager credentials; High is applied when User Account Control prompts result in elevation; System corresponds to core Windows services and kernel-mode proxies. Integrity labels are represented by Security Identifiers (SIDs) in the form of integrity SIDs and can be observed in tools that parse Security Descriptors or process tokens, interacting with Access Control Entry semantics while remaining distinct from Access Control List identities.
Mandatory Integrity Control works alongside User Account Control to constrain elevated and unelevated tokens: UAC creates secondary tokens with different integrity levels to implement the principle of least privilege for interactive logons. When a user consents to elevation through UAC, the process receives a High integrity label and associated privileges; without consent, spawned processes remain at Medium. This interaction reduces reliance on permanent administrative tokens and complements Privilege management features such as SeDebugPrivilege and service isolation policies enforced by Service Control Manager. Because integrity labels are enforced regardless of ACL settings, even accounts in privileged Administrator groups can be restrained by a lower integrity label until elevation occurs.
Mandatory Integrity Control mitigates a range of attack vectors by preventing lower-integrity processes from modifying higher-integrity objects, thereby reducing the impact of drive-by downloads, browser-based exploits, and lateral tampering. It is widely used in sandboxing strategies for Internet Explorer Protected Mode, Office document viewers, and application containers to isolate untrusted content. System hardening products, endpoint protection suites, and Windows Defender components leverage integrity levels to limit code execution paths. However, designers must combine integrity controls with correct ACLs and privilege hygiene to achieve defense in depth; integrity labels provide containment but are not a substitute for proper authentication mechanisms like Kerberos or NTLM where applicable.
To preserve compatibility with existing applications, integrity enforcement is additive: legacy applications that do not set or check integrity labels continue to operate under default inheritance rules. Developers can query and set integrity levels via Windows API calls such as SetTokenInformation and by manipulating integrity ACEs in security descriptors. Certain object managers expose integrity attributes through native APIs and tools like Sysinternals utilities or the Microsoft Management Console. Backwards compatibility considerations influenced the choice to implement integrity as SIDs and ACEs so that traditional ACL parsers can ignore or accept integrity metadata without breaking behavior for older Windows components.
Critics note that Mandatory Integrity Control provides coarse-grained containment compared with multi-level mandatory models like SELinux or Trusted Solaris, offering primarily a "no-write-up" policy without comprehensive label-based information flow controls. Misconfigurations, developer misconceptions, and inconsistent application of integrity labels can create false senses of security; attackers who can escalate to High integrity or exploit trusted components can bypass controls. Some third-party software and legacy drivers that assume full privilege may malfunction under strict integrity policies, necessitating exceptions or shims. Finally, integrity labels do not replace cryptographic attestation or code signing systems such as AuthentiCode in preventing code origin forgery.