AppLocker, App Control for Business (WDAC), and Business App Distribution — Before "Application Control" Blocks You

“We installed it on the customer’s PC, but the app won’t start. Double-clicking does nothing.” — this kind of report is arriving more and more often for Windows apps built under contract. Investigate the cause, and what turns out to have stopped the app without even showing an error dialog is application execution control, which is increasingly being deployed on the customer side.

Windows has several mechanisms for allowing only approved applications to run: AppLocker, App Control for Business (long known as WDAC, Windows Defender Application Control), and the consumer-facing Smart App Control. Most security write-ups take the perspective of the side deploying these controls. This article takes the opposite view and organises things from the perspective of the side building and distributing the app: the typical patterns in which your own business app gets blocked in a customer environment, which logs to check to confirm that a block has occurred, and the moves development and distribution teams can make in advance. It also summarises the key points for an IT department considering deploying these controls on its own PCs.

1. The Bottom Line First

• Think of application control as four distinct mechanisms. SmartScreen, which warns and lets the user choose; AppLocker, which applies rules per user/group; App Control for Business, which applies to the whole machine; and Smart App Control, which applies automatically for consumers (see the decision table in Section 2).
• The old assumption that “AppLocker is Enterprise-only” is out of date. From KB 5024351 onward, enforcement no longer requires a specific edition on Windows 10 version 2004 and later, or on any edition of Windows 11.¹
• App Control for Business works on every client edition of Windows 10/11 and on Windows Server 2016 and later. Microsoft recommends using App Control instead of AppLocker wherever possible.²
• Code signing is at the centre of what the distributing side can do. Sign not just the exe but every binary, including DLLs, and the installer, with consistent publisher information (Section 5). With Smart App Control now widespread, unsigned apps may fail to run even on personal PCs.³
• Evidence of a block can be confirmed from the event log. For AppLocker, the key event is 8004 in the “AppLocker - EXE and DLL” log; for App Control, it is event 3077 in “CodeIntegrity - Operational” (see the table in Section 4).⁴⁵
• A PowerShell script may end up “running in restricted mode” rather than being “blocked”. In an App Control environment, a script that does not match policy runs in Constrained Language Mode, producing the confusing failure mode of “it runs, but only some operations fail”.⁵
• The side deploying these controls should start in audit mode. Both AppLocker and App Control have a mode that records “what would have been blocked” without actually blocking it; events 8003 and 3076 correspond to this.⁴⁵

2. Distinguishing the Four Mechanisms

Let’s start with the overall map. The names are similar and easy to confuse, so let’s separate them by “who manages it”, “what unit it applies to”, and “how it takes effect”.

2.1. SmartScreen — The Only Mechanism That Stops You With a “Warning”

SmartScreen is a mechanism that “warns about things with a poor reputation”, and by default the user can override it. In a managed environment, however, a policy that prohibits overriding the warning may be in effect, in which case SmartScreen too works as an effective block (this is covered in “Windows SmartScreen and Code Signing”).

From the distributing side, what characterises SmartScreen is that it takes effect by default even with no administrator writing any rule, and that the reason for a block is “reputation”, not policy. The remedy is therefore different from the other three: rather than having the customer write an allow rule, you address it through signing and building up reputation. What follows in 2.2 through 2.4 covers mechanisms that block outright, rather than warn.

2.2. AppLocker — The Veteran With Per-User Control

AppLocker is an execution control introduced in Windows 7. It defines rules based on code-signing certificate attributes (the publisher), file attributes derived from signing metadata (original file name, version) or hashes, and file paths. Policies can apply to the whole computer, or to specific users or groups.²

This is where the edition requirement is often misunderstood. Current documentation is unambiguous: from KB 5024351 onward, enforcing AppLocker policy no longer requires a specific edition on Windows 10 version 2004 and later, or on any edition of Windows 11. On older versions (Windows 10 before 2004, including Windows Server 2019), the old restriction still applies: enforcement of policy distributed via Group Policy is limited to the Enterprise and Server editions, while MDM-distributed policy works on every edition.¹

Breaking down “what can you do on Pro” into whether you can author rules and whether the rules you author actually take effect (are enforced) gives the picture below. It’s the fact that these two things are different that keeps the old assumption alive.¹

It’s commonly assumed that “you can’t even author rules on Pro”, but authoring works on every edition. What used to differ was enforcement, and even then, MDM-distributed policy was enforced on Pro. The types of rule you can apply (executable files, Windows Installer, scripts, DLLs, packaged apps) do not vary by edition.¹ Note also that, regardless of edition, rules are not evaluated unless the Application Identity service (AppIDSvc) is running (Section 6).

AppLocker does, however, come with an important caveat. Microsoft itself states plainly that AppLocker does not meet the servicing criteria (MSRC’s servicing criteria) for a security feature. In other words, if a bypass technique is found, it is not treated as a security vulnerability in its own right.²

2.3. App Control for Business — The Real Deal as a Security Feature

App Control for Business is the current name for the mechanism that first appeared in Windows 10 as “Device Guard” / “Configurable Code Integrity (WDAC)”. Policy applies to the whole machine and affects every user of the device. Rules can be based on signing-certificate attributes, file attributes or hashes, a reputation score from Microsoft’s Intelligent Security Graph (ISG), the process that initiated installation (a managed installer), the file’s path (Windows 10 1903 and later), or the process that launched the file.²

This one is designed as a security feature defined under MSRC’s servicing criteria. Its usage conditions are also broad: you can create and apply policy on any client edition of Windows 10/11, or on Windows Server 2016 and later. Distribution can use an MDM such as Intune, Configuration Manager, or PowerShell. It can also be distributed via Group Policy, but only in the single-policy format that runs on Windows Server 2016/2019.²

On which to use, Microsoft’s guidance is clear. If you can implement it with App Control, you should: App Control keeps being improved, whereas AppLocker still receives security fixes but no new features. AppLocker suits situations where you have a mix of older Windows versions and want to distribute the same policy, shared PCs where different rules are needed per user or group, and adding user-level restrictions on top of App Control.²

2.4. Smart App Control — Execution Control That’s “Already There” on Personal PCs

Smart App Control is a protection feature for personal users of Windows 11. When an application tries to run, a cloud security service checks whether it can confidently predict that the app is safe, and blocks apps judged malicious, as well as unsigned apps whose trustworthiness cannot be confirmed. On a new PC it starts in evaluation mode, and Windows automatically decides whether it is suitable for that user and turns it on or off accordingly (for a user who is likely to be blocked frequently, such as a developer, it is turned off automatically).³

For the distributing side, the implication is simple: execution control is now present by default even on PCs outside corporate management — that is, on the PCs of small businesses and sole traders. Even with no administrator writing any policy at all, an unsigned app can still be blocked. Microsoft’s guidance to developers also lists signing your app with a valid certificate as a way to avoid being blocked.³

3. Typical Patterns Where Your App Gets Blocked

Here are the patterns actually encountered in contract development and packaged distribution, laid out by root cause.

The common thread is that the side distributing the app is not reliably supplying the evidence (signature, path, hash) that the allowing side needs. Even if the customer’s IT department wants to write a publisher rule, if only some binaries are signed they have no choice but to write a hash rule — and a hash rule breaks every time you ship an update. It may look as though responsibility for the block lies with the deploying side, but in practice, it is often the distributing side that is making the rules fragile in the first place.

4. Confirming What Happened From the Log

Whether “it won’t start” is caused by execution control can be confirmed from the event log, not guesswork. There are two places to look.

4.1. AppLocker Events

Look under Applications and Services Logs\Microsoft\Windows\AppLocker in Event Viewer.⁴ For anyone opening this for the first time, here is the path to follow.

Event Viewer (type “Event Viewer” in the Start menu, or run eventvwr.msc from Run) > Applications and Services Logs > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

This is the same path in an English-language environment: Applications and Services Logs > Microsoft > Windows > AppLocker. If you would rather skip the GUI, open PowerShell as administrator and read the log with the single command below (when asking a customer to check this, handing them this one line is the fastest route).

# Pull AppLocker blocks (8004) and audits (8003) from the last 24 hours
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

The event records the target file’s path, whether it was allowed or blocked, the type of rule applied (path, hash, publisher) and its name, and the SID of the rule’s user/group.⁴ Reading it correctly does take some care, though. Under an allow-list style of operation, most blocks are not “matched some deny rule” — they are an implicit deny because no allow rule matched at all. In that case, what event 8004 confirms is only “the fact that it was blocked, and which file”; the rule name is not a useful clue. When you do hit an explicit deny rule, its name is the cause directly, but for an implicit deny you have to work out “which allow rule is missing” by cross-checking against the policy currently in force.

4.2. App Control for Business (WDAC) Events

App Control blocks appear in a different place: Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational. Control of exe, DLL, and driver files shows up here, while control of MSI, script, and COM shows up in the “AppLocker - MSI and Script” log covered above — that’s the division of labour.⁵

Event Viewer > Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational (the same path in an English-language environment: Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# View App Control blocks (3077), audits (3076), and the corresponding signature info (3089) together
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

When you don’t know which mechanism caused the block, the reliable approach is to line up both logs over the same time range and compare them.

Event 3089 is easily overlooked but important. One event is generated per signature on the file, and an unsigned file produces a single event with a signature count of zero. Distribution-side problems such as “it should be signed but is being treated as unsigned” or “a signature from an old certificate is still there” can be confirmed here.⁵

Script behaviour needs particular care. Event 8029 indicates that “a script was blocked”, but the actual enforcement is delegated to the script host’s own behaviour — PowerShell, for example, does not stop a script that doesn’t match policy outright, but instead runs it in Constrained Language Mode.⁵ Because creation of .NET objects is broadly restricted in that mode, the result is the awkward half-broken failure where “the script itself runs, but one line partway through fails”. If your app bundles a script, not knowing about this failure mode can drag out an investigation (the practicalities of script signing are covered in “PowerShell Execution Policy and Script Signing”).

Note also that the “AppLocker - MSI and Script” log does not exist on the Windows Server Core edition.⁵ Keep this in mind when investigating an app deployed on a server.

5. What the Distributing Side Can Do — Making the App Easy to Write Rules For

Rather than reacting after a block occurs, the right approach is to distribute the app in a state where the customer’s IT department can write a stable allow rule. There isn’t much to do.

1. Apply an Authenticode signature to every binary. Not just the exe, but your own-built DLLs, the installer (MSI/setup exe), and any bundled scripts too. Publisher rules are based on signing metadata (publisher, product name, file name, version), so if the binaries are signed you enable a rule that survives updates: “allow this product from this publisher, regardless of version”.² Choose a certificate that is RSA-based and issued by a trusted certificate authority. A self-signed certificate or one from an internal CA will not work on a customer PC that doesn’t trust that CA, and is not supported by Smart App Control either. Smart App Control’s signature check also does not support ECC (elliptic-curve) signatures, so signing with an ECC certificate can leave the app effectively unsigned on a personal PC.⁶ App Control has the same constraint: signer-based rules only support RSA (up to 4096 bits), and a file signed with ECDSA cannot be allowed by a publisher rule (its signature-info event 3089 will show VerificationError = 23).⁷ Choosing ECC on the assumption that “newer and stronger” is better works against you from the point of view of execution control.
2. Always add a timestamp. This keeps the signature valid even after the certificate itself expires. The practical signing procedure and its relationship to SmartScreen are covered in a separate article.
3. Keep the publisher information and each file’s version resource stable. When you renew a certificate, changing the subject (organisation name) breaks publisher rules. If you change how the company name is written, or where the certificate is obtained from, include advance notice to customers in the release notes. Another point often missed is that a publisher rule’s “product name”, “original file name”, and “version” are taken from each file’s version resource (assembly info), not from the certificate. Leaving these fields blank, or changing the product name or executable file name from release to release, breaks any rule scoped down to a specific product or file, even when the signer stays the same.
4. Keep the executable’s location conventional. Install under Program Files, and stop designs that extract exe/DLL files to %TEMP% or %APPDATA% at runtime and launch them from there. A design that runs from a writable location is fundamentally at odds with a path-rule-based environment.
5. Revisit your auto-update design. Sign the updater itself too, so that an update is a closed loop of “a signed binary replacing a signed binary”. Where distribution goes through Intune or Configuration Manager, if the customer has configured that distribution agent as a managed installer, it becomes possible to run in a mode that allows binaries that arrived via the installer. This doesn’t take effect automatically — it depends on explicit configuration by the administrator — but having a silent-install-capable MSI ready hands that option to the customer (safe design for auto-update is covered in “Security Design for Auto-Update”).
6. Prepare the information you’ll need to hand over if a block occurs. If the signing subject, the list of binaries required at runtime, and the install path are all documented clearly in the deployment guide, the customer’s IT department can write a rule from that alone. If trouble does arise, asking them to check the specific event IDs from Section 4 keeps it to a single round trip.

These six points also serve directly as preparation for Smart App Control. A binary that is signed and has built up reputation is less likely to trip the automatic block on a personal PC.³

5.1. Getting a Code-Signing Certificate for the First Time

If “let’s sign it” is where things stall, here’s the next concrete step for anyone who doesn’t yet have a certificate.

Choosing a certificate. What you need is a code-signing certificate issued by a public certificate authority (a commercial CA). A self-signed certificate or one from an internal CA cannot be validated on a customer PC that doesn’t trust that CA, so it’s unusable for distribution. Public-CA certificates come in OV (which verifies the organisation’s existence) and the more rigorously vetted EV, but from the point of view of AppLocker and App Control publisher rules, you can write a rule the same way with either. App Control does provide a rule option to require EV signing (Required:EV Signers), but the documentation states plainly that it is currently not supported, so there is presently no reason to choose EV for the sake of execution control.⁷

Thinking about cost. The price varies by CA and validity period, so you’ll need to get a quote, but knowing the structure of what’s included makes comparison easier. Since 1 June 2023, under CA/Browser Forum requirements, both OV and EV certificates must have their private key generated and stored on hardware equivalent to FIPS 140-2 Level 2 or higher (an HSM or a USB token).⁸ That means the cost includes not just “the certificate itself” but also “the fee for the token/HSM, or for a cloud signing service offered by the CA”. If you want to sign automatically in CI/CD, a cloud signing service is generally easier to set up than a physical token, so raise how you plan to operate signing when you get the quote.

The minimal signing command. Use signtool, which ships with the Windows SDK.

:: Sign the file (hash with SHA-256, add an RFC 3161 timestamp)
signtool sign /fd sha256 /tr <timestamp server URL> /td sha256 /a MyApp.exe

:: Verify the signature (validate against Authenticode policy, show details)
signtool verify /pa /v MyApp.exe

/fd is the file hash algorithm, /tr is the RFC 3161 timestamp server URL, /td is the timestamp’s hash algorithm, and /a tells it to automatically select the appropriate certificate from the certificate store. Use the timestamp server URL provided by the CA you bought the certificate from. If you’re signing with a key on a token or HSM, the CSP/KSP specification will be in the CA’s setup guide. The same command works for DLLs and installers too, so the reliable approach is to run it over everything at the end of the build.

What breaks when you renew the certificate. A publisher rule is based on the signature’s publisher information (the certificate chain and subject). So the following kinds of change will silently stop matching the rule on the customer’s side.

• You changed how the company name is written (for example, changed the certificate subject from Komura Soft LLC to 合同会社小村ソフト, the formal Japanese company name). Even for the same company, a different string means a different publisher.
• You switched certificate authority. An App Control Publisher-level rule is a combination of “intermediate CA (PCA) certificate + the leaf certificate’s CN”, so changing CA changes the PCA and the rule stops matching.⁷
• You changed the executable’s file name or product name. A FilePublisher-level rule includes, in addition to the above, the original file name (OriginalFileName) and a minimum version.⁷

In every case the symptom is the same: the moment you ship the replacement update, the app stops starting, but only in that environment. And from the customer’s point of view it’s simply “it broke after an update”, so no one suspects the signature is the cause. When you renew or change a certificate, put the old and new signing information (subject, issuing CA) side by side in the release notes, so the customer’s IT department can add the rule.

6. Key Points for the Deploying Side (IT Department)

For the side deploying execution control on its own PCs, this article covers only the essentials.

1. Choose the technology. As a rule, App Control for Business. Add AppLocker alongside it for shared PCs that need user-level control, or for environments with a mix of older OS versions.² For fixed-purpose PCs such as kiosk terminals, narrowing things down with shell restrictions first (see “Kiosk Mode and Assigned Access”) keeps the rules simpler.
2. Always start in audit mode. With AppLocker set to “Audit only”, events 8003 and 8006 record what would have been blocked if enforced; with App Control’s audit mode, events 3076 and 8028 do the same.⁴⁵ The approach — collect until a full cycle of business operations has passed, then switch to enforcement — is exactly the same as for SMB signing or NTLM restriction. Note one prerequisite if you use AppLocker: AppLocker policy is not evaluated unless the Application Identity service (AppIDSvc) is running, and no events appear even in audit mode without it. Before you start auditing, configure this service to start automatically on the target machines.
3. Keep a ledger of exceptions. An old business app that continues to run unsigned has to be registered as a hash-rule exception. That list is, in effect, a list of “things that should eventually be replaced”, so tie it to your asset management and review it every year.

So you don’t have to be sent to another article, here is the minimal flow for step 2, “start in audit mode”.

For AppLocker (3 steps)

1. Turn on audit mode. In the Group Policy Management Editor (or secpol.msc locally), open Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker, right-click AppLocker, and choose Properties. Tick “Configured” for each rule collection (Executable Rules, Windows Installer Rules, Script Rules, Packaged app Rules) and select “Audit only”. Also create the default rules for each collection, and configure the Application Identity service (AppIDSvc) on the target machines to start automatically (without it running, policy is not evaluated and no events appear).

2. Collect events. Until a full cycle of business operations has passed, collect event 8003 (exe/DLL) from Microsoft-Windows-AppLocker/EXE and DLL, and event 8006 (scripts/MSI) from MSI and Script.⁴ There’s a catch here: the PowerShell in Section 4 is pinned to the log name “EXE and DLL”, so as written it will not pick up 8006 for scripts and MSIs. Because the logs are separate, you need to run it against both, as below.

    # In audit mode, collect "what would have been blocked if enforced" from both logs
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   -ErrorAction SilentlyContinue is added because Get-WinEvent returns an error for a log with no matching events at all. If packaged apps are also under control, add Packaged app-Deployment / Packaged app-Execution in the same form. Check that you’ve captured monthly and yearly batch jobs too.

3. Switch to enforcement. Fold what appeared under 8003 and 8006 into allow rules, then change to “Enforce rules” on the same Properties screen. After switching, monitor 8004 (exe/DLL blocks) and 8007 (script/MSI blocks).

For App Control for Business the flow is the same: distribute the policy XML with rule option 3 (Enabled:Audit Mode) set (configure it with the App Control Policy Wizard or the Set-RuleOption cmdlet), collect 3076 and 8028, then remove that option and switch to enforcement. Microsoft too recommends checking the impact with Enabled:Audit Mode first.⁷

7. Summary

• Think of execution control as split between SmartScreen, which “warns”, and AppLocker / App Control for Business / Smart App Control, which “block” (though SmartScreen too works as an effective block under a management policy that prohibits overriding the warning).
• AppLocker’s edition restriction has already been relaxed (Windows 10 2004 and later, all editions of Windows 11), and App Control has always worked on every client edition. “Our customers are on Pro, so this doesn’t apply to us” no longer holds.¹²
• With Smart App Control, execution control has arrived even on personal PCs that no one manages. An unsigned distributable may fail to run for that reason alone.³
• Confirm a block from the event log. For AppLocker, the key event is 8004 (the EXE and DLL log); for App Control, it is 3077 together with signature-info event 3089 (the CodeIntegrity - Operational log).⁴⁵
• What the distributing side can do: consistent signing across every binary, timestamping, a conventional install location, signed auto-update, and providing information in the deployment guide. Making the app easy for the customer to write rules for is the whole of block prevention.
• The deploying side should collect a full cycle in audit mode (8003 / 3076) before moving to enforcement. This approach is the same as for other security hardening measures.

Related Articles

• Why Windows Shows “Windows protected your PC”
• Security Design for Auto-Update - Why HTTPS Alone Is Not Enough
• Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater
• PowerShell Execution Policy and Script Signing — A Practical Guide to Graduating From “Papering Over It With Bypass”
• When Your In-House Windows App Gets Flagged as a Virus — Handling Microsoft Defender False Positives and Living With the Performance Impact
• Locking Down Business Terminals with Kiosk Mode — Choosing Between Assigned Access and Shell Launcher, and Designing for Operation
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement

Related Consulting Areas

KomuraSoft LLC handles development and modification of business applications that run correctly under execution control environments (AppLocker / App Control for Business), designing distribution and auto-update with code signing built in, and investigating cases where an app fails to start in a customer environment.

• Windows Application Development
• Windows Modernization & Maintenance
• Bug Investigation & Root-Cause Analysis
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Isn't AppLocker unusable on the Pro edition?

That assumption is out of date. From KB 5024351 onward, enforcing AppLocker policy no longer requires a specific edition on Windows 10 version 2004 and later, or on any edition of Windows 11. The old restriction — "enforcement via Group Policy distribution is limited to the Enterprise and Server editions" — still applies only up to Windows 10 versions older than 2004 and Windows Server 2019 (and even then, distribution via MDM works on every edition). Even in an environment centred on small-business Pro machines, AppLocker is now a viable option.

Should we buy an EV code-signing certificate?

From the point of view of AppLocker and App Control for Business publisher rules, you can write a rule based on signer information with either an OV (organisation validation) or an EV certificate. Note also that the understanding "with EV, the SmartScreen warning disappears from the first run" is out of date; a file signed with EV now needs to be thought about on the same reputation-accumulation basis as OV (this point is covered in the separate article "Windows SmartScreen and Code Signing"). What matters more than the certificate type is signing every binary — not just the exe but DLLs and the installer too — with a consistent subject, adding a timestamp, and keeping the publisher information stable across certificate renewals. Publisher rules are written relying on that signer information, so if the signing state shifts from release to release, the rule on the customer's side breaks.

Our own app seems to have been blocked in a customer environment, but I can't find anything in the log. Where should I look?

The usual cause is that the log you need to check is split across two systems. An AppLocker block of an exe/DLL appears as event 8004 (or 8003 in audit mode) in the "AppLocker - EXE and DLL" log; scripts and MSIs appear as 8007 (or 8006) in the "AppLocker - MSI and Script" log. A block by App Control for Business (WDAC), on the other hand, appears as event 3077 (or 3076 in audit mode) in the "CodeIntegrity - Operational" log, with the corresponding signature information recorded in 3089. If a script, MSI, or COM object is caught by App Control, that also appears in the "AppLocker - MSI and Script" log, as 8029, 8036, or 8040. When you're investigating without knowing which mechanism is at work, line up both CodeIntegrity - Operational and the logs under AppLocker by time and compare them.

What do we need to do to keep Smart App Control from blocking our own app?

In practice, code signing. When an app runs, Smart App Control checks the cloud security service's prediction of the app's safety and whether the app carries a valid signature, and blocks apps judged malicious as well as unsigned apps whose trustworthiness cannot be confirmed. Microsoft's own guidance to developers also lists signing your app with a valid certificate. One thing to watch, though, is the signing algorithm: Smart App Control's signature check does not support elliptic-curve cryptography (ECC) signatures, and only apps signed with an RSA-based certificate are eligible to be allowed to run. Smart App Control is not an enterprise management feature but a protection for personal users of Windows 11, and it is turned on or off automatically starting from evaluation mode, so from the distributing side it's safest to work on the assumption that "an unsigned executable may not run on a personal PC".

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.