Microsoft says that on Windows 11 devices, Smart App Control may supersede SmartScreen application reputation, and it blocks execution of unsigned files unless they have a positive reputation. Its signature checks apply to all executable files, not only downloaded ones. If you ship tools to Windows users, sign everything.
What the documentation says
The SmartScreen guidance for developers includes a tip about Smart App Control: it can take over from SmartScreen application reputation, it blocks unsigned files that lack positive reputation, and its checks cover all executable files, not just those from the internet. We did not read a separate Smart App Control page, so check Microsoft's current documentation for modes and settings.
Why developers should care
Your own build outputs are unsigned during development. If a developer machine runs with this protection active, a locally built tool, a script host or a plug-in may be blocked. That creates friction that tempts people to turn the protection off for good.
Practical options
- Sign test builds too. Use a development signing identity that is separate from your release identity, and never reuse the release key.
- Scope exceptions. If a team needs an exception, make it narrow and documented, and review it. Do not disable protection across the fleet.
- Use a dedicated dev environment. Some teams run unsigned tooling inside a virtual machine or dev box, separate from the machine that holds credentials.
- Sign helper binaries and updaters. An unsigned helper next to a signed app is the usual cause of surprises.
What this means for shipping software
Sign every executable and library you ship, not only the main installer. Keep a consistent publisher identity, because reputation builds around it. Do not modify files after signing. Microsoft lists each of these in its guidance on minimising warnings, and they apply equally here. See why a signed installer can still warn.
For IT teams
If you manage developer laptops, decide the policy deliberately. A blanket exception is a security regression. A signed internal tooling pipeline is the better long-term answer. Our notes on attack surface reduction rules on dev PCs show a similar audit-first approach.
A short policy you can adopt
Write two sentences and share them. First, every binary we ship is signed with the release identity by the pipeline. Second, development builds are signed with a separate development identity, and exceptions to endpoint protection need a named owner and an end date. Short rules like these are easy to follow and easy to audit. Review them when your tooling or the platform's behaviour changes.
Quick check
Does Smart App Control only look at downloaded files?
Microsoft says its signature checks apply to all executable files, not just those downloaded from the internet.
Should we turn it off for developers?
Prefer signing development builds and narrow exceptions. Turning protection off widely removes a useful control.
Sources
Last reviewed: 19 October 2026.
