Supported way to run a locally built application with Smart App Control enabled

Question

Supported way to run a locally built application with Smart App Control enabled

Justin Youri Larocque 0

On Windows 11, a locally built, unsigned C++ application was blocked before its process started. CreateProcessW returned error 4551. CodeIntegrity event 3077 reported:

Policy: VerifiedAndReputableDesktop
Status: 0xC0E90002
Requested signing level: 2
Validated signing level: 1

We want to keep Windows security protections enabled. A newer build exists but has not been executed, so we do not know whether it would be accepted.

What is the supported path for an individual developer to run and test this application under Smart App Control? Before purchasing code signing, what certificate requirements and other acceptance criteria should we verify? Is there a supported review or support channel for this situation?

We are not requesting a security bypass. No executable, source code or diagnostic files are attached.

0 comments

3 answers

Your answer

Answer 1

The supported path is to test with Smart App Control in Evaluation mode and use its audit logging to determine whether the app would be blocked, then sign the app with a certificate trusted by the Microsoft Trusted Root Program if Smart App Control cannot establish reputation.

For an individual developer, the practical supported workflow is:

Check Smart App Control state in Settings > Windows Security > App and Browser Control.
- On = enforcement mode.
- Evaluation = audit-style evaluation without blocking.
- Off = not running.
If possible, use Evaluation mode for testing.
- In evaluation mode, Smart App Control evaluates the app signature but does not block the app if the signature is invalid.
- For testing, audit output can be reviewed to see what Smart App Control would do.
Review Code Integrity logs in Event Viewer > Application and Services Logs > Microsoft > Windows > CodeIntegrity > Operational.
- Event ID 3076 = evaluation mode events.
- Event ID 3077 = enforcement mode events.
- These logs identify blocked or audited files, not installer-level failures.
If deeper signature diagnosis is needed, inspect correlated 3089 events.
- A 3077 event with requested signing level 2 and validated signing level 1 means Windows treated the binary as effectively unsigned for policy purposes.
- On correlated 3089 events, the VerificationError explains why a signature was rejected.

Before purchasing code signing, the supported acceptance criteria to verify are:

The app should be signed with a code signing certificate from a certificate authority in the Microsoft Trusted Root Program.
All shipped binaries should be signed, including exe, dll, temp installer files, scripts, and uninstallers.
Smart App Control allows code to run if Microsoft app intelligence predicts it is safe, or if it is signed with a certificate issued by a CA in the Trusted Root Program.
Unsigned code, invalidly signed code, and code that cannot be confidently predicted safe are blocked.

If testing requires changing Smart App Control mode by registry, that is supported for testing purposes only and carries risk because editing Smart App Control settings this way can compromise the protection it provides.

On review or support channels: the available material describes testing, logging, and signing expectations, but does not identify a separate supported review or exception-request channel for individual developers to submit an app for Smart App Control acceptance review.

A newer build that has not yet been executed cannot be predicted from the available guidance. The supported way to determine likely acceptance without enforcement blocking is to run under Evaluation mode and inspect the resulting audit events.

References:

Answer 2

Justin Youri Larocque 0

Smart App Control is already On on my Windows 11 PC, and Evaluation mode is not available in the Windows Security interface. I want to keep protection enabled and avoid registry or policy changes. What supported option is available in this situation? Is recognized code signing the only practical path for testing my locally built application without weakening the current protection?

0 comments

Answer 3

Hi @Justin Youri Larocque ,

Thank you for detailed post.

With Smart App Control already On, and with registry and policy changes excluded, publicly trusted code signing is the practical path you can control for repeated local builds. SAC can also allow unsigned files that Microsoft’s cloud intelligence considers safe, so signing is not literally the only acceptance path. However, Microsoft documents no per-app “allow anyway” exception. Microsoft’s SAC FAQ

Microsoft explicitly supports testing directly with SAC in enforcement mode so Evaluation mode is not required. That is the option consistent with keeping your current protection enabled. SAC testing guidance

Your VerifiedAndReputableDesktop event identifies an enforcement block. Requested signing level 2 means the file must satisfy the application-control policy; validated level 1 means Windows treated it as unsigned for that decision. This alone does not establish that the application is malicious, and it does not predict whether the newer build will be accepted. Event interpretation

Before purchasing signing, verify:

Certificate trust and purpose: Obtain a Windows Authenticode code-signing certificate chaining to a CA in Microsoft’s Trusted Root Program. Self-signed or privately trusted certificates do not meet that public-trust criterion. SAC’s desktop-app guidance does not specify EV as a requirement. SAC acceptance criteria
Algorithm compatibility: Publicly trusted RSA signing is the conservative choice. The current SAC signing page supports RSA and ECC, but related App Control documentation still lists ECC limitations. Before choosing ECC, obtain confirmation for your exact Windows version and build.
Individual eligibility and workflow: Confirm that the provider accepts individual developers in your country, what identity verification it requires, and whether its hardware-token or cloud-signing arrangement supports your build process.
Complete application coverage: Sign each rebuilt output and ensure DLLs, helper executables, installers, and uninstallers also satisfy SAC. Verify signatures and test all relevant code paths under enforcement. Signing only the main executable may leave another component blocked. A valid signature does not override a malicious or potentially unwanted classification.

Microsoft’s Artifact Signing is an option if you qualify. Individual Public Trust enrollment is currently limited to the US and Canada. Its Private Trust and Public Trust Test profiles are not substitutes for publicly trusted signing. Eligibility · Trust models

You can try the newer build normally with SAC still On. If it is blocked, capture the exact file identified in event 3077 and correlate any 3089 signature events using the same Activity ID.

For product feedback, you can create a request on the FeedBack Hub.

Select report a problem
In category, select Smart App Control
Fill in any necessary information
Then Submit

If you found my investigation and direction of my support helpful, I’d really appreciate it if you could follow this guide so others with similar issue can benefit as well. Thank you.