Unlicensed software isn't just a compliance risk on paper, it's a real audit exposure and a common malware vector. Here's how policy-based blocking keeps it off your endpoints in the first place.
Software license audits rarely turn up surprises IT already knew about. They turn up the free trial someone never uninstalled, the personal license running on a company laptop, or the cracked utility a contractor installed to get a job done quickly. Each one is a license compliance risk, and depending on the software, a security risk too, since unlicensed and pirated software frequently ships with disabled update mechanisms or bundled malware. Application control addresses this at the source: instead of finding unlicensed software during an audit, you stop it from running in the first place.
IT Asset Management gives you visibility, an accurate record of what's installed and what's licensed against it. Software Metering adds a third layer that inventory alone can't: actual usage data, showing whether an installed, licensed application is genuinely being used or sitting idle. That distinction matters for compliance in both directions. Metering data can flag a seat that's installed but never launched, a candidate for reclaiming or downgrading a license, and it can just as easily confirm that a flagged application is in real, active use before you build a block rule around it. Application control gives you enforcement, the ability to act on inventory and usage data by blocking anything that falls outside your licensed software list. The three work together: inventory and license records tell you what's installed against what's entitled, metering tells you what's actually being used, and an application control block list stops unlicensed or non-compliant software from running once identified.
Without the enforcement layer, license compliance becomes a recurring cleanup exercise. Someone reinstalls the same unlicensed tool a month after IT removed it, and the cycle repeats. A block list rule, by contrast, stops it from launching every time, regardless of how many times it gets reinstalled.
Known unlicensed or cracked software identified through prior audits or inventory scans, blocked outright by product name or executable.
Expired trial software that was never formally licensed or removed, a common and often overlooked compliance gap.
Personal or consumer-tier software running on company devices where only an enterprise license is compliant, blocked by vendor or product rule while the licensed enterprise version remains allowed.
Duplicate or shadow installations of software your organization already licenses through a different, unmanaged channel, which inflates your effective license count without IT's knowledge.
Start from your actual license and usage data, not assumptions. Cross-reference software license management records against what's installed, and check software metering data to confirm whether a flagged application is genuinely in use before deciding whether it belongs on a block list or simply needs its license reassigned.
Create an Application Group with a Block List Access Type for confirmed unlicensed or non-compliant software, and tag it with an appropriate Risk Level based on the legal and security exposure involved.
Use Product/Software or Vendor rules for most entries, reserving File Hash rules for cases where you need to block one specific unlicensed build without affecting a properly licensed version of the same title.
Run Audit Only first to confirm the block list doesn't catch a properly licensed installation by mistake, since a Product Name rule that's too broad can inadvertently block compliant use.
Move to Block & Notify once confirmed, so users see a message explaining the software isn't licensed for use rather than a confusing, unexplained failure.
Once the policy is live, the violations dashboard becomes your ongoing compliance record: every blocked attempt logged by device, user, application, and reported time. That's useful for two audiences. It gives IT a running list of where unlicensed software keeps getting reintroduced, often pointing to a real, unmet business need worth formally licensing. And it gives you a defensible audit trail showing active enforcement, not just a policy document, when a software vendor or licensing body comes asking. See the Application Control overview for the full walkthrough of policy setup, or our best practices guide for a phased rollout approach.
Block it once and it stays blocked, no matter how many times it gets reinstalled. Pair enforcement with usage data from Software Metering to catch both compliance gaps and licenses you're paying for but not using.
• No credit card required • 14 day free trial
No. Application control enforces a policy once you know what should and shouldn't be running; it doesn't replace the license reconciliation work of comparing installed software against purchased entitlements, or the usage analysis that tells you whether a license is worth keeping in the first place. Think of ITAM and metering as the audit and usage evidence, and application control as the enforcement that keeps the findings from reappearing.
Yes, this is exactly what File Hash or version-specific Product/Software rules are for: block the unlicensed build by its specific identifier while a separate rule allows the properly licensed version to run without interruption.
Pull your current software inventory and cross-reference it against your license records to spot unlicensed installs, then check software metering data to see which licensed applications are barely used, a common source of avoidable licensing cost that inventory alone won't reveal. Running an Audit Only application control policy across your fleet adds a third view, everything actively attempting to launch, before deciding what belongs on a block list.