C++ Program Being blocked by SAC after adding Cryptographic token

Question

I am writing a Console application in Visual Studio, as a proof of concept, before I write the actual program I am wanting to make, the program ran perfectly fine for the last two days during small iterative upgrades, I have no build issues, but as soon as I added a cryptographic token to the program SAC blocks it from running, I am in the very early stages of writing this POC application, and I can't imagine this is going to get any better when I write the actual software. I am nowhere near close to where I want to be before paying for a Signed Certificate and honestly never wanted to sign the POC as it's just a demonstration of what the actual software will do. Developer mode is turned on, this is my personal gaming machine as well so I don't want to turn SAC off for a litany of reasons. Is there a Microsoft approved way of preventing SAC from shutting down my locally written application without having to expose my machine security to possible real threats, without having to sign the application with a trusted cert? I am using windows 11 home, I cannot change SAC to evaluating, I absolutely do not want to reinstall windows after turning off SAC just to turn it back on. and I refuse to write a program I cannot debug as I go along.

Answer 1

Hi @Casey French ,

What you're seeing is expected behavior for Smart App Control in enforcement mode, and Developer Mode doesn't exempt you from it.

SAC allows a binary to run in one of two cases: Microsoft's cloud app intelligence service confidently predicts it's safe, or it's signed with a certificate from a CA in the Microsoft Trusted Root Program. Unsigned or unknown code is blocked by default. There's no per-app allow list or exclusion you can add.

That explains the "it worked for two days, then stopped" part. Every rebuild produces a new binary, and SAC evaluates each one as it loads. Your earlier builds were getting through on a cloud prediction, not because they were trusted. Once the crypto token changed what the binary does, the service stopped predicting it as safe, and with no signature to fall back on, it blocks. Since the prediction isn't something you control, you can't rely on it to keep working as the POC grows.

Approaches you can consider:

1. Sign your builds. This is the only supported way to keep SAC on and run your own code. A few things to know before you buy anything:

• Self-signed certs will not work. SAC only considers certificates issued by trusted providers.
• The cert must be RSA-based. SAC's signature check does not support ECC/ECDSA signatures.
• You need to sign everything SAC loads, not just the main .exe, including DLLs and any installer binaries.
• Trusted Signing is the cheaper route than a traditional cert if you go this way. You can also sign locally with signtool.exe, which ships with Visual Studio.

Docs: Sign your app for Smart App Control compliance

2. Develop in a VM. Move the project to a VM or second machine where SAC isn't enforcing. Your gaming machine stays protected, and you get an unblocked debug loop. For a POC this is usually the most manageable option.

3. Check whether re-enabling SAC is still a one-way trip on your build. You mentioned not wanting to turn it off because of the reinstall. Worth verifying before you rule it out: the Smart App Control FAQ notes that recent Windows updates allow SAC to be enabled from the Windows Security app without requiring a clean install. Make sure you're fully patched, then open Windows Security > App & browser control > Smart App Control settings and see what the page tells you about turning it back on. If it confirms you can re-enable it, turning it off for the duration of the POC becomes a reasonable call. If it doesn't, skip this option.

4. Registry configuration. Microsoft documents forcing SAC into a different mode via the registry, including into Evaluation, in Test your app's signature with Smart App Control.

---

You're not the only developer hitting this. There's an open Visual Studio feedback item, Reporting Smart App Control errors when developing .NET apps, asking for exactly what you're describing: dev-certificate signing or a valid bypass for local builds. It's been triaged to the engineering team. If this matters to you, upvoting and adding your C++ scenario in a comment is the most direct way to get it in front of the right people.

For now, my recommendation is: option 2 if you can spare a VM, option 1 once you're closer to something real.

Hope this helps. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you.

Answer 2

Smart App Control (SAC) blocks your C++ binary after adding cryptographic tokens for one of three core reasons: an unverified digital signature, missing modern security flags, or suspicious token loading behavior.

• ​__Sign with an EV Certificate:__ Self-signed or unverified certificates are blocked by SAC. You must sign the .exe using signtool.exe with a trusted EV Code Signing Certificate and a valid RFC 3161 SHA-256 timestamp server.
• ​__Enable Required Linker Security Flags:__ SAC enforces modern PE headers. Pass these flags to MSVC:
  • ​/DYNAMICBASE (ASLR)
    • ​/HIGHENTROPYVA (64-bit ASLR)
      • ​/NXCOMPAT (DEP)
        • ​/INTEGRITYCHECK (forces signature validation on load)
        • ​__Avoid Dynamic Injection:__ If your crypto token uses raw memory injection or API hooking, SAC flags it as malware. Load token libraries cleanly via native Win32 APIs (LoadLibraryEx) or CryptAcquireContext / NCryptOpenStorageProvider.
        • ​__Store Keys Properly:__ Do not embed raw byte arrays into executable headers. Use standard .rc resource files or the Windows Certificate Store (CertOpenStore).

​__Quick Check:__ Run Get-AuthenticodeSignature .\YourApp.exe in PowerShell to ensure the binary is fully trusted, and check Event Viewer (CodeIntegrity > Operational) for the exact block log.