In a perfect world, your staff could work on their computers with complete freedom, using whatever programs they wanted. We don’t live in that world. To keep your organisation safe, you need to have full visibility into what applications get used – and block anything that isn’t explicitly approved.
Application control is also a core part of Essential Eight Maturity Level 1, the federal cyber security standard recommended for SMBs. If you’re working with your IT provider to reach ML1, use this guide to understand what you need to do to become compliant.
This article is part of a series on implementing the Essential Eight to Maturity Level 1. Read other articles in the series here.
What Is Application Control?
The applications in your IT environment aren’t autonomous, free-roaming entities. The information they can see and the actions they can take are limited by permissions – which you, the human user, grant to them.
Traditionally, any program that could autonomously roam your system with full permissions would be classed as malware. Today, that definition has been extended to AI agents like OpenClaw – which are themselves major threat vectors.
Think about app permissions a bit like physical keys in your office. You might give all tenured staff keys to the front door, but only share keys to secure spaces like your server room, your accounts room, and your personal office with people who need that access. It’s not that you don’t trust your team … but, the more keys floating around, the more likely it is that one could get lost or stolen.
The same holds true for applications. If your IT team has approved an application, it probably isn’t malicious in nature. If it gets compromised, though, unrestricted permissions mean it could spread malware throughout your system.
Let’s extend the analogy to strangers coming into your office. Would you feel comfortable with your staff inviting random friends, associates, and people off the street into your workplace? Probably not. It’s unnecessary and a security risk – you have no idea who those people are.
That’s why application control also restricts what apps can and can’t be installed by your staff. If your team needs access to a program, it should be vetted by your IT partner to make sure it:
- isn’t compromised or likely to be compromised
- only requires necessary levels of access to run
- doesn’t simply duplicate the functionality of an existing approved program that your team already uses.
The best approach to controlling applications is allowlisting. Unlike blocklisting, which blocks specified apps from running, allowlisting only allows specified apps. That means, if an app isn’t on your environment’s allow list, it won’t be permitted to run.
Restricting App Permissions
Essential Eight Controls:
- Application control is implemented on workstations.
- Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients.
- Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications, and control panel applets to an organisation-approved set.
Implementing the Essential Eight controls is, in some ways, straightforward. In fact, all you need is an application control tool like Threatlocker or Windows Defender Application Control. (Simply having either set up on your team’s workstations means you’ve met the first control.)
With that said: properly configuring your control policies is technically complicated. Your control software needs to:
- accurately recognise your applications (which are collections of files, not single files)
- permit software updates and necessary processes to run without restriction
- limit the ability of applications to write to and execute from all locations on your system.
To do that, your IT partner will need to set up your control software with a combination of hash-based, certificate-based, and path-based rules.
Hash-based rules use cryptographic hashes – a kind of unique fingerprint – to identify files. If a file is changed, the hash changes too. That means hash-based rules are extremely effective, but only suitable for files that don’t get updated often.
Publisher-based rules involve using digital signatures from app publishers to certify files. If the file is changed after signing, the signature disappears. Because publisher-based rules apply to all files signed with a specific signature, they’re easier to maintain than hash-based rules.
Path-based rules work based on a file’s location within your computer or network. For example, all files located at a specific path could be blocked from writing and executing. Because path-based rules are not file-specific, they’re less secure than using hashes or publisher certificates. They should, though, be used as a fallback option.
To comply with the second Essential Eight control we mentioned – applying app control to user profiles and temporary folders – you’ll need to block the following paths:
- C:\Windows\Temp\*.* (the folder that contains temporary system files)
- %USERPROFILE%\AppData\Local\*.* (the folder containing user-specific app data that stays on the current endpoint)
- %USERPROFILE%\AppData\Roaming\*.* (the folder containing app information that ‘roams’ with your user profile across endpoints).
Finally, the third Essential Eight control can be met by running control software like ThreatLocker in ‘learning mode’ for around 30 days. The software will log every executable, app, and installer than runs on your endpoints, which produces a baseline list that your IT provider will then need to evaluate and refine.
If, for example, ThreatLocker detected different apps that performed the same function, it might make more sense to pick one that meets your requirements and get rid of the others. You also don’t want any malware or unsecure processes being allowed simply because they were running during learning mode.
Once a list of trusted applications has been compiled, the rules we talked about before – hash-, publisher- and path-based – can be implemented to ringfence them. Your IT provider will need to continuously monitor your allowlist to make sure it stays up to date with your organisation’s requirements.
Handling User App Requests
In theory, application control is straightforward. Your IT partner can deploy control software, automatically compile your allowlist, then block everything else.
Reality, though, is more complicated. If your staff are like most people, they won’t appreciate the transition from a loosely controlled environment where any and all apps are permissible to one that’s compliant with the Essential Eight. That can lead to friction and complaints about unnecessary red tape.
To make changeover as smooth as possible, explain to your staff why application control is being implemented (or have your IT provider hold a presentation instead). Make sure you also walk them through how they can request allow-listing for apps that aren’t automatically added to the allow list – a formal submission to IT, for example, with a rationale signed off by the staff member’s manager.
Good security is, ultimately, about balancing controls with operational flexibility. If your restrictions are too aggressive, you’ll hamstring your staff and create a shadow IT risk – which will undermine all the work you’re doing to reach Essential Eight ML1.
Need help reaching Essential Eight Maturity Level 1? We help Australian SMBs strengthen their security postures – without affecting business productivity.
More Essential Eight Implementation Guides
Read other articles in our series on reaching Essential Eight Maturity Level 1.

