In cybersecurity, we often chase the novel and the sophisticated. We hunt for advanced persistent threats, reverse-engineer custom malware, and build complex detections for esoteric techniques. Yet, one of the most powerful and foundational controls at our disposal remains one of the most challenging and misunderstood: application control.

For too long, app control has been relegated to a simple, almost archaic definition: blocking unknown executables. But in 2026, that view is dangerously incomplete. A modern approach to app control is not just about stopping malware; it’s about controlling script execution, taming living-off-the-land binaries (LOLBins), and preventing dynamic link library (DLL) side-loading.

This blog is a high-level look at what app control means today, why it’s difficult to get right, and most importantly, how you can leverage it to make a meaningful, measurable impact on your organization’s security posture.

Redefining app control for a new era

Let’s level-set. When we talk about app control, we’re talking about a system that allows or blocks app execution based on established rules. Traditionally, these rules were based on simple attributes:

• Hash: The most secure and specific, but a nightmare to maintain
• Path: Simple, but easily abused if the path is user-writable
• Publisher/signature: A good balance, but relies on developers signing their code correctly
• File reputation: Often a dynamic, cloud-driven security feature leveraged by endpoint detection and response (EDR) or antivirus solutions

The ultimate goal, or the ideal state, of app control is to implement a default-deny policy. This is what used to be called “application allowlisting.” In this model, nothing runs unless it is explicitly trusted. You baseline your environment, identify all approved software, and create a comprehensive set of rules that comprise “trusted.” Everything else is blocked by default.

It sounds perfect. It sounds impenetrable. And it is, in theory, an incredibly powerful security stance. By implementing a strong, allow-only rule set as part of an application control policy you can eliminate entire classes of MITRE ATT&CK® techniques, many traced to routinely detected threats, before they even have a chance.

The chasm between ideal and reality

As anyone who has tried to implement this type of scenario knows, this quickly collides with operational reality. The process of baselining an entire fleet, identifying every required installer, path, and signer, is arduous. The real world is messy, and a rigid policy can bring an organization to a screeching halt.

Consider a common scenario: you’re a Zoom shop, but a prospective customer needs to meet today and they only use WebEx. In a strict enforcement environment, a user can’t simply download and run the WebEx installer. They’d have to file an IT ticket, wait for security to vet the application, and have an exception rule pushed to their device. The business opportunity could be lost. This highlights the critical need for any app control solution to have a process for efficient exception management.

Too rigid of an app control policy can bring your organization to a screeching halt.

On Windows, which has the most mature built-in offerings and mostly what we’ll be discussing in this blog, there isn’t an easy solution for this. You either have to build a workflow yourself or look to commercial solutions—more on those later—that specialize in solving this problem.

This forces us to make compromises. The most common and necessary compromise is trusting the operating system vendor. To run Windows, you generally have to allow Microsoft-signed code to execute. There’s no practical way around it. But this broad allow rule opens a Pandora’s box of another kind: LOLBins.

LOLBins are nothing to laugh about

PowerShell is the canonical example, but the list is long—msbuild.exe, mshta.exe, rundll32.exe, and countless others. These legitimate, dual-purpose, Microsoft-signed tools can be abused by adversaries to execute arbitrary code, bypassing the very signature-based rules we rely on. This forces us into a hybrid model: broad allow rules (like for Microsoft) paired with a curated list of explicit deny rules for known LOLBins. Does this block the next LOLBin that a researcher discovers that could allow arbitrary code execution? No—but don’t let the existence of bypasses dissuade you from trying to implement it in your environment.

By having a solid app control policy in place, you can go a long way in reducing your organization’s attack surface, eliminating both common threats and, as a bonus, many advanced techniques that rely on executing custom tooling. Doing this allows your defenders to focus their limited time and resources on the far more narrow attack surface that remains.

Why is this so hard? The common failures

If app control is so great, why isn’t it everywhere? The failures often stem from a few key challenges.

Breaking legitimate workflows

This is the number one fear and a very real risk. Overly strict policies generate false positives and prevent users from doing their jobs, leading to a flood of help desk tickets and frustrated employees.

Legacy apps and unsigned binaries

In a perfect world, every component of an application would be neatly signed by a single, reputable certificate. In reality, apps are often a patchwork of signed and unsigned binaries, different signers for different DLLs, and ancient legacy tools that have never been signed at all. Not to mention, as we’ve seen, just because a binary is signed, doesn’t necessarily mean it’s a safe one. All of this forces a messy mix of signer rules, fragile hash-based rules for unsigned components, and risky file path rules to make things work.

Dev tools everywhere!

The modern developer’s toolkit is a minefield for app control. An environment running something like Visual Studio Code (VS Code) is a perfect example. It’s a highly extensible platform that legitimately spawns child processes like cmd.exe and PowerShell, downloads extensions, and executes code in ways that are nearly indistinguishable from malicious activity. Trying to create a maintainable allowlist for a developer’s machine is one of the toughest challenges in this space.

Another great example of a practical challenge is firmware and driver updates. How do you allow these critical updates without opening a hole? Thankfully, modern systems provide solutions. Windows Defender Application Control (WDAC), for example, allows for separate user-mode and kernel-mode policies. Over the years, Microsoft has become increasingly strict about kernel security, enforcing mandatory driver signing. Starting with Windows 11 22H2, the Microsoft Vulnerable Driver Blocklist is enabled by default. Using a strong deny policy to block known living off the land drivers (LOLdrivers) without you having to lift a finger is app control in action.

How to start and succeed with app control in 2026

The prospect of a full-scale deployment can be paralyzing. The key is to reframe the goal. It’s not a binary state of unenforced vs. enforced. It’s a journey of continuous improvement.

Step 1: Start in audit mode. Just do it.

This is the single most important piece of advice. Configure your app control policy and put it into audit mode across your fleet. If you do nothing else, you have just created an incredibly valuable source of telemetry. You’ll gain a deep understanding of what is actually executing in your environment. Solutions like Microsoft Defender for Endpoint will ingest these audit events, giving you rich data—including signer information—on every process that would have been blocked if it was in enforcement mode. This is a powerful, complementary data source for your existing EDR and a fantastic threat hunting resource as well.

Step 2: Prioritize your crown jewels (Tier-0 assets).

Don’t try to boil the ocean. A full enforcement rollout across a heterogeneous environment of Windows endpoints is not a realistic starting point. Instead, prioritize enforcement around your Tier-0 assets: sensitive jump boxes, critical web servers, even domain controllers. These systems typically have a much more predictable and uniform set of running processes, making them ideal candidates for a strict enforcement policy. Start small, prove the value, and then expand your scope.

Step 3: Treat policy development like detection engineering.

Your app control policy is not a “set it and forget it” configuration. It is a living entity that requires continuous refinement and tuning. As you start in audit mode, you’ll begin with a wide funnel—perhaps broad file path or publisher rules. As you analyze the audit logs, you can gradually tune out the noise, replacing broad rules with more specific, secure ones (e.g., moving from a path rule to a signer rule, or even a hash rule for a specific unsigned binary). This iterative process of refinement is similar to how a good detection engineering team operates.

Step 4: Use built-in defenses.

When dealing with script-based attacks like paste-and-run (or ClickFix) payloads—where users are socially engineered into pasting malicious PowerShell into a terminal—a properly enforced policy is your best defense. When a Windows Application Control user-mode policy—like WDAC or AppLocker—is active, it automatically enables PowerShell Constrained Language Mode. This is a legitimate security boundary, serviced by Microsoft, that explicitly blocks the commands that an adversary could use to gain arbitrary code execution.

App control: The force multiplier for your security program

It is critical to understand that app control is not a replacement for your EDR or antivirus. It is a supplement—a force multiplier that makes every other part of your security program more effective.

By eliminating the vast majority of common and opportunistic threats, you dramatically reduce the noise your SOC has to deal with. This frees up your analysts and detection engineers to focus their efforts on the much smaller, more nuanced set of activities that are still allowed. It forces adversaries off their favorite tools and through narrow chokepoints where EDR and human hunters are waiting for them.

The journey to effective app control is a marathon, not a sprint.

The cultural win is just as important. App control is a partnership. It cannot be unilaterally implemented by the security operations team. Because it’s so close to what users are doing and how systems work, you must partner with IT and developer teams early and often. The cost of a broken workflow is a shared one, and the path to a successful, low-friction implementation is through collaboration.

The principles of app control—of defining “known good” and denying everything else—can even be extended beyond the endpoint. We’re seeing similar concepts applied to identity, with tools emerging to help assess and lock down application permissions in cloud environments like Entra ID.

The journey to effective app control is a marathon, not a sprint. But by starting with audit mode, focusing on your most critical assets, and embracing a philosophy of continuous refinement, you can build one of the most robust and effective defenses available today. You can move beyond the simple blocklist and truly master control of your environment.

Further reading and resources

For those looking to dive deeper on all things app control, here are some excellent resources:

• Windows application control overview: Microsoft Docs
• Microsoft recommended driver block rules: Microsoft Docs
• Applications that can bypass app control: Microsoft Docs
• Santa (for macOS): GitHub
• Commercial solutions:
  • Airlock Digital
  • Carbon Black app control