Most application control projects fail in operations, not in the product demo: policies stay in audit mode for years because nobody can keep up with software changes, exceptions and helpdesk calls. This vendor-neutral buyer's guide helps you choose an application control or endpoint prevention product, whether it manages the operating system's built-in enforcement or brings its own agent. It focuses on what decides success: how trust is established, how change is absorbed, whether the product meets the Essential Eight maturity level you are targeting, and how much effort each blocked event costs. It is written for endpoint engineers, security architects and evaluation panels. How allowlisting works, rule types and rollout technique are in the Application Allowlisting Guide; this page is about buying.
Key takeaways
- Buy for change management, not for blocking: the deciding question is how new and updated software becomes trusted without a ticket for every patch.
- Map the product to a maturity level: Essential Eight Maturity Level Two and Three add servers, Microsoft's recommended block rules, driver restriction and central logging, and Microsoft states reputation-based trust alone does not meet them.
- Prefer publisher and hash trust over paths in user-writable locations, and ask exactly which file types the product controls: executables, libraries, scripts, installers and drivers.
- Measure the operating cost in a pilot: time from a blocked request to an approved rule, false blocks per hundred devices, and the share of devices that reach enforcement.
- Treat the console as a privileged system: whoever can edit the policy can allow anything to run on every endpoint.
Define requirements
- Target outcome: the framework level you must evidence, such as Essential Eight Maturity Level One, Two or Three, CIS Controls v8.1 safeguards 2.5 (allowlist authorised software), 2.6 (allowlist authorised libraries) and 2.7 (allowlist authorised scripts), or NIST SP 800-53 CM-7(5) authorised software, allow by exception. See the Essential Eight Guide.
- Estate: counts of Windows workstations and servers by version, macOS and Linux endpoints, virtual desktops, kiosks and offline or air-gapped devices. Native Windows options and their limits are covered in App Control for Business (WDAC); Linux in the fapolicyd and Linux Application Allowlisting Guide.
- Software churn: how many titles you run, how software arrives (management tool, store, developer builds, user installs), and the weekly volume of updates. High churn favours products with a strong managed installer or trusted updater model.
- Prevention scope beyond execution: whether you also need ringfencing (limiting what allowed applications can reach on disk, network and registry), storage device control, privilege elevation or script interpreter controls. Elevation has its own market: see the Endpoint Privilege Management Buyer's Guide.
- Coexistence: your EDR, management tool and SIEM. Decide whether application control must run alongside EDR or come from the same agent; see the EDR and XDR Buyer's Guide.
- Operating model: who approves requests, out-of-hours cover, and the service level for unblocking a business-critical application.
Capability areas
| Area | What to look for | Why it matters |
|---|---|---|
| Trust model | Publisher (certificate) rules, hash rules, path rules restricted to admin-writable locations, managed installer or trusted updater, optional reputation service | Microsoft advises against path rules for user profiles and temporary folders because users can write there |
| File type coverage | Executables, DLLs and libraries, scripts (PowerShell, VBScript, JavaScript, batch), installers (MSI), compiled HTML, HTML applications, control panel applets, drivers | Essential Eight ISM-1657 lists executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets |
| Blocklists for trusted binaries | Built-in support for Microsoft's recommended block rules and recommended driver block rules, kept current | Required at Maturity Level Two (ISM-1544) and Three (ISM-1659); signed system tools are a common bypass (ATT&CK T1218) |
| Driver control | Approved driver sets and vulnerable driver blocking, ideally with hypervisor-protected code integrity | ISM-1658 at Level Three; vulnerable drivers are used to kill security tools. See the BYOVD and EDR Killers Guide |
| Policy lifecycle | Audit mode, staged rings, policy versioning and diff, rollback, base and supplemental policies, rule expiry | Determines whether you can enforce safely and undo a bad change in minutes |
| Request and approval workflow | User request from the block prompt, approver context (signer, hash, prevalence, reputation), time-limited exceptions, integration with ticketing | The workflow is where most operating cost sits |
| Ringfencing and containment | Rules limiting child processes, file, registry and network access for allowed applications, especially interpreters and Office | Allowed but abusable software (T1059.001 PowerShell, T1204.002 malicious file) is the usual gap |
| Logging and reporting | Allowed and blocked events forwarded centrally in a documented schema, tamper protection, retention, per-rule reports | ISM-1660 requires central logging of allowed and blocked events at Level Two |
| Platform coverage | Windows client and server versions, macOS, Linux distributions, VDI, offline devices with cached policy | Level Two extends control to internet-facing servers (ISM-1490) and other locations (ISM-1871); Level Three to other servers (ISM-1656) |
Evaluation criteria
| Criterion | Illustrative weight | Good evidence |
|---|---|---|
| Operational efficiency | 25% | Pilot data: share of devices enforced by week four, median time from request to rule, false blocks per 100 devices per week |
| Control depth and coverage | 20% | File types enforced on each OS, blocklist support, driver control, ringfencing, behaviour when the agent or service stops |
| Framework fit | 15% | Mapping of each Essential Eight application control requirement at your target level to a named product setting, with an assessor-ready report |
| Change absorption | 15% | Number of routine updates in the pilot that needed no manual rule |
| Security of the product | 10% | Console SSO with phishing-resistant MFA, granular roles, approval for policy changes, audit log of every rule change, agent tamper protection |
| Integration | 10% | SIEM export, EDR coexistence, management tool and ticketing integration, API for policy as code |
| Commercials | 5% | Per-device or per-user metric, server pricing, modules sold separately (ringfencing, storage control, elevation), renewal caps |
Weights are illustrative. An organisation with a stable estate and a mature management tool may get most of the value from the operating system's built-in enforcement plus a management and reporting layer; one with high software churn, many unmanaged installs or mixed operating systems will usually weight workflow and change absorption higher. Microsoft's Essential Eight guidance states that AppLocker can meet Maturity Level One but Levels Two and Three need App Control for Business (WDAC), and that its reputation-based option does not meet Levels Two or Three on its own; ask any product that relies on reputation how it meets ISM-1657 and the annual ruleset validation in ISM-1582. In framework terms the product implements NIST CSF 2.0 PR.PS-05 (installation and execution of unauthorised software are prevented) and supports DE.CM-09 through its event stream; in NIST SP 800-53 it maps to CM-7(5), CM-11 user-installed software and SI-7 software integrity.
Questions to ask vendors
- Show how a routine update to an approved application is trusted automatically. What happens to an update from a publisher whose certificate changed?
- Which file types do you enforce on each operating system, and which do you only log? Do you control DLLs and scripts, or only executables?
- How do you deliver and update Microsoft's recommended block rules and driver block rules, and how quickly after Microsoft updates them?
- Map each application control requirement at Essential Eight Maturity Level [Two] to a product setting and to the evidence an assessor would see.
- If you use a reputation or cloud trust service, what happens to a device that is offline, and can we turn reputation off for high-security groups?
- What does the user see when blocked, and how does an approver decide? Show the context provided for one real block.
- Who can change policy, is a second approval supported, and is every rule change logged with who, what and when?
- Can policies be held in version control and deployed through an API, and how do we roll back the last change on every device?
- What happens if your agent crashes or is removed: does enforcement fail open or closed, and what alert fires?
- What runs with the highest privilege on our endpoints, and how is your update channel signed and protected?
Red flags
- Coverage figures quoted only for executables, with libraries, scripts or drivers left to "roadmap".
- Default rules that trust whole folders such as user profiles, downloads or temporary directories.
- A deployment plan that stays in audit or "learning" mode indefinitely with no enforcement milestones.
- Claims that a reputation service alone delivers Essential Eight Level Two or Three.
- No way to see or export allowed and blocked events, or events kept only in the vendor console for a short period.
- Policy changes possible by any console administrator with no approval, versioning or audit trail.
- Broad exclusions requested for the vendor's own agent or for scripting hosts to make the pilot pass.
Proof of concept
- Pick three pilot groups: a standard office build, a high-churn group (developers or engineering) and one internet-facing server. Agree success criteria in writing first.
- Deploy in audit mode for two weeks. Record unique files seen, proposed rules and how many come from publisher, hash, path or reputation trust.
- Enforce on the office build, then the high-churn group. Count blocks, false blocks, requests and median time to approval each week.
- Run a defensive test set in a lab: an unsigned executable and script in a user profile, a library loaded from a writable folder (T1574.001), a signed system binary on the recommended block list and a known vulnerable driver. Record which are blocked and which only logged.
- Push a normal monthly patch cycle and two application upgrades. Count manual rules needed.
- Stop the agent or service as an administrator and confirm the alert, the enforcement state and the event in your SIEM.
- Make a deliberately bad policy change, then time the rollback across the pilot.
- Export the event data and an assessor-style report mapped to your target maturity level.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support for endpoint and identity controls, including how application control interacts with local administrator rights, service accounts and the privileged identities that manage endpoint policy. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Application Allowlisting Guide · App Control for Business (WDAC) · Essential Eight Maturity Level Assessment Guide · Endpoint Security Guide · Security Vendor Evaluation and RFP Guide