Signed and unsigned App Control policies, and where each belongs
Unsigned policies suit end user devices. Signed policies belong on privileged access workstations and protected servers. Why, and what signing actually costs you.
The question is not whether to sign your App Control policies. It is which devices should have signed policies, and the answer is not the same across a fleet.
Signing does not make a policy stricter. A signed policy and an unsigned policy with the same rules allow and block exactly the same files. What signing adds is protection for the policy itself, and that protection comes with a recovery path that involves physical access to firmware. That trade is worth making on some devices and not on others.
What signing actually protects
Microsoft is direct about the purpose. Signed policies "are designed to detect administrative tampering of the policy, such as by malware running as admin, and will result in a boot failure or blue screen".
That is the whole feature. An attacker who reaches local administrator on a device with an unsigned policy can delete the policy file and reboot. On a device with a signed policy, tampering with it stops the machine booting instead. The policy cannot be quietly removed, because removing it is loud.
Two conditions apply:
- Secure Boot must be enabled. Microsoft states that the protection only applies to computers with UEFI Secure Boot enabled. Without it, signing buys you nothing.
- The protection starts after the first reboot. Anti-tampering takes effect after the first restart once the signed policy is applied. The window between deployment and that restart is not protected.
The certificate rules are not advice
This is the part that breaks devices, so it is worth stating exactly. Microsoft warns that boot failure or blue screen may occur if your signing certificate does not follow these rules:
- All policies, base and supplemental, must be signed according to the PKCS 7 standard.
- RSA keys only, at 2K, 3K or 4K. ECDSA is not supported.
- SHA-256, SHA-384 or SHA-512 as the digest algorithm on Windows 11, and on Windows 10 and Windows Server 2019 and above after the November 2022 cumulative security update. Every other device supports SHA-256 only.
The ECC limitation is worth internalising because it also applies to your rules, not just your policy signature. App Control signer rules only work with RSA. If you try to allow a file by an ECDSA signature you get VerificationError = 23 on the corresponding 3089 event and the file is not allowed.
End user devices: unsigned, with detection
On a managed end user fleet, unsigned policies are the sensible default.
The reasoning is about what you are defending against and what else you have available. The threat signing addresses is a policy being removed by someone or something with administrator rights. On a managed device you can find out that happened, because a policy being loaded and a policy being absent are both observable. Event 3099 tells you a policy has been loaded and its details include the policy options. A device that stops reporting the policy you deployed has told you something.
That is the trade. You give up the guarantee that the policy cannot be removed, and in exchange you keep a recovery path that does not involve a technician touching firmware. On a fleet of tens of thousands of end user devices, where local administrator rights should be rare in the first place, that is the right side of the trade.
It is only the right side of it if you are actually watching. An unsigned policy nobody monitors is a policy that can be removed silently, which is the exact scenario signing exists to prevent. Detecting drift and tampering is the compensating control, and it has to be real. This is one of the things our own agent is for, and it is the reason we recommend unsigned on end user devices rather than treating signing as universally better.
Privileged access workstations and protected servers: signed
The calculation inverts on the devices where a compromise is not recoverable.
A privileged access workstation exists so that administrative credentials are only ever used from a known good machine. A protected server holds something worth the attacker's effort. On those devices the population is small, the change rate is low, the people who use them are the ones who can be told to expect an operational process, and the consequence of an attacker quietly removing execution control is severe.
That is the profile signing is for. Small blast radius, high value, low change rate, and an outcome where "we detected it afterwards" is not good enough.
Practical notes for those devices:
- They are usually the devices where you also want option 2 Required:WHQL, so every kernel driver must be WHQL signed and legacy driver support is removed.
- They are the devices where you can afford a policy that is genuinely narrow, because the application set is known and small.
- They are the devices where you should not be relying on the Intelligent Security Graph. Microsoft says reliance on the ISG "isn't recommended for critical workloads, Windows OS code, especially code that runs during boot, or situations where performance is most critical".
What signing costs operationally
Nobody regrets signing a policy on the day they deploy it. They regret it the first time they need to change or remove one.
Supplementals come along for the ride. When you sign a base policy that has existing supplemental policies, you must switch all of the supplementals to signed as well, and authorise them by adding a <SupplementalPolicySigner> rule to the base.
The UpdatePolicySigner rule is not optional. At least one <UpdatePolicySigner> rule must exist to convert the policy XML with ConvertFrom-CiPolicy. Microsoft's warning on this step is blunt: failing to perform it "will leave you unable to modify or disable this policy and will lead to boot failure".
Version numbers only go up. When updating a signed policy, the VersionEx of the updated policy must be greater than or equal to the current policy. Replacing a signed policy with a lower version leads to boot failure.
Removal is a procedure, not a delete. To remove a signed base policy you must first deploy a signed replacement that:
- has the same PolicyId as the one it is replacing,
- has a version equal to or greater than the existing policy,
- includes option 6 Enabled:Unsigned System Integrity Policy,
- includes
<UpdatePolicySigners>, and - is signed with a certificate included in the
<UpdatePolicySigners>section of the original policy.
Then restart, so the UEFI protection is deactivated. Microsoft's note on skipping that restart: "Failing to do so will result in a boot start failure."
Signed supplemental policies are easier. They can be removed the same way as unsigned policies without that sequence.
And before removing any policy, disable whatever deployed it. Otherwise it comes straight back.
When it has already gone wrong
If a policy is causing boot stop failures, the documented recovery is:
- If the policy is signed, turn off Secure Boot in the firmware.
- Reach the Advanced Boot Options menu and choose Disable Driver Signature Enforcement, which suspends all code integrity checks including App Control for a single boot session.
- Start Windows, sign in, and remove the policy by script, deleting the
.cipfiles from both the EFI System Partition and the OS volume. - If you turned off Secure Boot and the drive is BitLocker protected, suspend BitLocker protection, then turn Secure Boot back on.
- Restart.
Note step 4. If the drive is BitLocker protected you may need the recovery keys to do any of this. That is the real reason signed policies belong on a small, well understood set of devices: the recovery path assumes someone can get to the firmware and has the recovery key.
Testing a signed policy
Microsoft's guidance here is specific and it is the part most often skipped.
Deploy an unsigned version of the policy first, to uncover any issues with the policy rules. Debug the rules while the policy is still removable.
Enable options 9 and 10 while you are testing. Option 9 Enabled:Advanced Boot Options Menu allows the F8 menu to appear, which is otherwise disabled for all App Control policies. Option 10 Enabled:Boot Audit on Failure puts the policy into audit mode when a boot critical driver fails during startup, so Windows loads and you can read the reason in the CodeIntegrity log. Remove them once validated if you want to.
Setting one is harmless if it is already set:
Set-RuleOption -FilePath <PathAndFilename> -Option 9
Reboot the test machines at least twice. Microsoft says so explicitly, because the anti-tampering protection only engages on the first restart, so a single reboot does not prove the second one works.
The Intune trap on memory integrity
One known issue is worth planning around before it surprises you.
On Windows 11 versions earlier than 24H2, you should activate new signed App Control base policies with a reboot on systems that have memory integrity enabled. Microsoft's recommendation is to deploy those policies by script and activate with a system restart, rather than through MDM.
The scope matters, because it is narrower than people assume. It affects new signed base policies going to systems with memory integrity enabled. It does not affect updates to signed base policies already active on the system, unsigned policies, supplemental policies signed or unsigned, or systems not running memory integrity.
So it is a first-deployment problem on hardened devices, which is exactly the population you were going to sign. Plan the script path for those devices rather than discovering it when the policy silently fails to activate.
Where this leaves you
Two configurations, chosen by what the device is for.
End user devices run unsigned policies, and you invest in knowing when a policy stops being present. Same rules, same enforcement, a recovery path that does not need a screwdriver.
Privileged access workstations and protected servers run signed policies, with WHQL required, a narrow rule set, no reliance on reputation, options 9 and 10 during testing, and the script deployment path for the first signed base policy if memory integrity is on.
Treating signing as a maturity level you graduate to across the whole fleet is how organisations end up with a recovery procedure that requires firmware access on ten thousand laptops. It is a device profile decision, not a programme milestone.
For the rules themselves rather than the signature over them, our piece on what App Control covers and how rule levels work goes through the trade offs. The platform sets out where signing fits in the sequence.
Signing your policy is a good decision that removes your ability to undo it casually, which is exactly why the version history matters more once you do. PoliEze keeps every policy version, its approval and its predecessor, so moving to a signed policy is a step forward rather than a door closing behind you.
Sources
Every claim above is from Microsoft's own documentation. Worth reading directly before you sign anything, because the warnings are stated more bluntly there than anywhere else.
Questions about this
Do App Control policies have to be signed?
What happens if you get a signed policy wrong?
Can you remove a signed App Control policy?
Should end user devices use signed policies?
Related reading
Audit mode to enforcement, and what audit mode does not tell you
Audit mode is not a perfect dress rehearsal. Four things are enforced or changed even in audit, and one failure mode produces no events at all.
The missing control plane for App Control for Business
Windows already enforces. What no vendor ships is the layer that decides what to trust, records who approved it, and takes it away again when it is no longer needed.
Every application control product identifies files the same way
The file identity model is common to all of them. What separates one product from another is the operating model around it, which is what evaluations skip.