Smart App Control (SAC) does not rely only on key length or the fact that binaries are signed. It combines:
- Cloud-based reputation (Intelligent Security Graph / app intelligence services)
- Code integrity policy
- Signature validity and trust chain (certificate must chain to a CA in the Microsoft Trusted Root Program)
If the cloud service cannot confidently classify the app as safe, SAC will then check whether the binaries are signed with a certificate issued by a trusted root CA. If either the reputation is bad/unknown or the certificate chain is not trusted as expected, SAC will block the binaries even if they are RSA 4096-bit signed.
To allow customers to run the software without disabling Smart App Control:
- Ensure all code is signed correctly
- Sign every executable component that SAC can load:
.exe, .dll, installers, temp installer files, scripts, uninstallers, and any binaries loaded by integrations (for example Office add-ins).
- Use a code signing certificate from a CA that is part of the Microsoft Trusted Root Program, or use Microsoft Trusted Signing.
- Verify the full certificate chain on an affected Windows 11 25H2 device to confirm it chains to a trusted root.
- Test the app with Smart App Control audit policies
- Use the documented SAC audit policy to test the app in an environment where SAC logs what it would block without actually blocking execution.
- After enabling the audit policy and refreshing with
citool.exe -r, reproduce installation and all major features so SAC evaluates all code paths.
- Review Code Integrity event logs on affected machines
- On a device where the app is blocked, open Event Viewer → Application and Services Logs → Microsoft → Windows → CodeIntegrity → Operational.
- Look for SAC-related events:
- Event ID 3076: evaluation mode
- Event ID 3077: enforcement mode
- These events show which specific files are blocked and why. Use this to identify unsigned or mis-signed binaries, or components loaded indirectly (for example helper EXEs, plug-ins, or scripts) that were missed during signing.
- Note that the log records only blocked/audited files, not high-level “installation failed” reasons, so each blocked file must be addressed.
- Address any blocked or misconfigured components
- For each blocked file in the CodeIntegrity log:
- Confirm it is signed with the same trusted certificate and timestamped correctly.
- If it is intentionally unsigned (for example a script), consider signing it or refactoring so that only signed binaries execute.
- Rebuild and redistribute the installer after ensuring all binaries are properly signed and trusted.
- Keep Windows and Defender up to date
- SAC’s cloud intelligence is updated regularly. Ensure customers have current Windows and Microsoft Defender updates so reputation and classification are up to date.
If, after verifying trusted-root signing and fixing all blocked components, SAC still blocks the app, collect the relevant CodeIntegrity 3076/3077 events and engage Microsoft support so the app’s reputation and any false positives can be investigated using those event details.
References: