Essential Eight application control WDAC vs AppLocker

Which tool does Essential Eight application control need: WDAC or AppLocker?

Microsoft's Essential Eight application control guidance says Maturity Level 1 can be achieved with Microsoft AppLocker, while Maturity Levels 2 and 3 require Windows Defender Application Control (WDAC) because of additional Information Security Manual requirements. If you are working toward ML2 or ML3, plan on WDAC from the start rather than building AppLocker rules you will later have to rewrite. The decision still depends on your target level, the device types in scope (workstations, servers and shared devices), and whether AppLocker stays in place as a complement.

Microsoft recommends WDAC over AppLocker and notes that AppLocker still receives security fixes but no new features. AppLocker remains useful in a specific case: shared devices where particular users must be blocked from a particular application. Confirm with your team which devices are shared, which users need individual blocks, and whether an existing AppLocker policy already covers them. Mixing the two tools needs a clear owner for each policy, or the rulesets will drift apart over time. Also confirm with your assessor how they will treat a complemented design before you build it.

Your organization owns the application control decision and the rulesets, and it stays accountable for keeping them current. An implementation partner can prepare policies, test them and collect logs, but it does not decide the maturity level achieved. Only an independent assessor can judge whether your implementation and its effectiveness meet the Essential Eight maturity model. Use the Essential Eight maturity model on cyber.gov.au as the reference your assessor will work from, and agree the target level and the tool choice in writing before rule design begins.

How the tool choice changes by maturity level

At Maturity Level One, Microsoft's guidance states that AppLocker is sufficient. This makes it the lowest-cost route for organizations that have not yet deployed WDAC and are focused on restricting execution on workstation user profiles first. The ML1 requirements are a subset of the higher levels, so an AppLocker policy built now should be designed so it can be carried forward rather than discarded.

Tool acceptable: AppLocker is recognized by Microsoft as achieving ML1 for application control.
Rule types: Publisher, hash and path rules are the options to design around, with path rules limited to folders that users cannot modify.
Scope: Workstation user profiles are the typical starting point for ML1 coverage.
Blocklists: Plan for Microsoft's recommended application blocklist (ISM-1544) even at this level, since it is a requirement the profile carries forward.
Upgrade path: Keep rule design portable so that the policy can be reviewed when moving to WDAC for ML2.

Confirm the final ML1 mapping against the ISM Essential Eight ML1 profile, since the mapping is what an assessor will test.

Which rule types ASD considers suitable

WDAC and AppLocker both let you write rules by hash, publisher or path, and the Essential Eight only accepts some of those choices in some places. The cards below cover the rule types ASD treats as suitable, the conditions attached to path rules, and the blocklists that carry the most weight at higher maturity levels.

Cryptographic hash rules

A hash rule allows or blocks one exact file by its cryptographic hash. It is precise and does not depend on where a file sits or who signed it, which makes it a strong fit for small, stable sets of approved executables. The trade-off is maintenance: every update to a file produces a new hash, so the ruleset must be revisited after each patch. Check how your team will refresh hashes during change windows, because a stale hash rule will either block a legitimate update or leave an old binary permitted.

Publisher certificate rules

A publisher rule trusts files signed by a named certificate publisher, often with version and product name conditions. It survives routine updates from that vendor without rewriting the ruleset, so it is usually the most practical rule type for commercial software. Review which publishers you trust and whether any certificate can sign code outside the product you intended. Narrow rules to a specific product where the platform allows it, rather than trusting a whole publisher by default.

Path rules with strict folder permissions

A path rule allows execution from a folder. ASD considers this suitable only where file system permissions stop users from changing the folders and files inside that path. Before writing a path rule, confirm with a permission audit that standard users cannot add, replace or modify content there, including through shared or inherited permissions. Re-run that audit whenever folder structures or group memberships change, because a single writable subfolder can undo the control.

Path rules in user profiles and temp folders

User profiles, downloads folders and temporary directories are the places where users can write files, so path rules that allow execution from them are not recommended under ISM-1870. Malware commonly lands in these locations first. If a business application installs there, ask the vendor for a supported installation location or use a publisher or hash rule for that application instead. Treat any existing rule of this kind as a finding to remediate, not a default to preserve.

Recommended block rules

Microsoft's recommended block rules for applications map to ISM-1544, which requires its recommended application blocklist to be implemented. These rules stop known-vulnerable or abused applications and are a baseline rather than a complete list. Deploy them in audit mode first to confirm they do not break approved business software, then enforce them. Record the policy version you deployed, since assessors will ask which blocklist was in force on a given date.

Recommended driver block rules

Microsoft's recommended driver block rules map to ISM-1659, which covers blocking drivers known to be vulnerable and abusable. Pair them with driver application control, which Microsoft maps to hypervisor-protected code integrity, enabled by default on Windows 11 2022 and later. Test driver blocks on representative hardware, because blocking a storage, network or endpoint security driver can stop a device from starting. Confirm the blocklist version in your policy matches the version you documented for the assessor.

Covering executables, scripts, drivers and blocklists

The core requirement behind this section is ISM-1657, which asks that application control restrict execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organization-approved set. Many teams build WDAC or AppLocker policies that only cover .exe files and then assume the rest is covered. Before writing rules, list each of these file types in your environment, confirm which ones your policy engine governs, and document how your approved set treats each one. Scripts and installers are where most gaps appear, particularly PowerShell, Windows Script Host, and MSI packages launched by users or by deployment tools. Expect to decide case by case whether a script runtime is allowed, constrained, or blocked, and record that decision as part of your approved set.

ISM-1658 addresses driver control, which is a separate decision from user-mode execution. Microsoft links this control to hypervisor-protected code integrity, and states that this feature is enabled by default on Windows 11 2022 and later. Do not assume that default covers your estate. Confirm the Windows version on each device class, check whether the feature is running on the devices you manage, and test that approved third-party drivers, such as storage, endpoint security and virtualization drivers, still load after enforcement. Driver failures often appear as boot or hardware issues rather than policy events, so include driver validation in your change process before enforcement.

Two blocklists sit on top of the approved set. ISM-1544 requires the recommended application blocklist to be implemented, and ISM-1659 covers the recommended driver blocklist, which Microsoft maps to its recommended driver block rules. Both lists change over time as vulnerable binaries are discovered, so the requirement is not satisfied by a one-time import. Assign an owner, record the version of the blocklist applied to each policy, and review updates on a schedule you can evidence. Your annual ruleset validation under ISM-1582 is the natural point to confirm that the blocklists in production match the current Microsoft recommendations. Check the Microsoft Learn Essential Eight application control guidance for the current block rule references before you finalize your evidence.

How the rollout moves from audit mode to enforcement

The sequence starts with knowing what runs in your estate and ends with a policy that enforces the approved set and a dated record showing the ruleset still matches it. Each phase produces an artifact that the next phase depends on, so an assessor can trace an enforced rule back to the inventory that justified it.

Inventory applications and device groups
The organization's application owners and IT operations build a list of executables, scripts, installers, libraries and drivers in use, grouped by device role such as workstation user profiles, shared devices and servers. The platform team pulls file and publisher data from the endpoints in scope so the list reflects what is installed, not what is documented. The step is complete when every device group has a named owner and the inventory is signed off as the baseline for the approved set. Ask your partner to show how the inventory is stored and versioned, because it is the first evidence an assessor will request.
Design the approved set and rule types
Using the inventory, the organization decides which software is approved and which rule type covers each item: publisher certificate rules where the vendor signs its files, cryptographic hash rules for unsigned or unstable files, and path rules only where file system permissions stop standard users from changing the folders. Path rules for user profiles and temporary folders are excluded. Blocklists from Microsoft's recommended sets are added at this stage. The output is a written rule set with a justification for each rule, and it is the document that later validation will test against.
Deploy in audit mode to a pilot group
The rule set is deployed in a mode that logs would-be blocks without stopping execution, to a small pilot group chosen to represent each device role. Central logging is confirmed first so that allowed and blocked events reach the security team's log platform. The operations team reviews every event that would have been blocked and sorts it into three outcomes: a missing approved application, a rule that is too broad, or a genuinely unwanted executable. The output is a pilot results report listing each event category and the change made in response.
Correct rules and repeat the pilot
Each rule change from the pilot review is recorded with its reason, the approver and the date, then the policy is redeployed to the pilot group. The cycle repeats until the audit log contains no unexplained events for the approved set. Some vendors update binaries frequently, so the team confirms how updates are handled before enforcement, for example by publisher rules or by an agreed process for hash rule replacement. The output is a change log tied to the rule set version, which shows the policy was tuned on evidence rather than guesswork.
Switch to enforcement in staged rings
The policy is moved from audit to enforcement one device group at a time, starting with the group that has the cleanest pilot results. Help desk staff are briefed on the blocked-application message and on the exception request route before each ring changes. The team watches blocked-event volumes after each change and can roll a ring back to audit mode if a legitimate application is stopped. The output is an enforced policy with a deployment record per ring, showing the enforcement date and the group covered.
Document exceptions and the approval path
Any request to run an application outside the approved set goes through a written exception process with an owner, a business reason, a risk assessment and an expiry. Exceptions are added to the rule set only after approval, and the change is recorded like any other rule change. Microsoft treats this process and the incident response steps around blocked events as people and process controls outside its technical guidance, so the organization writes them itself. The output is an exception register linked to the rule set version.
Validate the ruleset at least annually
The application owners and the security lead review the enforced rule set against the current inventory, confirm that each rule still has a justification, and check that blocklists and driver controls are current. The review is performed at least once a year, as the ISM requires for application control rulesets, and the outcome is recorded with the reviewer, the date and any changes made. Microsoft suggests storing this documentation in Purview Compliance Manager as evidence. The output is a signed validation record, which becomes the starting point for the next cycle. Confirm the review cadence and evidence format with your assessor before you agree the written scope.

Process controls Microsoft leaves to you

Microsoft's technical guidance stops at the rule set, the logs and the blocklists. The controls below depend on people, documented decisions and sign-off from your own organization, and an assessor will look for them as much as for the technical settings.

Annual ruleset validation

ISM-1582 requires application control rulesets to be validated at least annually. Validation means checking that each allow rule still matches an approved application, that publisher and hash rules still reflect current versions, and that removed software no longer has a live exception. Record who performed the review, the date, the rules changed and the approver. An assessor will ask for the most recent record, so schedule the review before the previous one lapses.

Incident reporting to the CISO and ASD

Application control events that point to an attempted compromise, such as repeated blocked executions from a user profile or a blocked driver, need a defined path to the CISO and, where the incident criteria are met, to ASD. Write down the triggers, the named roles and the timeframes in your own incident procedure. Test the path with a tabletop exercise so the reporting chain works before a real event.

Enacting the incident response plan

A written incident response plan is only evidence if staff follow it. When a blocked-event alert fires, the plan should say who triages it, how the device is isolated, which logs are preserved and when the event is closed. Keep a record of each activation, including the decisions taken and their times. Sample a few past alerts during internal review to confirm the steps were carried out as written.

Event analysis and review

Microsoft's guidance captures allowed and blocked events centrally, but collecting them does not satisfy the requirement on its own. Someone must analyze the events on a defined cadence, separate expected business blocks from suspicious ones, and feed findings back into rule changes. Document the review schedule, the analyst and the outcome of each review. Confirm that your review cadence meets the level you are targeting in the maturity model.

Storing evidence in Purview Compliance Manager

Microsoft suggests keeping the documentation for these process controls in Purview Compliance Manager, where it can sit alongside technical assessments. Compliance Manager holds the records, but it does not perform the reviews, reports or sign-offs for you. Assign owners to each improvement action, attach the signed review records and set reminders for the annual validation. Confirm with your assessor that this evidence format is acceptable for their testing.

Sign-off by accountable owners

Each process control needs a named owner who accepts the outcome, usually the CISO or a delegated security lead. Microsoft and any implementation partner can prepare the rule sets, logs and templates, but they cannot accept the risk or attest that the work was done. Keep signed approvals in the same repository as the evidence so the chain from decision to record is clear to an assessor.

What the work costs and who is paid for each part

The cost of application control under the Essential Eight is spread across four buckets, and each one is paid to a different party. The first is internal staff time. Someone in the organization has to build and maintain the application inventory, decide which publishers, paths and hashes are approved, and own each rule and its exception process. That work is paid from existing payroll, but it is rarely small, and it recurs because the ruleset must be validated at least annually under ISM-1582. Ask who in your organization holds rule ownership and how many hours that role is expected to spend on it each quarter before you commit to a timeline.

The second bucket is licensing. Microsoft's guidance uses Defender for Endpoint P2 for the central logging of allowed and blocked application control events, with Windows event logs captured in Microsoft Sentinel and Microsoft Defender XDR. Those products are licensed separately, Sentinel also bills on data ingestion, and both recur every year. Confirm current licensing and any per-user or per-gigabyte charges directly with Microsoft or your reseller, because terms change and your existing Microsoft 365 agreement may already include some of them. Our implementation partner fees, when they apply, are set out in a fixed written scope that lists the work, deliverables and timeline before anything starts, and a quote follows from that scope. DeployOpen does not publish a price list.

The third and fourth buckets are implementation partner fees and independent assessor fees. An implementation partner's work on WDAC or AppLocker rulesets, blocklists, driver control and logging is usually a one-time project cost, while ongoing ruleset validation and support may be a separate retainer. An independent assessor is paid to test the evidence and issue whatever report the engagement calls for. DeployOpen prepares systems and evidence but does not issue audit reports, attestations or certifications, so assessor fees are always separate. When you request quotes, ask each party to separate one-time setup, recurring tasks and licensing pass-throughs, and to state which deliverables they will hand over for the assessor.

What must be in place before an assessor reviews application control

An assessor testing application control will ask for six kinds of evidence, and each one depends on the others. The inventory defines what is allowed, the rule design explains why, and the audit mode results and event logs show whether the rules work. The validation record and signed incident response plan show that the organization keeps all of it current.

Approved application inventory

This is the list of executables, scripts, installers, libraries and other file types your organization has approved to run, with an owner and a business reason for each entry. Without it, no rule can be shown to match an approved set. To check it, pick ten entries at random and confirm each one traces to a named owner, a current version and a rule in the design. Ask who approves additions and how often the list is reviewed.

Documented rule design

The rule design records which rule types you chose for each folder, publisher or hash, and why. Microsoft lists cryptographic hash, publisher and path rules as methods ASD considers suitable, and path rules are acceptable only where file system permissions stop users changing the folders. To check it, confirm that every path rule points to a location users cannot write, and that user profile and temporary folders carry no path allowances.

Testing evidence in audit mode

Before enforcement, rules should run in audit mode so that you can see what they would block without stopping work. The assessor will want the audit results, the list of changes made after testing, and the sign-off for moving to enforcement. To check it, compare the audit log against the rules that went live and confirm that each blocked item in audit was either approved, added to the inventory or removed from scope.

Logs of allowed and blocked events

ISM-1660 requires central logging of allowed and blocked application control events. Microsoft's guidance uses Defender for Endpoint P2 with Windows event logs sent to Microsoft Sentinel and Microsoft Defender XDR, but any central store with retention and search will do if you can show it works. To check it, trigger a blocked test binary on one workstation and one server, then confirm both events arrive in the central store with the device, user and file identified.

Validated ruleset record

ISM-1582 requires application control rulesets to be validated at least annually. The record should show the date of each validation, who performed it, which rules were checked against the inventory and what was changed. Microsoft treats this as a process control and suggests keeping the documentation in Purview Compliance Manager. To check it, confirm the most recent validation falls within the last twelve months and that it lists specific rule identifiers, not only a sign-off line.

Signed incident response plan

Blocked execution events feed into incident handling, so the assessor will look for an incident response plan that covers application control alerts, approved by a named executive and dated. Microsoft lists enacting the plan, incident reporting to the CISO and ASD, and event analysis as people and process controls it leaves to you. To check it, walk through one simulated blocked malware event and confirm the plan names who triages it, who is told and where the record is kept.

Who owns each part of application control

The organization owns the control itself. Its leadership decides which applications, scripts, installers and drivers are approved to run, who signs off exceptions, and how often the ruleset is reviewed. These decisions cannot be delegated to a vendor because they define the approved set that the assessor will test against. The organization also owns the people and process controls that Microsoft's technical guidance leaves outside its scope.

Approved set: Business owners and the security function agree which software is allowed, and record the approval basis for each rule.
Annual ruleset validation: The organization validates application control rulesets at least annually (ISM-1582) and keeps dated records of each review.
Incident handling: Reporting to the CISO and to ASD, and enacting the incident response plan, are organizational duties.
Exception approval: Someone accountable approves, time-limits and revisits every exception to the ruleset.
Evidence ownership: The organization keeps the documentation, for example in Purview Compliance Manager, and answers the assessor's questions.

Before engaging anyone, confirm which named role signs each approval and where the review records will be kept.

Questions buyers ask about WDAC, AppLocker and Essential Eight

Can AppLocker alone meet the Essential Eight application control target level?

AppLocker can meet Maturity Level 1 according to Microsoft's Essential Eight application control guidance, but Maturity Levels 2 and 3 require Windows Defender Application Control (WDAC) because of additional ISM requirements. Microsoft also recommends WDAC over AppLocker, noting that AppLocker still receives security fixes but no new features. AppLocker can still complement WDAC, for example on shared devices where specific users must be blocked from an application. Confirm your target level and the exact ISM controls it covers against the Essential Eight maturity model before choosing a tool.

Is WDAC required at Maturity Level 2?

Yes. Microsoft's guidance states that Maturity Levels 2 and 3 require WDAC because of the additional ISM requirements, so AppLocker alone is not a path to ML2. Your team should still confirm this against the ISM baseline profile for ML2 in ASD's OSCAL release, since the profile lists the controls that apply. Plan for WDAC policy design, a validation process for rulesets, and central logging of allowed and blocked events, which ML2 expects to be captured centrally.

What does the work need from our own team?

Expect your team to own the decisions that a tool cannot make for you: which applications and publishers are approved, who can request exceptions, and who signs off on rulesets. Engineers need working knowledge of Group Policy or Intune deployment, Windows event logs, and Microsoft Sentinel or Defender XDR if you are centralizing logs. Your team also owns the annual ruleset validation and incident reporting steps, which Microsoft treats as people and process controls outside its technical guidance. A partner can prepare the policies and evidence, but the approvals and reviews remain with your organization.

How long does the engagement take?

The duration depends on the target maturity level, how many device types and servers are in scope, how many applications need approved-set review, and how much logging is already in place. DeployOpen does not publish fixed timelines. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask any provider for a written scope that lists the in-scope systems, the rule types to be used, the logging design and the handover items, then compare timelines against that document.

Can we implement application control ourselves?

Yes, if your team has the skills and capacity to build and maintain the work internally. Many organizations do the technical policy build in-house and bring in outside help for specific gaps, such as WDAC design for servers, driver control, or evidence packaging for an assessor. Before deciding, check whether your team can handle a test phase in audit mode, a staged rollout, exception handling, and a yearly validation cycle. Microsoft's guidance is the starting point for the technical settings, and your internal controls must still meet the ISM controls for your target level.

What evidence should an assessor expect for application control?

An assessor will typically look for the approved application set, the WDAC or AppLocker policy files and their deployment records, evidence of the recommended blocklist being applied, and driver control settings. They will also expect logs of allowed and blocked events, evidence of annual ruleset validation, and records of exception approvals and incident handling. Microsoft suggests storing people and process documentation in Purview Compliance Manager. Ask your assessor which artifacts they accept and how they want them organized before the assessment starts.

Can a partner issue an Essential Eight certificate?

No. The Essential Eight is a set of mitigation strategies rather than a certification scheme, and there is no ASD certificate. A partner such as DeployOpen can plan, implement and document the controls and prepare the evidence, but only an independent assessor can issue an assessment report or conclusion about your maturity level. Ask any provider to state its role in writing, and ask your assessor to confirm the evidence they need.

How DeployOpen scopes and prepares application control evidence

DeployOpen works on Essential Eight application control as a fixed-scope engagement inside your own infrastructure. We prepare the WDAC or AppLocker policies, logging and process documentation that your assessor will examine, while your organization keeps ownership of its controls and the assessment outcome.

How we scope

Confirm the target maturity level and which device groups, servers and user populations the application control policies must cover.
Agree in writing which rule types, driver controls and blocklists apply, and which systems fall under WDAC or AppLocker.
Record which process controls, such as annual ruleset validation and incident reporting, remain with your staff and which we document.

How we build

Build WDAC policies or AppLocker rule sets in audit mode first, then move them to enforcement once allowed and blocked events are reviewed.
Prefer hash, publisher and suitably restricted path rules, and test path rules against folder permissions before relying on them.
Configure central capture of allowed and blocked application control events so the log evidence is available to your security team and assessor.

How we hand over

Deliver the policy files, rule inventories, blocklist configuration and logging settings in a documented form your team can maintain.
Provide test records showing blocked execution attempts, driver control behavior and the validation steps performed against each requirement.
Hand over a runbook for annual ruleset validation, change handling and evidence collection, and confirm who on your side owns each task.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, covering policy changes and new software approvals.
Re-run validation when Microsoft guidance changes or when your Windows estate or software inventory changes significantly.
Ask any independent assessor or certification body to confirm which evidence they accept, since DeployOpen prepares evidence but does not issue assessment outcomes.