Why Your Essential Eight Audit is Probably Wrong (And How to Fix It)

You've completed your Essential Eight assessment. The spreadsheet is green. The board is happy. Your cyber insurance renewal sailed through.

Here's the uncomfortable truth: you're probably not as secure as that audit says you are.

After conducting assessments across dozens of Australian organisations — from ASX-listed companies to local councils — we've identified the same failures again and again. Not dramatic headline-grabbing breaches. Quiet, structural gaps that audits consistently miss because they're designed to verify documentation, not test defences.

This article isn't a theoretical critique. It's a field guide to the seven audit failures we see most often, why they matter, and how to validate your controls properly before someone with worse intentions does it for you.

The Compliance vs Security Gap

The Australian Cyber Security Centre (ACSC) designed the Essential Eight as a baseline — the minimum viable security posture, not the finish line. But the maturity model has an unintended side effect: it makes security look like a scoring exercise.

Maturity Level One: documented policy exists. Maturity Level Two: policy is partially implemented. Maturity Level Three: policy is fully implemented and automated.

Here's what that model doesn't capture well: a fully implemented, automated control can still be bypassed in five minutes by someone who knows what they're doing.

Most Essential Eight audits follow a predictable pattern: review documentation, interview stakeholders, inspect configuration screenshots, sample a subset of endpoints. That tells you whether the *intent* to secure exists. It doesn't tell you whether the *defence* actually holds up.

Real validation requires adversarial testing — attempting to do the things your controls are supposed to prevent, and documenting what happens when you do.

Seven Essential Eight Audit Failures We See Constantly

1. Application Control: "Approved, Except..."

The Audit Finding: *"Application control is implemented. Default deny policy is active. Approved application lists are maintained."*

The Reality: There's always an exception. Usually several.

• ▸The CFO's laptop runs an older accounting package that "can't be on the list"
• ▸The IT admin has a blanket bypass for "troubleshooting"
• ▸A contractor's machine was missed during deployment
• ▸The policy allows anything signed by a trusted publisher — which includes every .msi on the internet

How to Actually Test:

1. 1.Obtain a non-admin standard user account
2. 2.Attempt to run common unsigned tools: `mimikatz.exe`, a custom PowerShell script, a renamed legitimate application
3. 3.Attempt to run known-safe but non-whitelisted software (e.g., a new version of Chrome portable)
4. 4.Document every path that succeeds

If anything executes without explicit approval workflow and logging, your application control has holes.

ACSC Maturity Level Three specifically requires: *"Microsoft Windows environments implement application control using AppLocker or Windows Defender Application Control (WDAC) with default-deny policies."* Most audits check the policy exists. Few attempt to bypass it.

2. Patch Applications: The One-Month Lie

The Audit Finding: *"Critical vulnerabilities are patched within 48 hours. High-risk applications are patched within two weeks."*

The Reality: That clock starts when the auditor *asks*, not when the patch was released.

More importantly, the scope of "high-risk applications" is usually narrower than it should be. The audit samples Chrome, Office, and the OS. It doesn't check:

• ▸Java Runtime Environment on that one legacy server
• ▸The VPN client running on 40% of endpoints
• ▸The marketing team's Adobe suite
• ▸Chrome extensions (which update independently and have been used as attack vectors)

How to Actually Test:

1. 1.Run an unauthenticated vulnerability scan across your entire network — not just servers, every endpoint
2. 2.Check version numbers of every application the ACSC lists as high-risk, not just the obvious ones
3. 3.Look at patch age distribution: what percentage of systems are more than 30 days behind on *any* high-risk app?
4. 4.Test whether the patching mechanism actually works: deploy a test patch and verify it applies, even on remote/WFH machines

3. Configure Office Macros: The Percentage Problem

The Audit Finding: *"Microsoft Office macros are disabled by default. Only digitally signed macros from trusted publishers are allowed."*

The Reality: "Disabled by default" sounds comprehensive. It isn't.

If your policy allows signed macros, your policy allows any macro signed with a certificate purchased from a commercial CA. That costs about $200 and a business registration — not exactly a high bar for a determined attacker.

More commonly: the finance team has a macro-enabled template they "need." The exception is granted. Then copied. Then becomes standard practice. No one revokes it because no one remembers why it exists.

How to Actually Test:

1. 1.Create a macro-enabled document (.docm or .xlsm) with a benign macro
2. 2.Sign it with a self-signed certificate (free, takes 30 seconds)
3. 3.Email it to yourself and open it on a standard user machine
4. 4.Does it execute? Does it prompt? Is the prompt clear enough that an actual user would understand the risk?

If a user can click "Enable Content" and run code, your macro control is only as strong as your least careful employee.

4. User Application Hardening: Checked, But Not Enforced

The Audit Finding: *"Web browsers are configured to block Flash content. Java is disabled. Ads are blocked."*

The Reality: Group Policy exists. Group Policy is applied. Group Policy is also sometimes:

• ▸Overridden by local admin actions
• ▸Bypassed by users installing alternative browsers
• ▸Not applied to BYOD or contractor machines that access corporate data
• ▸Missing on machines that were imaged before the policy was created

How to Actually Test:

1. 1.Attempt to install an old browser plugin on a standard machine
2. 2.Check browser configuration on 10 random endpoints — not the ones IT prepared for the audit
3. 3.Attempt to access a known phishing or malware test site (services like KnowBe4 or Cofense provide safe ones)
4. 4.Verify that the blocking actually happens, and that the user sees a clear denial, not a confusing error

5. Restrict Administrative Privileges: Admin-by-Tradition

The Audit Finding: *"Administrative privileges are restricted. Privileged access is controlled, monitored, and logged."*

The Reality: This is consistently the weakest control in Australian organisations. Not because the policy is bad — because the exceptions have accrued over years.

• ▸"Dave in Finance needs local admin for his accounting software"
• ▸"The CEO's EA has domain admin because she used to help with IT"
• ▸"The developers all have admin because otherwise Docker doesn't work"
• ▸Service accounts with domain admin rights because "something broke once and that fixed it"

How to Actually Test:

1. 1.Audit every account with local or domain admin rights
2. 2.For each account, demand: *what specific task requires this level of access?*
3. 3.Attempt to perform common non-admin tasks (installing approved software, updating drivers, configuring printers) with a standard user account
4. 4.Check if any admin accounts are shared, have passwords in documentation, or haven't had their passwords rotated

If you can't explain exactly why each admin account exists and what specific function requires it, it's probably unnecessary — and dangerous.

6. Multi-Factor Authentication: The MFA That Isn't

The Audit Finding: *"Multi-factor authentication is enforced for all remote access and privileged accounts."*

The Reality: MFA is enabled. It's also sometimes:

• ▸Bypassable via "remember this device for 30 days" — which is essentially single-factor on a persistent machine
• ▸Not enforced for legacy protocols (IMAP, POP3, basic auth) that modern attackers love
• ▸Missing on break-glass or emergency access accounts
• ▸Implemented as SMS, which is vulnerable to SIM swapping and phishing

How to Actually Test:

1. 1.Attempt to authenticate to every remote entry point (VPN, RDP gateway, webmail, cloud apps) with only a password
2. 2.Check whether legacy authentication protocols are blocked at the firewall or identity provider
3. 3.Verify that "remember device" options are disabled or tightly scoped
4. 4.Attempt a SIM swap or MFA fatigue attack in a controlled test
5. 5.Check if MFA can be bypassed by contacting the help desk (social engineering test)

7. Regular Backups: Restored, Not Just Stored

The Audit Finding: *"Backups are performed regularly, encrypted, and stored offsite."*

The Reality: Backups are performed. They've rarely been restored. The encryption key is known by one person who's on leave. The "offsite" storage is actually the same AWS region as production because cross-region replication "costs too much."

How to Actually Test:

1. 1.Perform a full restoration of a critical system to isolated hardware — not the original infrastructure
2. 2.Time the process. Document every manual step. Account for decryption time, network bandwidth, and licensing
3. 3.Verify that the restored system actually works, not just that files exist
4. 4.Test whether the backup itself is clean — ransomware often sits dormant for weeks before detonating
5. 5.Check backup immutability: can an admin with current credentials delete or encrypt the backups?

If your recovery time objective is 4 hours but your last test took 3 days, your documented RTO is fiction.

What Real Validation Looks Like

The difference between a compliance audit and a security validation is adversarial intent.

A compliance audit reviews documentation, interviews IT staff, samples configuration, and checks that policy exists. A security validation attempts to bypass controls, tests with standard user accounts, validates every high-risk application, and verifies policy actually prevents the threat.

You don't need to hire red team operators for this. You need someone who understands the ACSC guidelines *and* has the independence to say: *"Yes, the policy exists. No, it doesn't actually work the way you think it does."*

A Short Validation Checklist

Run this yourself before your next audit. If you can't answer "yes" confidently to every item, you have work to do.

• ▸Can a standard user execute an unsigned application?
• ▸Are all exceptions documented with business justification?
• ▸Is execution logged and reviewed?

• ▸Do you have a complete inventory of all high-risk applications?
• ▸Are any applications more than 30 days behind on patches?
• ▸Can you verify patch status on remote/WFH machines?

• ▸Can a user execute a signed macro from an unknown publisher?
• ▸Are macro exceptions reviewed quarterly?
• ▸Do users understand the macro enable prompt, or do they click through?

• ▸Are browser configurations consistent across all endpoints?
• ▸Can users install alternative browsers with weaker defaults?
• ▸Are ads, Flash, and Java genuinely blocked?

• ▸Can you justify every account with admin rights?
• ▸Are service accounts using least-privilege principles?
• ▸Is privileged access logged and anomaly-detected?

• ▸Is every remote access point protected by MFA?
• ▸Are legacy authentication protocols explicitly blocked?
• ▸Is MFA resistant to phishing and fatigue attacks?

• ▸Have you performed a full restoration test in the last 6 months?
• ▸Are backups immutable and isolated from production?
• ▸Does more than one person know how to access decryption keys?

The Bottom Line

The Essential Eight is a solid framework. The maturity model provides useful structure. But compliance with the framework is not the same as resilience against actual attacks.

If your audit process stops at documentation review, you're measuring intent — not outcomes. And in cybersecurity, outcomes are the only metric that matters when someone decides to test your defences for real.

A real Essential Eight assessment should leave you slightly uncomfortable. It should find gaps. It should force prioritisation. It should make you wonder whether you're doing enough — because that wondering is what drives actual improvement.

If your last audit left you completely satisfied, it probably wasn't thorough enough.

Need an Essential Eight assessment that tests your defences, not your documentation? Cloudscape IT conducts adversarial security assessments for Australian organisations. We find the gaps that checkbox audits miss.