What does MIC stand for?
| Full form | Mandatory Integrity Control |
|---|---|
| Category | Technology & computing |
| Type | Initialism |
The initialism MIC stands for Mandatory Integrity Control in Windows security. It adds integrity-level and mandatory-policy checks to access control for securable objects.
Windows integrity levels describe a protection relationship; they are not a synonym for a user’s name, a file extension or a malware verdict. Microsoft explains MIC alongside discretionary access control: a discretionary permission allowing a write does not by itself override the mandatory integrity check. In the documented example, a low-integrity principal cannot write to a medium-integrity object even when the object’s DACL allows that write. This gives a useful way to read a simplified permission note: keep the requested operation, the principal level, the object level and the applicable policy together. It also sets a limit on what can be concluded. If the integrity comparison does not block a hypothetical operation, that does not establish that every other access check permits it. A matching level is not a complete permission grant. Likewise, a low-integrity label alone does not prove that a particular program is malicious. The exercise below uses supplied fictional records to distinguish mandatory-policy and discretionary-permission statements. It performs no Windows access check, reads no security token and changes no permissions. For an actual application, the complete access-control and token context must come from its own diagnostic evidence. Direction matters in the simplified rule. A medium-to-low write is not an upward write, so a supplied no-write-up rule does not block it for that reason. This limited comparison still does not grant a real operation or decide unspecified checks.
Meaning in context
- Mandatory
- The integrity-policy check is additional to the discretionary permissions described by a DACL.
- Integrity Control
- Integrity levels and policy constrain specified operations; the label alone is not a malware classification.
Practical examples
Read both permission layers
- Before
Invented exercise: low-integrity principal, medium-integrity object, no-write-up policy, DACL allows write. Draft: The DACL line proves write access.
- After
Under the supplied no-write-up policy, the low-to-medium write is blocked by the integrity check despite the stated DACL allowance.
The example applies the declared operation, levels and policy. It does not inspect a real Windows object.
Do not turn one passing check into a final grant
- Before
Invented exercise: principal and object are both medium integrity; no DACL outcome is supplied. Draft: Matching levels prove the write succeeds.
- After
Matching levels alone do not supply the missing discretionary-permission result or a final write outcome.
A conclusion about one comparison does not answer every other access-control check.
Original illustrative examples, not quotations or reports of actual events.
Which access conclusion follows?
Why can a supplied DACL allow statement be insufficient to establish write access across integrity levels?
See all guidance
Read a denial note
Retain the operation and both integrity levels.
The supplied note concerns a low-to-medium write.
Compare permission layers
Do not treat a DACL allowance as overriding mandatory policy.
The toy no-write-up rule still applies.
State an uncertainty
Identify the missing access-check evidence.
Equal integrity levels do not supply a missing DACL result.
Keep integrity policy and discretionary permission separate; passing one stated check does not establish the final access result.
Help improve this entry
Spot a mistake or have a clearer example? Suggest a change.
By AcronymIndex Editorial Team · Editorial policy