Users of modern versions of Windows 11 have a powerful security feature for keeping their devices secure, known as Smart App Control.
I’ve talked about this feature a few times over the last year, but in April 2026, a powerful improvement landed. Previously, Smart App Control could not be turned back on if you ever turned it off. That limitation has been removed in Windows 11 version 25H2, making the feature far more practical to use and try out.
What is Smart App Control?
While Windows’ SmartScreen AppRep feature only checks the reputation of the entry point program (typically a .exe file) from an untrusted origin (like the Internet), Windows 11’s Smart App Control goes further than SmartScreen and evaluates trust/signatures of all code (DLLs, scripts, etc) that is loaded by the Windows OS Loader and script engines. This provides a broader range of protection (somewhat akin to Gatekeeper on MacOS) and addresses AppRep bypasses like DLL hijacking. If a code file is unsigned, Windows will consult the Microsoft Defender Intelligent Security Graph in the cloud to see whether the file is known to be trustworthy and permit it to load only if so.
Beyond trust evaluation, when Smart App Control is enabled, many dangerous file types are blocked from ShellExecute() entirely if a file is from an untrusted origin.
End-users can enable Smart App Control in the Windows Security App.
Automatic Enablement
By default, Smart App Control starts in Evaluation mode, meaning that it watches as you use your device to determine whether SAC’s protections are a good match for your use cases. While SAC works great for the majority of consumers, it tends to cause too much friction on devices used by Developers and within Enterprises, because these devices commonly interact with unsigned code or code that is not broadly used by the public.
Other file types
One of the most exciting features of Smart App Control is that it blocks the Windows Shell from opening files of certain types if they originate from untrusted locations.
As of April 2026, the list of SAC-blocked-if-MotW extensions is .appref-ms, .appx, .appxbundle, .bat, .chm, .cmd, .com, .cpl, .dll, .drv, .gadget, .hta, .iso, .js, .jse, .lnk, .msc, .msp, .ocx, .pif, .ppkg, .printerexport, .ps1, .rdp, .reg, .scf, .scr, .settingcontent-ms, .sys, .url, .vb, .vbe, .vbs, .vhd, .vhdx, .vxd, .wcx, .website, .wsf, .wsh.
If you attempt to open one of these potentially dangerous files from an untrusted source, you’ll encounter the following block dialog:
Notably, this dialog box does not offer an override. If you’re confident that the file is from a trusted source, you could remove the MotW or temporarily disable SAC before opening it.
Impact on Other Features
- Enabling SAC causes the Choose where to get apps setting to be ignored.
- Enabling SAC causes SmartScreen Application Reputation to be disabled.
- When SAC is enabled, Microsoft Defender Antivirus enters a special “Hybrid” mode (similar to its passive mode). In Hybrid mode, Defender’s real-time protection feature is less-active, reducing the monitoring (BM and file open/close scans) for processes unless the system determines that the process is one that is particularly interesting (e.g. a script engine host).
- Unfortunately, SAC’s dangerous file type list is baked into the feature and is not extensible. It does not respect the
HighRiskFileTypeslist from the registry or theEditFlagsof the file type.
Developer Guidance
For software publishers, the best way to avoid problems with SAC blocking your app is to sign your code, already a longstanding best practice. Importantly, unlike SmartScreen AppRep (which only verifies the reputation files with an Internet origin), SAC verifies signatures on all code modules, including DLLs and packages like MSIs. That means that tricks like using a signed stub installer to drop unsigned code will not be good enough.
One early problem with Smart App Control is that the Code Integrity codepath didn’t support ECC signatures. That’s being addressed, but for broadest compatibility and least friction, you should still avoid ECC for code-signing.
Other Links
Nitty Gritty – Nearly four years ago, @n4r1B posted an amazingly low-level exploration of the underlying implementation of SAC and the Windows code integrity technology that implements it.
text/plain 