Application control is the first of the Essential Eight and the one organisations are most likely to be rated at maturity level zero on, despite having bought a product for it. The reason is almost never the technology. It is that enforcement never happened.
A deployment running in audit mode is reporting what would have been blocked. It is not blocking anything, which means it is not mitigating anything.
What Application Control Covers
Application control restricts execution to an approved set. The scope is wider than most teams assume when they start: it covers executables, software libraries, scripts and installers, not just the applications a user would recognise by name.
That breadth is what makes it effective. An adversary who cannot run an executable will try a script; an approach that allowlists applications but ignores scripting engines leaves the path open. It is also what makes it difficult, because the legitimate script and library surface of a real fleet is larger and stranger than anyone expects before they measure it.
The control applies across workstations and, at higher maturity, extends to servers and to the places where executable content can be dropped and run.
Why Deployments Stall in Audit Mode
The pattern is consistent. A team deploys in audit mode to learn what the fleet runs, the log fills with thousands of events, and nobody can tell which represent legitimate work and which are noise. Enforcement is deferred until the list is understood. The list is never fully understood, so enforcement never arrives.
Three things cause this.
The learning period has no end date, so it never ends. Without a scheduled cutover, audit mode is indefinitely comfortable — it produces activity and reports without risk.
The ruleset is built from events rather than from intent. A list derived purely from what ran last month encodes whatever was running, including things that should not have been.
And there is no exception path, so the first user who cannot do their job becomes an escalation that rolls the whole deployment back. Without a fast, owned route to add a legitimate application, enforcement feels like a risk to operations rather than a reduction in risk.
Stuck in audit mode?
Share your work email and we'll walk your current ruleset and exception process and map what reaching enforcement would actually take.
Building a Ruleset That Survives Real Users
Build the ruleset from intent first, then reconcile against what real users were observed running.
Start by listing what the fleet is supposed to run — the standard operating environment, the line-of-business applications, the development toolchains. That list is short, known, and owned by someone. Allow it.
Then compare it against what audit mode observed. The difference is the interesting part, and it falls into three buckets: legitimate things nobody thought to list, obsolete things that should be removed rather than allowed, and things that should never have been running at all. Each bucket has a different action, and collapsing them into one allowlist is how deployments encode their own problems.
Segment the fleet where it genuinely differs. Developers, finance and a call centre do not run the same software, and a single ruleset wide enough for all three is wide enough to be worth little.
Allowlisting by Publisher, Path or Hash
The rule type you choose decides how much maintenance you sign up for and how much security you get.
- Publisher rules trust software signed by a given vendor. Lowest maintenance, because updates keep working. Weakest precision, because they trust everything that vendor signs.
- Path rules trust what lives in a directory. Moderate maintenance. Only as strong as the permissions on that path — a writable allowed directory is not a control.
- Hash rules trust an exact binary. Strongest precision, highest maintenance, because every update breaks them.
Most workable rulesets are publisher-led for mainstream vendor software, path-based for tightly controlled directories users cannot write to, and hash-based only for the small set where precision justifies the overhead. The anti-pattern is a path rule over a user-writable location, which quietly converts the control into a formality.
The Enforcement Cutover
Set the enforcement cutover date before you start learning, and treat it as a commitment.
- Scope a pilot group that includes at least one awkward team, not only the cooperative one. A pilot of the security team proves nothing.
- Run audit mode for a defined period, long enough to cover a month-end and whatever periodic work exists.
- Publish the exception route before enforcement, with a named owner and a turnaround measured in hours.
- Enforce for the pilot, and keep the exception path visibly fast for the first fortnight.
- Expand in waves, by segment, with each wave's audit data reviewed before its own cutover.
- Close audit mode out. Any group still in audit mode after its wave is unfinished work, and should appear on a report as such.
The single most useful decision is making enforcement the default state of the project and audit mode the temporary one. Teams that frame it the other way round rarely finish.
Evidence an Assessor Will Ask For
The evidence an assessor will ask for follows from what would be contested. Configuration showing enforcement rather than audit, and which groups it applies to. The ruleset itself, with the rule types used. Coverage figures against the asset inventory, so that an unmanaged remainder is visible rather than implied. The exception register, with owners and expiry dates. And change records showing the ruleset is maintained rather than frozen at deployment.
Coverage is where most claims weaken. Enforcement on ninety per cent of a fleet is a real achievement and not the same as enforcement, and an assessment will ask what the other ten per cent is.
Application Control Questions Teams Ask
No. Antivirus and endpoint detection products identify and block things believed to be malicious, which is a default-allow posture with exceptions. Application control is default-deny: only approved executables, libraries, scripts and installers run, and everything else is blocked whether or not it is recognised as bad. They complement each other, and an EDR deployment does not move the application control strategy above maturity level zero.
Yes, but not with the same ruleset as the rest of the fleet. Developer workstations legitimately run compilers, interpreters and freshly built binaries, so a hash-based approach is unworkable and a naive allowlist either blocks real work or is widened until it means nothing. The usual answer is a separate segment with publisher and path rules covering the approved toolchain, tighter controls on where build output can execute from, and an exception route fast enough that it is used rather than circumvented.
Long enough to observe a full business cycle — typically including a month-end and any periodic processing — and no longer. The important discipline is setting the cutover date at the start rather than waiting for the log to feel complete, because it never does. Deployments that leave the end date open are the ones that remain in audit mode indefinitely and stay rated at maturity level zero.
It depends on the rule type you chose. Publisher rules usually survive updates, because the signature remains valid. Path rules survive if the install location is unchanged. Hash rules break on every update by design, which is why they are worth reserving for the small set where that precision is justified. Planning the mix around update frequency is most of the maintenance decision.
Get application control from audit mode to enforced
Book a demo and we'll show how Konfirmity tracks coverage, exceptions and enforcement state across the Essential Eight so the gap between claimed and assessed maturity stays closed.
Book a demo
Finish the Strategy You Already Started
Most organisations reading this have already bought the product and already deployed it. The remaining work is not technical procurement — it is a cutover date, an exception route with an owner, and the willingness to enforce on a segment that will complain.
Application control sets the pace for the rest of the Essential Eight maturity model, because the guidance is to move all eight together and this is the one that lags. Finishing it is usually what unlocks the next level across the set.
