App Control managed installer, ISG and supplemental policies

The App Control for Business pillar guide ends with a policy that trusts Windows, Microsoft-signed code and a scanned snapshot of your software. That policy is correct on day one and wrong on day thirty, when the first application update ships a new unsigned helper or a vendor rotates its signing certificate. Most App Control projects that fail do not fail on security; they fail because the allowlist cannot keep up with change.

Three features exist to solve that: the managed installer, which trusts whatever your deployment tool installs; the Intelligent Security Graph (ISG), which trusts files with good Microsoft reputation; and supplemental policies, which let application owners extend a locked base policy without touching it. This guide covers how each one works under the hood, how to configure it, and where each one weakens your security model.

How the managed installer works

A managed installer is a process you designate as trusted to install software. When that process, or any child process it starts, writes an executable file to disk, Windows stamps the file with a kernel extended attribute (an "origin claim", stored as $KERNEL.SMARTLOCKER.ORIGINCLAIM). When the file later runs, App Control sees the claim and allows it, provided the policy has rule option 13 Enabled:Managed Installer.

Two components cooperate:

• AppLocker designates the installer. A special rule collection, ManagedInstaller, names the trusted binaries. The Application Identity service (AppIDSvc) and its driver do the tagging.
• App Control honours the tags at execution time.

That split matters. If AppIDSvc is stopped, no new files are tagged, and software your deployment tool installs from that point on gets blocked on enforced devices.

Step 1: choose the installer

Pick one tool per device. Designating several installers multiplies what is implicitly trusted, and every designated binary becomes a high-value target: whoever can make it run a payload gets that payload allowed.

The Intune switch only applies to Win32 and other apps delivered through the Intune Management Extension after it is enabled. Store apps and anything a user installs are not covered.

Step 2: deploy the AppLocker side manually (non-Intune)

Microsoft publishes a sample managed installer policy in the App Control documentation; start from it rather than writing XML by hand. Its structure is a ManagedInstaller rule collection containing publisher rules for your installer binaries, plus EXE and DLL rule collections in AuditOnly mode with the services extension enabled so that tagging works for processes running as services.

If you already use AppLocker, merge rather than replace, or you will overwrite your existing rules:

Set-AppLockerPolicy -XmlPolicy .\ManagedInstaller.xml -Merge
sc.exe config appidsvc start= auto
appidtel.exe start -mionly

appidtel.exe start starts the Application Identity tagging components; the -mionly switch enables managed installer tagging without turning on ISG. On a device that is not already enforcing AppLocker, keep the EXE and DLL collections in audit only; the point is tagging, not AppLocker enforcement.

Step 3: turn on option 13 in the App Control policy

The base policy must opt in:

Set-RuleOption -FilePath .\Base.xml -Option 13      # Enabled:Managed Installer
Set-RuleOption -FilePath .\Base.xml -Option 17      # Enabled:Allow Supplemental Policies
Set-RuleOption -FilePath .\Base.xml -Option 3       # Enabled:Audit Mode, during pilot
ConvertFrom-CIPolicy -XmlFilePath .\Base.xml -BinaryFilePath .\Base.cip

Then deploy an application through the installer and check that its files carry the claim:

fsutil file queryEA "C:\Program Files\Contoso\Agent\agent.exe"

A tagged file shows an extended attribute named $KERNEL.SMARTLOCKER.ORIGINCLAIM. No attribute means the file was not written by the installer's process tree, or AppIDSvc was not running at the time.

Step 4: decide whether to use the ISG

Option 14 Enabled:Intelligent Security Graph Authorization allows files that Microsoft's cloud reputation service considers known good. Option 15 Enabled:Invalidate EAs on Reboot makes Windows re-check reputation for ISG-authorised files after a restart, so a file whose reputation drops does not stay trusted forever.

The ISG allows things you never reviewed. That is the point on a sales laptop and the problem on a server. If you enable it, also run appidtel.exe start without -mionly, and treat it as a stepping stone: capture what it allowed from the audit logs and replace that trust with explicit publisher rules over time.

Step 5: delegate with supplemental policies

A supplemental policy adds allow rules to one specific base policy, identified by its policy ID. The base needs option 17 (set above). Build the supplement from the application's install folder:

New-CIPolicy -Level Publisher -Fallback Hash -UserPEs `
  -ScanPath "C:\Program Files\LineOfBusiness" -FilePath .\Supp-LOB.xml
Set-CIPolicyIdInfo -FilePath .\Supp-LOB.xml -PolicyName "Supp - LOB app" `
  -BasePolicyToSupplementPath .\Base.xml
ConvertFrom-CIPolicy -XmlFilePath .\Supp-LOB.xml -BinaryFilePath .\Supp-LOB.cip
CiTool.exe --update-policy .\Supp-LOB.cip

A workable operating model:

• Security owns the base: Microsoft example policy, recommended block rules, the vulnerable driver blocklist, option 13, and deny rules. It changes rarely and, once stable, is signed.
• Application teams own supplements: one per application or business unit, reviewed through a change process, allow rules only.
• Rules stay at publisher level where possible. Hash rules in a supplement mean a new supplement for every release.

If the base policy is signed, supplements must be signed too, or they will not load. Plan your signing process before you sign the base.

What breaks

• Self-updating applications. Browsers, collaboration tools and agents that update themselves write new binaries from their own updater, not from the managed installer. The new files carry no origin claim. Cover these vendors with publisher rules in a supplement instead of relying on the installer.
• Per-user installers. Anything that installs to %LOCALAPPDATA% outside your deployment tool is untagged by design. That is usually what you want to block, but expect tickets.
• Files copied, not installed. Tools that a login script or an admin copies into place were never written by the installer's process tree, so they have no origin claim. Give them their own publisher or hash rules.
• The installer as an attack path. Anyone who can publish an app in Intune or a package in Configuration Manager can now get arbitrary code allowed on every enforced device. Your deployment tool's admin roles become part of your application control boundary; treat them as privileged accounts.
• AppIDSvc disabled by a baseline or a "debloat" script. Tagging silently stops.

Verify it

1. Services: Get-Service AppIDSvc shows Running and start type Automatic on every enforced device.
2. AppLocker side: Get-AppLockerPolicy -Effective -Xml contains a ManagedInstaller rule collection naming your installer.
3. App Control side: CiTool.exe --list-policies shows the base and each supplement as active; event 3099 in Microsoft > Windows > CodeIntegrity > Operational confirms each policy was activated.
4. Tagging: fsutil file queryEA on a freshly deployed binary shows the origin claim.
5. Blocks: event 3076 (audit) or 3077 (enforced) lists what would have run or was stopped. The diagnostic events 3090 to 3092 explain when a file was allowed or blocked by managed installer or ISG; 3090 (allowed purely by managed installer or ISG) is optional and needs reg add HKLM\SYSTEM\CurrentControlSet\Control\CI -v TestFlags -t REG_DWORD -d 0x300 plus a restart, which also turns on 3091/3092 where they are inactive. With a managed installer, 3091 can be very noisy, so filter it before it reaches a paid log store.

Checklist

• One deployment tool designated as managed installer per device
• AppLocker ManagedInstaller rule merged, not overwriting existing AppLocker rules
• AppIDSvc automatic and running; appidtel.exe start executed
• Base policy has options 13 and 17; option 14 only where ISG is a deliberate choice
• Origin claim confirmed with fsutil file queryEA on the pilot
• Self-updating apps covered by publisher rules in supplements
• Supplements owned by app teams, allow rules only, signed if the base is signed
• Deployment tool admin roles treated as privileged access
• Events 3076, 3077 and 3099 forwarded to your log pipeline

With a managed installer and supplements in place, App Control stops being a project and becomes a process. The next step is closing the kernel side with the driver blocklist, and the rest of the application control area covers the per-user controls with AppLocker.