Common Challenges in ACSC Essential Eight for Australian SaaS Companies

Most Australian SaaS companies do not adopt the ACSC Essential Eight because they want to. They adopt it because a government tender, an enterprise customer, or an investor's due diligence checklist asked for it. That is a perfectly good reason - but it means teams often start implementing the Essential Eight before they understand where the model fits their architecture and where it fights against it. I have assessed enough cloud-native environments against this framework to know that the friction is real, and pretending otherwise just wastes budget.

This is an honest look at the challenges Australian SaaS companies actually hit when they take the Essential Eight seriously, and how I work through them without cargo-culting controls that were designed for a different kind of network.

The Essential Eight in One Paragraph

The Essential Eight is the Australian Signals Directorate's baseline of eight mitigation strategies: application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication, and regular backups. Progress is measured against the Essential Eight Maturity Model, which runs from Maturity Level Zero (not implemented) through Maturity Level Three (aligned against more capable, better-resourced adversaries). The important structural point, which trips up almost everyone, is that maturity is assessed as a package - you are only at a given level once every one of the eight strategies meets that level.

Challenge 1: The Model Assumes a Windows Network, and Your Stack Is Not One

The single biggest source of confusion is that the Essential Eight was designed around internet-connected, Microsoft Windows corporate networks. Several strategies - Office macro settings, user application hardening around browsers and PDF viewers, Windows application control - map naturally onto a fleet of managed Windows laptops. They map far less cleanly onto a SaaS company running Linux containers on a cloud provider, developers on macOS, and production that no human logs into interactively.

The mistake is to either force-fit Windows-centric controls onto infrastructure that does not have them, or to wave the whole framework away as irrelevant. Neither is right. The correct approach is to translate intent. "Configure Microsoft Office macro settings" is really about controlling untrusted executable content; on a stack with no Office footprint, you demonstrate the equivalent control over the actual code execution paths you do have. Document that reasoning explicitly, because an assessor will ask, and "we do not use Office so we skipped it" is not an answer that survives scrutiny.

This is precisely the kind of scoping judgement where an experienced IT security audit saves months. Getting the mapping wrong early means re-doing evidence later.

Challenge 2: Application Control on Developer and Cloud Workloads

Application control - allowing only approved executables to run - is the hardest of the eight for almost every SaaS company, and for a specific reason. Developers install tools constantly. Build pipelines pull dependencies dynamically. Cloud workloads are ephemeral, spun up and torn down in minutes. A strict allowlist that would be manageable on a locked-down office desktop becomes a source of constant friction on an engineer's machine.

In practice you have to solve this in two different environments. On corporate endpoints, application control is achievable with modern tooling but demands real change management so that developers are not blocked ten times a day. In production, the honest translation of application control is immutable infrastructure: workloads built from signed, scanned images that cannot be modified at runtime, deployed through a controlled pipeline. That is arguably a stronger control than a Windows allowlist, but you have to be able to articulate why it satisfies the intent, and you have to have the evidence to back it.

If your production runs primarily on cloud infrastructure, working through this with cloud security consulting that understands both the framework and container tooling is far more productive than trying to bolt endpoint controls onto a Kubernetes cluster.

Challenge 3: The Patch Cadence Is Faster Than Most Teams Run

The two patching strategies - applications and operating systems - look trivial until you read the timeframes in the maturity model. At the levels most customers expect, you are looking at patching or mitigating actively exploited vulnerabilities in internet-facing systems within roughly 48 hours, and applying most other patches within about two weeks. Higher maturity also expects regular vulnerability scanning, in some cases daily for internet-facing services.

For a lean SaaS team shipping features, this is a genuine operational shift. It means vulnerability scanning has to be continuous rather than quarterly, patch decisions need a pre-agreed severity-driven SLA rather than a monthly maintenance window, and someone has to own the tail of third-party dependencies that never seem to fully patch. The strategy that most often drags a company's overall maturity down is not the exotic one - it is patching, because the cadence is relentless and easy to let slip.

A recurring vulnerability assessment gives you the visibility this requires, and a penetration test tells you which of the findings an attacker could actually reach - which is what should drive your 48-hour queue.

Challenge 4: You Cannot Cherry-Pick - Maturity Is Assessed as a Package

Teams love to report that they are "mostly at Maturity Level Two". There is no such thing. Because the maturity model is assessed as a whole, your maturity is set by your weakest strategy. Seven strategies at Level Two and one at Level One means you are at Level One, full stop.

This changes how you should plan the work. The instinct is to pour effort into the strategies you are already good at, because progress feels satisfying. The correct move is the opposite - find your weakest strategy and lift it, because that is the only thing that moves your headline number. I spend a lot of assessment time simply making this visible, because it reframes the roadmap from "do more of what we are good at" to "fix the specific things holding us back", which is usually patching, application control, or complete MFA coverage.

Challenge 5: MFA Has Moved On, and Coverage Must Be Complete

Multi-factor authentication sounds like the easy one, and enabling MFA on your identity provider is indeed straightforward. The challenges are scope and strength. On scope, the requirement extends beyond your admin console - it reaches into how users authenticate to internet-facing services, and at higher maturity, how they access important data and systems more broadly. The gaps are almost always the forgotten edges: a legacy service account, an SSH path, a third-party admin panel outside your single sign-on, a break-glass account with a password and nothing else.

On strength, the model has increasingly pushed toward phishing-resistant MFA at higher maturity levels, which rules out some of the SMS and one-time-code methods teams reach for first. So the real work is not turning MFA on - it is inventorying every authentication path in your environment, proving there are no exceptions, and moving the important ones to phishing-resistant methods. Complete coverage is much harder than partial coverage, and the maturity model only rewards complete.

Challenge 6: Evidencing Maturity Is Harder Than Achieving It

The last challenge is the one companies discover last. You can implement all eight strategies well and still fail an assessment because you cannot prove it. The maturity model is evaluated on evidence - configuration exports, patch logs, backup restoration test records, application control rulesets, MFA enrolment reports. If those artefacts are not being generated and retained as a byproduct of normal operations, you end up scrambling to reconstruct them, and reconstructed evidence is weak evidence.

Build evidence collection into the controls from the start. A backup is not compliant because it exists - it is compliant because you have documented, tested restoration on a defined cadence. Application control is not compliant because a policy is deployed - it is compliant because you can show the ruleset and demonstrate that unapproved execution is blocked. This is where an ongoing security function pays for itself; a virtual CISO keeps the evidence current so that an assessment is a formality rather than a fire drill.

The Eight Strategies and How They Land on a SaaS Stack

Strategy	Original intent	SaaS reality
Application control	Allow only approved executables	Hard on dev machines; met in production via immutable, signed images
Patch applications	Fast patching of app vulnerabilities	Relentless cadence; dependency sprawl is the pain point
Configure Office macros	Block untrusted macro code	Often low footprint; translate to controlling untrusted code execution
User application hardening	Harden browsers, block Flash/ads/Java	Applies to corporate endpoints; document browser and extension policy
Restrict admin privileges	Limit and control privileged access	Maps to least-privilege IAM, just-in-time access, no standing admin
Patch operating systems	Fast OS patching	Container base images and hosts; rebuild rather than in-place patch
Multi-factor authentication	MFA on key access	Coverage completeness and phishing resistance are the hard part
Regular backups	Tested, retained backups	Tested restoration and immutability, not just snapshots existing

Understanding the Maturity Levels

Level	Broadly aligned against	What it means for you
Maturity Level Zero	Weaknesses in overall posture	One or more strategies not meaningfully implemented
Maturity Level One	Adversaries using widely available, commodity tradecraft	A sensible baseline most SaaS companies should reach first
Maturity Level Two	More capable adversaries investing time in a target	Common expectation for enterprise and government-adjacent buyers
Maturity Level Three	Adaptive adversaries willing to invest significant effort	Demanding; usually driven by specific contractual requirements

Pick your target level based on who is actually asking and why. Chasing Maturity Level Three because it sounds impressive, when your customers only need Level Two, burns budget you could spend elsewhere.

Frequently Asked Questions

Is the Essential Eight mandatory for Australian SaaS companies?

The Essential Eight is mandatory for non-corporate Commonwealth entities. For private SaaS companies it is not legally required, but it is very commonly requested in government tenders, enterprise procurement, and investor due diligence, which is why most companies end up implementing it regardless.

Which of the eight strategies is hardest for a SaaS company?

Application control and patching cause the most trouble. Application control is difficult on developer machines and ephemeral cloud workloads, and the patching strategies demand a cadence - as little as 48 hours for actively exploited internet-facing vulnerabilities - that lean engineering teams struggle to sustain. Complete MFA coverage is a close third.

Can we reach Maturity Level Two on most strategies and claim Level Two overall?

No. The maturity model is assessed as a package, so your overall maturity equals your weakest strategy. Seven strategies at Level Two and one at Level One means you are at Level One overall. The fastest way to raise your headline maturity is to fix your weakest strategy, not to improve ones that already pass.

Does the Essential Eight even apply if we run on Linux and cloud infrastructure?

Yes, but you have to translate intent rather than apply Windows-specific controls literally. Application control becomes immutable, signed infrastructure; OS patching becomes rebuilding base images; macro settings become broader control of untrusted code execution. Document the reasoning for every translation, because an assessor will expect it.

How long does it take to reach a target maturity level?

It depends entirely on your starting point, but the long pole is almost never a single tool - it is building the sustained operational cadence for patching, keeping MFA coverage complete, and generating evidence continuously. Standing up the controls can be quick; embedding them so they hold up under assessment takes longer.

Do we need external help, or can we do this in-house?

Many teams can implement the controls themselves. Where external help pays off is scoping the translation for a non-Windows stack correctly the first time, and providing independent assurance that your evidence would withstand a formal assessment. That is often the difference between passing cleanly and re-doing work.

Where to Start

The Essential Eight rewards honesty. Map your real architecture to the intent of each strategy, find your weakest link, and build evidence collection in from the beginning rather than reconstructing it under deadline. Do that, and the framework becomes a genuine improvement to your security posture instead of a compliance tax.

If you want an independent read on where your SaaS environment actually sits against the Essential Eight, get in touch. Our companion pieces on Essential Eight best practices and turning Essential Eight compliance into business growth are useful next steps.