Application Blocked by Smart App Control: The Publisher's Fix
Why This Is Happening
I've seen this exact scenario derail software releases more times than I can count , and the frustration is completely valid. You've done everything right. Your .exe and .dll files are signed with a legitimate RSA 4096-bit code signing certificate, your installer works perfectly in your test environment, and then your users on Windows 11 25H2 start reporting that Windows just flat-out blocks it. No clear explanation. No meaningful error message. Just a hard stop that says something like "This app was blocked for your protection."
Here's the thing Microsoft doesn't explain well: Smart App Control blocked your signed application not because your signature is invalid, but because your application lacks sufficient reputation in Microsoft's cloud intelligence system. These are two completely separate trust mechanisms, and conflating them is the root of almost every publisher's confusion.
Smart App Control (SAC), introduced in Windows 11 22H2 and significantly tightened in 24H2 and 25H2, operates on top of the Windows Defender Intelligent Security Graph (ISG) , a cloud-based telemetry and machine learning system that aggregates signals from hundreds of millions of Windows devices worldwide. When a user launches your app, SAC doesn't just verify the Authenticode signature. It also sends a query to ISG asking, in effect: "Have enough Windows machines run this exact binary and reported it as benign?" If the answer is no, because your app is newly published, or your user base is small relative to the global Windows ecosystem, SAC blocks it regardless of signature validity.
Windows 11 25H2 made this noticeably stricter. Microsoft adjusted the reputation threshold and expanded SAC's enforcement to cover more file types, including side-loaded DLLs and certain script hosts. That's why publishers who had no issues on 24H2 are suddenly getting flooded with support tickets from users on 25H2 machines.
There's also a certificate type consideration. An OV (Organization Validation) code signing certificate, even one using RSA 4096-bit keys, grants less ISG reputation credit than an EV (Extended Validation) certificate. EV certificates require physical identity verification by the CA and are therefore treated as higher-trust anchors by ISG. If you're using an OV cert, that's a contributing factor. It won't bypass SAC entirely, but EV status does accelerate the reputation-building process.
One more thing worth understanding: SAC operates in three states, On, Evaluation, and Off. On fresh Windows 11 installs, SAC starts in Evaluation mode, silently auditing without blocking. After Windows accumulates enough local telemetry about a machine's software habits, it transitions to On mode. Once in On mode, there is no GUI toggle available to end users, the only way to disable it is through registry or Group Policy, which has significant security implications. This is exactly why your users can't just "click to allow" the app themselves.
The Quick Fix, Try This First
If you're a software publisher dealing with Smart App Control blocking your signed application across your user base, the single fastest path to relief, while you work through the longer-term reputation-building process, is to submit your application binaries to Microsoft's Security Intelligence portal for manual review and reputation seeding. This is different from a standard malware submission. You're specifically requesting ISG reputation provisioning for a legitimate signed application.
Here's exactly what to do:
- Go to Microsoft's file submission portal (Security Intelligence).
- Under Submission type, select "Software developer, I want to validate a file" rather than the standard malware submission option.
- Upload your primary
.exeinstaller or the main application binary. - In the description field, include: your code signing certificate thumbprint, the SHA-256 hash of the binary, your company name, and a brief statement that the application is blocked by Smart App Control on Windows 11 25H2 despite valid code signing.
- Submit and note your case number.
Microsoft's response time varies, typically 1 to 5 business days for ISV submissions with a valid case. Once they seed your app's hash into ISG, new instances of SAC blocking should stop within 24–48 hours as the reputation propagates globally.
For your users who are already blocked right now, the fastest per-machine workaround is switching SAC to Evaluation mode via PowerShell (requires admin), which I'll cover in the step-by-step section below.
Before anything else, confirm exactly what kind of certificate you're using and whether your binaries are properly timestamped. Open PowerShell as Administrator and run:
Get-AuthenticodeSignature -FilePath "C:\Path\To\YourApp.exe" | Select-Object -Property *Look at the SignerCertificate output. You want to see:
- Subject: Your company's full legal name (OV certs typically show just the org; EV certs are additionally verified by the CA)
- Status:
Valid - TimeStamperCertificate: This should NOT be empty, a missing timestamp means your signature expires when the signing cert expires, causing additional SAC distrust
To check if it's EV vs OV, look at the certificate's OID policies. Run:
$cert = (Get-AuthenticodeSignature "C:\Path\To\YourApp.exe").SignerCertificate
$cert.Extensions | Where-Object {$_.Oid.FriendlyName -eq "Certificate Policies"} | ForEach-Object { $_.Format($true) }An EV certificate will include the OID 2.23.140.1.3 in its certificate policies. If you don't see that OID, you have an OV certificate. This doesn't mean your signing is broken, it means you'll need to rely more heavily on the ISG reputation submission path and consider upgrading to EV for future releases. If the Status shows UnknownError or HashMismatch, you have a genuine signing problem to address first before tackling SAC.
Don't assume SAC is the culprit without checking Event Viewer first, Windows Defender, AppLocker, or WDAC could also be responsible. Open Event Viewer on an affected user's machine and navigate to:
Applications and Services Logs
→ Microsoft
→ Windows
→ CodeIntegrity
→ OperationalFilter for these specific Event IDs:
- Event ID 3076: SAC audit block (Evaluation mode, logged but not enforced)
- Event ID 3077: SAC enforcement block, this is the one you'll see when users report the app won't launch
- Event ID 3089: Signature information correlated with a block event
You can also pull this programmatically. On an affected machine run:
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" `
-FilterHashtable @{Id=3077} | `
Select-Object TimeCreated, Message | `
Format-ListThe Event 3077 message will reference your binary's path and include the SHA-256 hash that ISG evaluated. Copy that hash, you'll need it for your Microsoft submission. If you see Event ID 3077 entries matching your app's path, SAC enforcement is confirmed as the cause. If you see Event IDs in the 8028–8040 range instead, you're dealing with legacy SmartScreen, which has a different (simpler) resolution path.
This is the immediate per-machine workaround for users already blocked. SAC stores its state in the registry under:
HKLM\SYSTEM\CurrentControlSet\Control\CI\PolicyThe key is VerifiedAndReputablePolicyState with these DWORD values:
0= Off1= Evaluation mode2= On (enforcing)
To switch to Evaluation mode (which stops enforcement but logs decisions), run this in an elevated PowerShell session:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Policy" `
-Name "VerifiedAndReputablePolicyState" `
-Value 1 -Type DWordThen restart the machine. After restart, your application should launch without a block. Evaluation mode is much safer to advise for end users than turning SAC fully off, it keeps logging active so nothing silently slips through. Important caveat: on machines enrolled in Microsoft Intune or managed via Group Policy, this registry change may be overwritten by policy refresh. For managed environments, use the Group Policy path I cover in the Advanced section. After applying this change, verify the SAC state with:
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Policy").VerifiedAndReputablePolicyStateA return value of 1 confirms Evaluation mode is active.
This is the long-term fix that removes the dependency on per-machine workarounds. You need to submit each unique binary hash to Microsoft's Intelligent Security Graph. First, generate the SHA-256 hashes for all your signed binaries:
Get-ChildItem "C:\YourApp\bin\" -Recurse -Include "*.exe","*.dll" | `
ForEach-Object {
$hash = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
$sig = (Get-AuthenticodeSignature $_.FullName).Status
[PSCustomObject]@{File=$_.Name; Hash=$hash; SigStatus=$sig}
} | Export-Csv "app_hashes.csv" -NoTypeInformationThis exports a clean CSV with every binary's name, SHA-256 hash, and signature status. Include this CSV in your Microsoft submission. For the submission itself, use the Microsoft Security Intelligence portal and select the ISV/developer submission path. In addition to the portal submission, I strongly recommend opening a support case directly with Microsoft through your MPN (Microsoft Partner Network) account if you have one, partner submissions get prioritized ISG review. Include in your submission:
- The CSV of binary hashes
- Your code signing certificate's thumbprint (SHA-1)
- A description of your application's functionality
- Evidence of your CA-verified identity (the certificate itself)
- The Event ID 3077 log entries from an affected machine
Once Microsoft seeds your hashes, ISG reputation propagates to Windows clients over the next 24–48 hours via Windows Update telemetry channels. You don't need to push anything to end users.
If you're managing a corporate environment where your own software needs to run reliably, you can configure Smart App Control behavior through Group Policy. On domain-joined machines, open the Group Policy Management Editor and navigate to:
Computer Configuration
→ Administrative Templates
→ Windows Components
→ Windows Defender SmartScreen
→ Explorer
→ Configure Windows Defender SmartScreenSet this to Enabled with the option "Warn and prevent bypass" or "Warn" depending on your risk tolerance. Note that SAC itself is a separate layer from legacy SmartScreen, but Group Policy controlling SmartScreen's Explorer integration does affect how the overall chain behaves for trusted enterprise binaries. For Intune-managed devices, deploy a Device Configuration profile using the Settings Catalog. Search for "Smart App Control" in the catalog, you'll find the VerifiedAndReputablePolicyState setting there. Deploy it as a Device configuration policy targeting your affected device group:
Setting: Verified And Reputable Policy State
Value: Evaluation (1)After the Intune policy syncs (trigger manually with Invoke-MdmDeviceSync or wait up to 8 hours for the standard sync cycle), affected machines will move to Evaluation mode. Combine this with your ISG reputation submission for a complete fix, the Intune policy handles the immediate unblock, and the ISG submission handles the permanent resolution.
Advanced Troubleshooting
If the steps above haven't fully resolved the application blocked by Smart App Control issue, or if you're dealing with an enterprise environment with complex policy layering, here's where to dig deeper.
Analyzing the WDAC Policy Overlap
Windows Defender Application Control (WDAC) and Smart App Control share the same kernel enforcement layer, Windows Code Integrity (ci.dll). On enterprise machines, WDAC policies can conflict with SAC state changes. Check if a WDAC policy is deployed:
Get-CIPolicy -FilePath "$env:SystemRoot\System32\CodeIntegrity\SIPolicy.p7b" 2>$null
CiTool --list-policiesIf CiTool lists any active policies with enforcement mode, those may override your SAC state registry changes entirely. In that case, the policy itself needs to include your application's file hash or publisher rule, modifying the registry won't help.
Correlating Event IDs Across Logs
Pull correlated events from both CodeIntegrity and the AppLocker log to get the full picture:
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" `
-FilterHashtable @{Id=3076,3077,3089} -MaxEvents 50 | `
Select TimeCreated, Id, Message | Format-ListEvent ID 3089 is particularly useful, it appears immediately after 3077 and contains the specific signature details that caused the block, including whether ISG was consulted and what response it returned. A message containing "Revoked" means your certificate has been revoked or the OCSP/CRL check failed, a different problem entirely. A message containing "UnknownAuthority" points to an intermediate certificate chain issue.
Cross-Checking Certificate Chain Completeness
One commonly missed issue: the signing certificate's intermediate CA certificate may not be included in the binary's signature. SAC's ISG lookup can fail if the chain cannot be built locally. Verify your signing tool includes the full chain:
signtool verify /pa /v /debug "YourApp.exe" 2>&1You should see "Verified" and a complete chain listing all the way to a trusted root. If any intermediate certificate is missing, re-sign with /fd sha256 /ac IntermediateCert.cer included in your signtool command.
Domain-Joined Machine Specifics
On machines joined to an Active Directory domain, SmartScreen and SAC behavior can be overridden by domain GPO. Run gpresult /h gpo_report.html on an affected machine and look for any SmartScreen or Application Control policies applied from the domain. Conflicting domain policies will always win over local registry changes.
If you've submitted your binaries through the ISG portal, waited more than 7 business days, and users are still getting blocked, escalate directly. You'll want to open a support case as a software publisher, not as an end user. Go to Microsoft Support and choose "Developer & IT Pro" as your support category. Reference your WDSI submission case number and include the Event ID 3077 entries from affected machines. If you have an MPN or MCPP partner contract, use your partner support channel, it's dramatically faster and connects you to the actual ISG team rather than tier-1 support. Also consider reaching out through the Microsoft Tech Community forums under the Windows Security category, where Microsoft product team members are occasionally active.
Prevention & Best Practices
Once you've resolved the current Smart App Control blocking issue, the goal is to never hit it again on a future release. These practices, learned from working with dozens of software publishers on exactly this problem, make a measurable difference.
Upgrade to an EV code signing certificate before your next major release. I know they're more expensive and require hardware tokens (usually a USB HSM), but the ISG reputation head-start they provide is significant. Microsoft's telemetry system gives EV-signed binaries a reputation multiplier from day one because the CA-verified identity makes it much harder for malware authors to obtain them. The business case is simple: fewer support tickets per release pays for the certificate cost quickly.
Implement deterministic builds. If your build pipeline embeds timestamps, build numbers, or random padding into binaries at compile time, every build produces a different hash and starts at zero ISG reputation. Configure your compiler and linker for reproducible output, in .NET, set <Deterministic>true</Deterministic> in your project file. In C++, disable the /INCREMENTAL linker flag and strip debug timestamps. Test that two independent builds of the same source produce byte-identical output.
Submit to WDSI immediately after every release, don't wait for user reports. Make the submission step part of your release checklist, right after code signing. Proactive submission means your hashes are in ISG review before any user installs the software. With EV-signed binaries, this head start often means reputation is established before significant user volume arrives.
Build a release smoke test environment that mimics a fresh Windows 11 install with SAC in On mode. Most development machines have SAC in Evaluation mode or Off because developers have been running many unsigned scripts and tools. A clean Windows 11 VM with SAC in enforcement mode is the only reliable way to catch SAC blocks before your users do.
- Switch from OV to EV code signing certificate, reduces ISG reputation build time from weeks to days
- Enable deterministic builds in your CI pipeline so the same patch release always produces the same binary hash
- Add WDSI submission as a mandatory post-release step in your deployment checklist, not an optional one
- Maintain a Windows 11 clean VM with SAC On for release-gate testing before every public deployment
Frequently Asked Questions
My app is signed with a valid certificate, why does Smart App Control still block it?
This is the most common misconception I encounter. Smart App Control has two separate trust requirements: a valid Authenticode signature AND a positive reputation score in Microsoft's Intelligent Security Graph (ISG). The signature proves the binary hasn't been tampered with and identifies the publisher. But ISG reputation is based on how many Windows machines have run that specific binary hash and reported it as benign. A freshly signed binary from a new or small publisher has zero ISG history, so SAC blocks it regardless of signature validity. You have to build that reputation through volume of installs or through a direct Microsoft WDSI submission.
Can my users just click "Run anyway" to bypass the Smart App Control block?
No, and this is a key difference from the older SmartScreen warnings. Legacy SmartScreen showed a blue warning dialog with a "Run anyway" option that users could click through. Smart App Control in enforcement mode shows a hard block with no bypass option available to the user. The only ways around it are: switching SAC to Evaluation or Off mode (requires admin rights and a registry or policy change), or having the application gain ISG reputation so SAC no longer blocks it. This is why your support team can't just tell users to "click through the warning."
How long does it take for a new app to gain enough ISG reputation to stop being blocked?
Without a manual WDSI submission, reputation builds organically from user telemetry, and on a new or low-volume application, that can take weeks to months. With a proactive WDSI developer submission, Microsoft typically reviews and seeds reputation within 1 to 5 business days, though I've seen it take up to 10 days during high-volume periods. EV-signed binaries with a WDSI submission often see reputation established in 1–2 business days because the EV certificate identity reduces the review burden. Once seeded, the reputation propagates to Windows clients globally within 24–48 hours.
Does turning off Smart App Control make my users' machines less secure?
Yes, somewhat, but the risk depends heavily on context. SAC in Off mode means Windows no longer consults ISG before running unknown executables. However, Windows Defender Antivirus, real-time protection, and SmartScreen for the browser are all still active. The realistic risk increase is primarily for users who frequently download and run software from unofficial sources. For corporate environments where software installation is controlled by IT policy, switching SAC to Evaluation mode (rather than Off) is a better balance, it logs everything SAC would have blocked without actually enforcing the block, so you maintain visibility without disrupting legitimate software.
We push updates frequently, do we need to resubmit to WDSI every time we release a new build?
Technically, yes, each unique binary hash is evaluated independently by ISG. But there's a practical shortcut: if you sign with an EV certificate and your publisher identity is already established in ISG from prior submissions, new builds from the same EV publisher accumulate reputation significantly faster than the first submission. Many publishers find that after 3–4 well-received EV-signed releases, subsequent releases get through with minimal block reports even before a fresh WDSI submission. That said, for major version releases, always submit proactively. For patch releases, implementing deterministic builds that keep hashes stable across minor updates is the cleanest long-term solution.
Our software installer wraps a third-party component, does that third-party binary need its own WDSI submission?
Yes, if that third-party binary is extracted to disk and executed separately (rather than loaded purely in memory from within your process), SAC evaluates it as a standalone file with its own hash. This catches a lot of publishers off-guard, bundled runtimes, redistributable DLLs, and helper executables all need their own ISG reputation. The best approach is to ensure that any third-party components you bundle are themselves signed by their original vendor (which is usually the case for major runtimes like the Visual C++ redistributable or .NET), since those vendors' binaries already have strong ISG reputation. For any custom third-party components that are not already well-known, those hashes need to be included in your WDSI submission.