What Essential Eight application control at ML1 requires on workstations
If you are preparing an Essential Eight assessment and need to show application control at Maturity Level One, the answer is direct: ML1 requires application control on workstations, applied to user profiles and temporary folders, and restricting execution to an approved set. The Australian Signals Directorate (ASD) sets this through its Information Security Manual (ISM), where three controls carry the ML1 requirement: ISM-0843, which requires application control on workstations; ISM-1870, which extends it to user profiles and temporary folders used by operating systems, web browsers and email clients; and ISM-1657, which restricts executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set. The risk being addressed is unapproved code running from locations users can write to, such as a downloaded installer run from a profile folder or a script dropped into a temporary directory. Note that the Essential Eight is a set of mitigations defined by ASD's maturity model, not a certification scheme. There is no ASD certificate. An assessor tests whether your implementation meets each control and is effective, and the ISM OSCAL profiles on the ASD mirror are the authoritative list to map your evidence against.
The difficulty is rarely the policy itself. It is the exceptions. Every workstation estate has line-of-business tools that install under a user profile, portable utilities that run from a folder, and vendor agents that unpack scripts into temporary paths. Each one either becomes a documented exception with an owner and a reason, or it breaks when the rule is enforced. Legacy software is the hardest case, because older applications often write executables or libraries into user-writable locations by design. Before enforcement, inventory what actually runs on a representative set of workstations, including browser extensions and email client add-ins, and decide for each item whether it is approved, replaced or excepted. Confirm with your application control vendor or platform how it treats user-writable paths and whether it can audit before it blocks, since a monitor-first phase gives you the evidence an assessor will ask for.
For the evidence file, keep three things per control: the configured rule set or policy export showing the approved set and the covered paths, the list of approved exceptions with owners and review dates, and records showing that blocked execution attempts are visible to the team that acts on them. The ML1 requirement does not ask for central logging, but an assessor testing ISM-1657 will want proof the rules are in force on the workstations you name, which is easier to show when the same tooling reports per-device status. Open-source options such as Wazuh's Security Configuration Assessment can check configuration state on monitored endpoints, but confirm with the vendor whether a given check covers your specific application control mechanism before relying on it as evidence.
Which workstations, profiles and file types fall inside ML1 scope
Maturity Level One application control applies to workstations, and the scope question is less about which machines exist than about which ones the organization actually controls. The cards below cover the workstation population, the user profile and temporary folder locations that attackers commonly use, the file types named in ISM-1657, and the scoping decisions that change how much work the rollout takes.
Workstations the organization controls
ISM-0843 requires application control on workstations, so the first scoping step is an inventory of every device a staff member uses to run software. Build the list from the device management and directory records, then reconcile it against network discovery. A workstation missing from the inventory is a workstation without a policy, so reconciliation matters more than the first count. Confirm which operating system builds each device runs, because enforcement features differ between them.
User profiles and temporary folders
ISM-1870 extends the rule to user profiles and the temporary folders used by operating systems, web browsers and email clients. These are the locations where downloaded and attached files land before a user opens them, so they are where unapproved executables most often run. Map the actual paths for each browser and mail client in your build, since default locations vary by product and by profile configuration. Test that a file dropped into each path is blocked from executing.
File types named in ISM-1657
ISM-1657 lists executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets. Each type needs its own rule, because a policy that covers only executables leaves scripts and installers able to run. Compiled HTML and HTML applications are easy to miss in inventories. Ask your security team to confirm which of these types the chosen enforcement tool can restrict in your environment before you write the policy.
Shared and kiosk workstations
A workstation used by several people on rotating shifts changes who the approved set must serve. The policy must reflect every role that logs in, and a single rule set may not fit all of them. Decide whether shared machines receive the same policy as personal ones or a stricter variant. Record the decision, because an assessor will ask how the policy applies to a device that no single owner controls.
Unmanaged BYOD devices
Personal devices that access organizational email or files sit outside the management tooling that enforces application control. If the organization allows them, the in-scope population is larger than the managed fleet and the policy cannot be applied by the usual route. Decide whether to restrict access to managed devices, limit what BYOD can reach, or bring the device under management. Each option changes the work, and the choice should be written down before rollout.
Developer machines
Developers compile, install and run unapproved tools as part of their job, so a strict policy on their workstations can block legitimate work and generate exceptions. Treat developer machines as a distinct scope decision rather than a footnote. Options include a separate approved set, a controlled build path, or a documented exception process with review. Whichever route you choose, confirm with the assessor how exceptions are recorded and how long they remain open.
How an assessor tests application control at ML1
This table sets out how an assessor is likely to test each of the three ML1 application control controls, what evidence they will ask for, and where workstation deployments usually fall short. Read each row as a test plan the organization should rehearse before the assessor arrives. Across all three controls, the main takeaway is that an assessor will check the policy, the coverage and the observed blocking behavior, not just the existence of a tool.
| Control | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| ISM-0843 (implemented on workstations) | Sample a set of workstations across departments and confirm the application control agent or policy is active on each one. | Deployment reports showing enrolled workstations, policy assignment records and agent status for the sampled devices. | Workstations outside the management console, stale agents or devices that were never enrolled. |
| ISM-1870 (user profiles and temporary folders) | Review whether rules cover user profile paths and temporary folders used by the operating system, browsers and email clients, then test a sample of those paths. | Rule set exported from the control, documented path scope and test results showing execution from user-writable locations is handled as configured. | Rules that cover the program files folders only, leaving user profile and temp paths open to unapproved executables. |
| ISM-1657 (executables, libraries, scripts, installers and similar file types) | Compare the approved set against the file types listed in the control, then attempt to run a test file of each type that is not on the approved list. | Approved set with owners and approval dates, and blocked-execution test records for each file type in scope. | Scripts, installers or compiled HTML files that run freely because only executables were configured. |
| Policy review | Read the rule set with the approved software register and confirm each allowed entry traces to an approval decision. | Approved software register, change records for rule updates and the reviewer sign-off for the current rule set. | Broad allow rules such as trusting an entire folder, or rules that no one can link to an approval. |
| Sampling of workstations | Select a representative sample across user groups, operating system builds and locations rather than a single reference machine. | Asset inventory extract and the sampling basis the organization proposes, agreed in advance with the assessor. | Inventories that omit remote or unmanaged endpoints, so the sample does not reflect the real estate. |
| Blocked-execution testing | Run approved and unapproved test files on sampled workstations and record whether the control allows or blocks each one. | Dated test scripts, screenshots or logs of block events and a list of the files used in each test. | Test results collected once and never repeated after rule changes, or tests run by the administrator with exceptions silently applied. |
| Event logging of blocks | Check whether blocked and allowed events reach a central location and whether someone reviews them. | Sample of block events with the review trail showing who looked at them and what action followed. | Block events kept only on the endpoint, or no evidence that anyone reviews the events. |
| Exceptions and temporary allowances | Trace each exception to its request, approver, expiry date and removal record. | Exception register with approvals and closure records. | Exceptions that never expire or were granted verbally with no written record. |
Sequence for implementing ML1 application control
This sequence takes a workstation fleet from unknown software to an approved execution set that is enforced, with exceptions documented and user profile and temporary folder coverage confirmed. Each step produces an artifact that the next step depends on, so the organization can show an assessor how ML1 application control was built and proven.
Inventory workstations and operating system profiles
The organization's IT team lists every workstation model, operating system build and user profile type in scope, including standard, privileged and shared accounts. Confirm which endpoints are managed and which are not, because ML1 applies to workstations and unmanaged devices cannot be assessed the same way. The output is a workstation register with owner, build and management status for each device. The step is done when the register reconciles with the endpoint management console and nothing in scope is missing.
Identify file types and execution locations
Working with the same team, catalog the file types that can execute on those workstations: executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets. Record the locations where these files run, including user profile folders and temporary folders used by the operating system, web browsers and email clients. The output is a file type and location matrix that shows where execution rules must reach. The step is complete when each row can be traced to a workstation group from the register.
Build the organization-approved software set
Business owners and the IT team agree which applications, libraries, scripts and installers are needed for each workstation group, and who approves additions. Collect publisher, signer, hash or path information for each approved item, using the software inventory and deployment records as the starting point. The output is a signed-off approved set with an owner and approval date for each entry. The step is complete when the approver list is documented and the set covers the workstation groups from the register.
Deploy rules in audit mode
The rules are applied to a pilot group in a mode that logs what would be blocked without stopping execution. The IT team reviews the events to find legitimate software missing from the approved set and unexpected execution from user profiles or temporary folders. Confirm the logs are retained and reviewable before moving on. The output is a list of audit findings with a decision for each: approve, remove or investigate. The step is complete when the audit results are triaged and the approved set is updated to match.
Move rules to enforce mode
After the approved set is corrected, the rules are switched to enforcement across the workstation groups in scope, in stages that let the team reverse a change quickly. The IT team watches blocked-event reports during the first working cycles and confirms that business-critical software still runs. Keep the rollback procedure written down and tested. The output is an enforcement configuration record showing which groups are enforced and when. The step is complete when every in-scope group runs in enforce mode and blocked events are being reviewed.
Handle exceptions through a documented process
Requests to run software outside the approved set go to a named owner who assesses business need, security risk and compensating controls before any rule changes. Each approved exception has an expiry or review trigger and is recorded with the requester, approver and reason. Unapproved exceptions are reported to security staff rather than silently allowed. The output is an exception register that an assessor can sample. The step is complete when the register matches the rules actually deployed and no undocumented exceptions remain.
Validate user profile and temporary folder coverage
Test that the rules apply to user profile and temporary folder locations for the operating system, browsers and email clients, using test binaries from those paths in a non-production group. Compare the results with the file type and location matrix from the earlier step. The output is a coverage test record showing the path, file type, expected result and actual result. The step is complete when every location in the matrix has a passing test and any gaps are either closed or logged as open risks.
Retain evidence for assessment
Collect the workstation register, approved set, audit and enforcement records, exception register and coverage tests into one evidence folder with version dates and owners. Confirm that the evidence reflects the current state of the rules, since an assessor will test whether the controls operate rather than whether they were once configured. The output is an assessment-ready evidence package maintained by the control owner. The step is complete when a reviewer outside the implementation team can trace each claim to a record.
How the approved set and temporary folder rules fit together
The approved set only works if the rules that define it cover the places unapproved code actually runs. An allow rule can be written against a publisher, a file hash or a path. Publisher rules tie trust to a signed vendor identity and survive routine version updates. Hash rules pin one exact file and need changing with every release. Path rules are the weakest on their own, because anything that can be written into an allowed folder inherits the permission. That is why path rules must be read together with where users and applications can write files. Confirm with your application control platform how it evaluates a publisher rule against an unsigned file, and whether a path rule permits execution from a folder that a standard user can also write to.
Unapproved code usually lands in user profiles and temporary folders because operating systems, web browsers and email clients all write downloads, caches and extracted attachments there without administrator rights. ISM-1870 asks that application control be applied to these locations, so a rule set that only covers Program Files and Windows leaves the most common entry point open. For an illustrative workstation, a user opens an attachment that is extracted to a temporary folder, runs an unsigned executable from there, and no approved publisher or hash matches. The control should block that execution by default. Ask your team to list every user-writable path the endpoint uses, then test that a freshly downloaded unsigned file cannot run from each one.
The approved set is not a one-time list. Each software update changes publisher certificates, file hashes or both, so the set must be reviewed on a schedule and whenever a new application is requested. Assign an owner for approvals, record each change with a reason, and check that blocked events from the endpoint logs are reviewed rather than silently overridden. Where a business owner asks for an exception, decide whether it is a time-limited rule or a permanent one before the change is made. The outcome to plan for is a documented change process that an assessor can follow from a request, through approval, to the rule that was deployed.
Evidence that passes an ML1 application control assessment
An assessor testing ML1 application control wants to see that an approved set exists, that it is enforced on workstations and user profiles, and that someone reviews what was blocked and why. The cards below cover the five artifacts that connect those points, plus a sixth on keeping them current between assessments.
Approved set register
This is the list of executables, libraries, scripts, installers, compiled HTML, HTML applications and control panel applets the organization has approved to run, with an owner and a justification for each entry. Assessors check that the register covers the file types named in ISM-1657 and that workstation user profiles and temporary folders used by browsers, email clients and the operating system are in scope under ISM-1870. Confirm that every entry traces to a named business need, not to whatever was installed at the time of the first rollout.
Enforcement configuration exports
These are dated exports of the application control policy as it is deployed on workstations, showing the rule types, the scope of user profiles and temporary folders, and the assignment to device groups. Assessors compare the export against the approved set register and look for gaps, such as a rule that allows an entire user profile directory. Keep exports from the management console or policy store, not screenshots, so the configuration can be reproduced and compared between dates.
Blocked-execution logs from sampled workstations
Assessors usually pick a sample of workstations and ask for logs of blocked execution attempts over a stated period. The logs show that enforcement is active in practice, and they reveal which software users tried to run without approval. Check that logs come from the endpoints themselves, include the device, user, file path and time, and are retained long enough for the assessor's sample window. Osquery can surface processes and file hashes across a fleet, which helps match a blocked event to a specific binary.
Exception approval records
Every allowance outside the approved set needs a written exception with an owner, a business reason, a compensating measure and an expiry date. Assessors look for exceptions that never expire, approvals signed by the requester, and exceptions that appear in the enforcement export but not in any register. Keep the approval record linked to the specific file hash or path it covers, so a reviewer can confirm the exception still applies after an update.
Recurring review records
These are dated records showing that someone reviewed the approved set, the exceptions and the blocked-execution trends on a set schedule. The record should state who reviewed, what changed, and what was removed or added as a result. Assessors treat a register that has not changed in a long period as a warning sign, because software on workstations changes constantly. Fleet policies can run yes or no checks across devices, such as whether an unapproved binary is present, and the pass or fail results make a useful input to the review.
Keeping evidence current between assessments
Evidence goes stale quickly unless its collection is scheduled. Assign an owner to each artifact, export the enforcement configuration and register on a fixed cadence, and store dated copies in a location that cannot be silently edited. Ask the implementation partner to document the collection procedure so the organization can repeat it without them. Set the cadence in the organization's own control documentation, since no external source sets it for ML1.
What meeting ML1 application control costs in money and effort
Tooling is the one cost category where open-source choices can remove licence spend. The application control enforcement itself is typically provided by the operating system or endpoint management platform the organization already runs, so the marginal cost depends on whether those capabilities are already licensed. Monitoring and query tooling, such as osquery-based inventory, is available under open-source licences, though the hosting, storage and staff time to run it still cost money.
- Enforcement platform: Confirm whether the workstation enforcement capability is already included in your operating system or endpoint management licences.
- Open-source monitoring: Self-hosted tools such as Wazuh, Fleet and osquery carry no licence fee under their published licences, but they still require compute, storage and administration.
- Hosting: Ask whether the quote includes servers, backup of the management console and network access for endpoints.
- Renewals: Identify any licences that renew annually and whether they scale with device count.
- Quote request: Ask the implementation partner to list each tool, whether it is open source or commercial, and which party holds the licence.
Check whether the quote separates third-party licences from implementation labor so that you can compare the open-source and commercial options on the same basis.
Building the approved set is usually the largest one-time cost. Engineers inventory the executables, libraries, scripts, installers and similar files used on workstations, decide which ones are approved, write rules for user profiles and temporary folders, and test that business applications still run. Most of this effort is front-loaded, but it recurs whenever software changes.
- Discovery: Inventory of executables, libraries, scripts and installers across workstation profiles, which is usually one-time but grows with the number of applications.
- Rule design: Writing and testing allow and deny rules for user profiles and the temporary folders used by operating systems, browsers and email clients.
- Pilot testing: Running the rules against a representative group of devices before wider rollout.
- Exception handling: Reviewing and approving requests to run software that is not on the set. Exception volume is a major recurring driver.
- Quote request: Ask for the number of applications in scope, the device groups covered and the number of rounds of testing included.
Ask whether the quote is fixed for an agreed approved set or whether additional applications are billed separately.
Evidence upkeep is the recurring work of showing that the approved set is still enforced. An assessor needs to see the rules, the devices they apply to, and records of blocked and allowed events, along with proof that changes were reviewed. Keeping this current takes staff time every cycle, and the volume grows with fleet size.
- Rule records: Version-controlled rules with dated approvals for each change.
- Coverage reports: Recurring reports showing which devices are enforcing the approved set and which are not.
- Event records: Retained logs of blocked and allowed executions, stored long enough to meet your assessment cycle.
- Change reviews: Periodic review of the approved set with named owners.
- Quote request: Ask which evidence artifacts the partner will produce, in what format, and how often they will be refreshed.
Check whether evidence collection is included in the fixed scope or sits in a recurring retainer.
External testing and review checks whether the application control works as intended. This can be a security test of whether a user can run an unapproved file, or an independent review of the rules and evidence before an assessment. These services are optional for ML1 but commonly sought before an assessment, and their scope determines their price.
- Bypass testing: Testing whether common routes, such as user-writable folders or script hosts, allow unapproved execution.
- Rule review: A second reviewer checks that rules match the approved set and do not contain unnecessary exceptions.
- Re-testing: Repeat tests after significant software or policy changes.
- Independence: A review by the same team that built the rules is not independent, so confirm who performs the work.
- Quote request: Ask for the test objectives, the number of devices or profiles sampled and what report you receive.
DeployOpen runs security testing as a separate service, so you can scope it independently of the implementation.
Auditor sampling is the cost of the assessor's own work, which is set by the assessor and not by an implementation partner. An assessor selects a sample of devices and events to test, and the size of that sample affects how much evidence you must produce. Only an independent assessor or certification body issues assessment conclusions.
- Sample size: Assessors select devices and time periods to test, so a larger fleet does not always mean a proportionally larger sample.
- Preparation time: Staff time to answer requests, retrieve records and walk the assessor through the rules.
- Rework: Costs that arise when evidence is missing or inconsistent and must be regenerated.
- Scope agreement: Agreeing the boundary of the workstation fleet before fieldwork starts.
- Quote request: Ask the assessor how they select samples and what evidence they will request, in writing, before the engagement starts.
Confirm the assessor's fee structure directly with them, since it is not set by the implementation partner.
Which open-source tools produce ML1 application control evidence
This table compares four open-source tools by the endpoint evidence they can help produce for ML1 application control, such as process, file hash and configuration checks. Read it as a guide to evidence, not enforcement: none of these tools is listed here as the mechanism that blocks unapproved executables.
| Tool | Evidence it can help produce | Licence | What to confirm |
|---|---|---|---|
| Wazuh Security Configuration Assessment | Checks files, directories, registry keys and running processes against YAML policies, mostly based on CIS benchmarks, with remediation advice | GPL-2.0-only | Whether a custom policy can check for an approved-application list on your workstation images |
| Fleet policies | Yes or no osquery-based questions per device, such as whether a required control is present, shown as passing or failing across each fleet | MIT | Which policy queries you will write to reflect your approved-set rules and how failing devices are tracked |
| osquery | Scheduled SQL queries over running processes, file hashes, loaded modules and browser plugins across many hosts | Apache-2.0 OR GPL-2.0-only | That your approved-set inventory and hash baseline are maintained and that query results are retained |
| Velociraptor | Forensic artifacts collected through VQL from endpoints, with hunts across groups of systems and notebooks for combined results | AGPL-3.0-only | Whether hunts can confirm execution of unapproved files on user profiles and temporary folders for your evidence period |
| Enforcement (not covered above) | Blocking unapproved executables, scripts and installers is performed by an application control tool, not by these monitoring tools | Depends on the chosen tool | Confirm the enforcement product's ML1 rule coverage and its own event logs before relying on these tools as proof |
Who owns, implements and independently tests ML1 application control
Your organization owns application control at ML1. That means deciding what is approved to run on workstations, who may request an exception, who approves it, and who answers for the outcome. No implementation partner can make those decisions on your behalf, and an assessor will ask to see that the decisions were made by accountable people in your organization. The work is continuous, so it needs named owners rather than a project team that disbands after go-live.
- Approved set ownership: a named business owner and a technical owner agree the list of approved executables, libraries, scripts, installers and similar file types, and keep it current.
- Exception process: a written request, justification, approver and expiry date for every exception to the approved set.
- User profile and temporary folder scope: your team confirms which user profiles and temporary folders used by operating systems, browsers and email clients fall within the control.
- Operational monitoring: someone reviews blocked execution events and acts on them, rather than treating them as noise.
- Policy records: the approved set, exception log and review minutes are retained as evidence.
Check that each of these items has a named person, a review cadence and a record your staff can produce on request.
An implementation partner prepares the systems, configuration and evidence that your team and assessor rely on. DeployOpen is one such partner for self-hosted open-source tooling inside your own infrastructure. A partner builds the controls and the evidence trail, but it does not decide what your organization approves, and it does not certify that the controls work. Its deliverables should be written into a fixed scope before work begins.
- Configuration and deployment: preparing application control policy for workstations within the agreed scope, and documenting how it was built.
- Discovery support: helping your team inventory executables, scripts and installers so the approved set can be reviewed.
- Monitoring tooling: setting up open-source tools such as osquery, Fleet or Wazuh to check that endpoints match the expected state, where those tools fit your environment.
- Evidence packs: assembling configuration exports, query results, change records and runbooks that show how the control operates.
- Handover: training your staff so the control can be run without the partner.
Ask any partner to state in writing which deliverables it produces and which decisions remain with you.
The independent assessor tests whether application control is implemented and effective, then reports on it. Only an independent auditor, assessor or certification body can issue that report. The Essential Eight is a set of mitigations rather than a certification scheme, so the question is how your organization evidences maturity against ASD's maturity model, and the assessor's view is what your stakeholders will trust. Independence matters because the assessor must not have designed or operated the controls it tests.
- Sampling and testing: the assessor selects workstations and profiles and checks whether unapproved execution is blocked.
- Evidence review: the assessor reads the approved set, exception log and monitoring records, and asks whether they match the running configuration.
- Reporting: the assessor writes its own findings and conclusions. Neither your team nor a partner writes or edits them.
- Line of independence: a partner that prepared the evidence can explain it, but it should not grade it.
- Scope agreement: the assessor confirms the scope and the criteria it will test against before fieldwork.
Confirm with any assessor how it treats work performed by a partner, and whether it will rely on that work or retest it.
Where ML1 application control usually falls short
Application control at ML1 looks simple on paper, but most gaps appear in the details: which locations are covered, who maintains the approved set, and whether exceptions and evidence stay current. The cards below cover the failure points assessors most often find and what to check before an assessment.
Temporary folders left open
Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients, which are the paths malware most often uses to drop and run files. Gaps appear when rules cover Program Files but leave %TEMP%, browser cache folders or mail attachment folders writable and executable. Check each rule against a list of these paths for every workstation build, and test by attempting to run an unsigned test binary from each location.
Unmanaged user profiles
The control covers user profiles, not only the machine. Where local administrators can create or change profiles, or where profile folders sit outside the managed policy scope, execution can escape the approved set. Confirm which profile types exist on each workstation image, whether standard users can write to their own profile paths, and whether the policy applies to every account, including those created after deployment.
Stale approved sets
An approved set is only as good as its last review. Software updates, new libraries and replaced installers can fall outside the rules, leading either to blocked business applications that users work around or to older files that remain trusted after a vendor release. Assign an owner to the approved set, record a review date, and compare the policy against the installed software inventory at each review rather than waiting for a failed assessment.
Exceptions without expiry
Temporary allowances for a single application or user often become permanent. An exception that lacks an owner, a business reason and an end date is an unreviewed hole in the policy. Require each exception to name the file hash or publisher, the approver and an expiry date, then have a recurring task that removes expired entries and reports which ones were renewed.
Evidence gathered only at audit time
Assessors look for proof that the control operated over time, not a screenshot taken the week before the review. Teams that check policy state only when an assessment begins cannot show how often blocked events occurred or whether devices drifted. Schedule a recurring query of policy status across the fleet, keep the results with dates, and store the blocked-event history so the assessor can sample it.
Unverified device coverage
A policy that exists in the management console does not prove that every workstation enforces it. Devices offline during a rollout, reimaged machines and unmanaged laptops can run without the rule. Compare the list of enrolled endpoints against the asset inventory, then run a yes or no check on each device that confirms the policy is active and the temporary folder rules are in force.
Questions buyers ask about ML1 application control
How long does Maturity Level One application control take to implement?
The duration depends on how many workstation builds, user profiles and business applications the organization runs, and on how much of the allow list is already known. Teams with a standard desktop image and a short list of approved software usually finish faster than teams that must first discover what runs across a mixed estate. Application control is also usually rolled out in audit mode before enforcement, so time is spent watching what would be blocked and correcting rules before users are affected. Ask any provider for a written timeline tied to a defined scope, the number of endpoints, and the phases for discovery, rule building, testing and enforcement. No duration is fixed by ASD for this work.
What does ML1 application control ask of internal staff?
Internal staff own the decisions that a rule set cannot make for them. Application owners must confirm which executables, libraries, scripts and installers the business needs, and who approves a new one. Desktop support must test the rules against standard builds and handle exceptions without granting broad bypasses. Security staff must review blocked events, decide what counts as an approved change, and keep the evidence that the restriction is applied to user profiles and temporary folders used by operating systems, browsers and email clients. Staff also need a repeatable request process so that a new tool does not quietly become an exception that nobody reviews.
Can we implement ML1 application control in-house?
Yes, many organizations do, provided they have people who understand their endpoint management platform, their software inventory and their approval workflow. The work is mostly configuration and process rather than specialist engineering, but it does require time from several teams and a clear owner for the approved set. Outside help is usually considered when internal teams lack endpoint management skills, when the estate is large or mixed, or when they want an independent review of the rules before enforcement. Under any model, the organization owns its controls. An implementation partner can prepare systems and evidence, but only an independent assessor issues assessment conclusions.
What drives the cost of ML1 application control?
Cost is driven by the number and variety of endpoints, the number of applications that must be classified before enforcement, the maturity of existing endpoint management tooling, and how many approval cycles the business runs. One-time costs include discovery, rule design, testing against standard builds, and the first round of exception handling. Recurring costs include reviewing new software requests, reviewing blocked events, and maintaining the approved set as software changes. When requesting a quote, ask the provider to itemize discovery, rule design, testing, rollout support, documentation of evidence, and any ongoing review, and to state which items the organization must staff itself. DeployOpen does not publish a price list; a quote follows from a written scope.
How does ML1 application control differ from ML2 and ML3?
ML1 applies application control to workstations and to user profiles and temporary folders, restricting the common file types to an approved set. ML2 extends the control to internet-facing servers and across all file system locations, adds Microsoft's recommended blocklist, requires annual validation of the ruleset, and calls for central logging of allowed and blocked events. ML3 extends the control to non-internet-facing servers, restricts driver execution to an approved set, and adds Microsoft's vulnerable driver blocklist. Each level builds on the previous one, so ML1 rules are the starting point rather than a separate project. Confirm the exact requirements against the ASD maturity model and the ISM Essential Eight profiles before planning.
Is there an ASD certificate for ML1 application control?
No. The Essential Eight is a set of mitigation strategies, not a certification scheme, and ASD does not issue a certificate for any maturity level. Maturity is shown through assessment of how each strategy is implemented and whether it is effective against the maturity model. The organization owns the controls and the resulting evidence. An independent assessor reviews that evidence and reports its conclusions, and an implementation partner can prepare the configuration, records and documentation the assessor will request. Be cautious of any offer that describes an ASD certificate, and ask which independent assessor or body will review the work.
Official sources for the ML1 application control requirements
Start with two primary references: the ASD maturity model that defines what each Essential Eight maturity level means, and the machine-readable ISM catalog that tags which controls sit at ML1. For application control at ML1, the ISM catalog tags three controls: ISM-0843, which requires application control on workstations; ISM-1870, which extends it to user profiles and temporary folders used by operating systems, web browsers and email clients; and ISM-1657, which restricts executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organization-approved set. The Essential Eight maturity model on cyber.gov.au explains the intent behind these requirements in plain language, and the November 2023 PDF release is the version to cite in a governance pack.
The machine-readable source is the ISM OSCAL catalog, published by ASD through its mirror, which holds the Essential Eight ML1, ML2 and ML3 baseline profiles. Use the catalog to pull exact control identifiers into your GRC tool, so the ML1 scope in your register matches the published profile rather than a retyped list. Confirm the release you map against, since the ISM is updated and the version used in your assessment must match the one your evidence was collected against.
Before you rely on any wording, confirm it against the current ISM release in your own environment, and record the release version in your assessment file. An assessor will ask which version you tested against, and a mismatch between the catalog text and your control narrative is an easy finding to avoid. Ask your auditor or ASD-aligned assessor which release they expect, and keep a dated copy of the catalog alongside your evidence.
How DeployOpen scopes and prepares ML1 application control evidence
The sequence moves from a written scope to a tested allowlist, self-hosted monitoring and an evidence pack that an independent assessor can review. DeployOpen prepares the systems and evidence, while the organization owns its controls and the assessor issues any conclusion.
Agree scope and deliverables in writing
DeployOpen and the organization agree in writing which workstation populations, user profiles, temporary folders and file types fall under ML1 application control (ISM-0843, ISM-1870 and ISM-1657). The scope also names who owns each control, which systems are excluded and what the deliverables are. The step is done when the signed scope document lists the in-scope endpoints and the named owner for each control.
Confirm the ML1 control baseline
The team maps the agreed scope to the ML1 Essential Eight profile in ASD's ISM OSCAL catalog so every in-scope requirement has a named owner and a planned evidence source. The organization confirms which controls it already meets and which need work. The output is a baseline register that the organization approves before implementation begins.
Inventory workstations and execution paths
Engineers identify the operating system versions, user profiles, temporary folders and browser or email client locations that launch code on the in-scope workstations. They also record where legitimate software is installed, including the paths used by updaters and installers. The inventory is complete when the organization has reviewed it and confirmed that no in-scope execution path is missing.
Build and test the approved set
DeployOpen works with the organization's application owners to draft the approved set of executables, libraries, scripts, installers, compiled HTML, HTML applications and control panel applets. The draft is tested in a monitored audit mode on a pilot group before enforcement. The step closes when the organization signs off the approved set and each rule has an owner and a reason.
Deploy and harden self-hosted monitoring
Engineers deploy self-hosted tools inside the client's environment. Options include Wazuh Security Configuration Assessment policies, Fleet policies backed by osquery queries and Velociraptor hunts for targeted collection. Each tool is configured with access controls and logging suited to the organization's own risk settings. The step is done when the tools report on the pilot group and their configuration is documented and reviewed.
Enforce and verify control operation
The approved set moves from audit mode to enforcement in stages, with exceptions tracked through a documented change process. Engineers run policy checks and fleet queries to show which endpoints pass or fail each control. The step closes when test results show the control operating as designed and each exception has an approver and an expiry decision.
Assemble the evidence pack
DeployOpen compiles configuration exports, the approved set and its change records, policy results, exception logs and screenshots or query outputs into an evidence pack organized by ISM control ID. The organization reviews the pack for accuracy and completeness. The output is a versioned evidence set that the organization owns and can hand to any assessor.
Hand over to the independent assessor
The organization gives the evidence pack and the signed scope to its chosen independent assessor or certification body. DeployOpen answers technical questions about how the systems were built but does not issue audit reports, attestations or certificates. The step is complete when the assessor confirms receipt and the organization records any findings for remediation.
