First time Essential Eight mistakes include working on strategies at uneven maturity levels, jumping to level three, keeping exceptions informal, treating the model as a full security program, and never restoring a backup. ASD's own guidance speaks to each of these.
Mistake 1: uneven levels
Teams often finish MFA and backups, then leave application control. ASD says the eight strategies complement each other and advises reaching the same level across all eight before moving higher. An attacker will use whichever strategy is weakest. Chart your current level per strategy and put the lowest first.
Mistake 2: picking level three on day one
The model describes more capable attackers at each level. Level three is a large step in effort, tooling and logging. ASD tells organisations to choose a target that fits their environment, then build up level by level. A level one result with evidence beats a level three plan that stalls.
Mistake 3: informal exceptions
Every real environment has legacy systems and awkward software. ASD expects exceptions to be minimised in number and scope, covered by compensating controls, documented, approved through a process and reviewed regularly. ASD also says appropriate use of exceptions need not stop an assessor rating you as meeting a level. A spreadsheet with owner, reason, compensating control, approver and expiry date does the job. A hallway agreement does not.
Mistake 4: missing the online services
MFA statements in the model reach beyond your own login page. In the copy I read, they cover your organisation's online services and third party online services that hold sensitive data. New SaaS tools sneak in through credit cards and free trials. Keep a live list and check MFA on each. (The copy was an archived page because the live site blocked automated access, so confirm against the current model.)
Mistake 5: patching only operating systems
The model has separate strategies for patching applications and operating systems, with different scanning cadences and patch windows. Browsers, office suites, PDF software, security products and online services each need coverage. Add asset discovery too, since the copy I read requires it at least fortnightly.
Mistake 6: application control that never leaves audit mode
Audit mode helps you learn what runs. It does not block anything. Set a date to enforce, with a process for adding approved software. At the second level the copy I read also expects rule sets to be validated at least annually and events to be centrally logged.
Mistake 7: backups never restored
The model asks that restoration from backups is tested as part of disaster recovery exercises, and that ordinary accounts cannot modify or delete backups. A green backup job proves nothing about a restore. Run one and write down how long it took.
Mistake 8: treating the Essential Eight as the whole program
ASD calls it a minimum set of preventative measures. It will not mitigate every threat, and ASD points to its wider mitigation strategies and the Information Security Manual for more. It was also designed for internet connected IT networks, not operational technology.
Mistake 9: assuming a certificate is needed
ASD says there is no requirement for independent certification. An assessment may still be demanded by government policy, a regulator or a contract. Ask the party who is asking.
What to do
- Chart maturity per strategy and fix the weakest first.
- Choose a target level you can evidence.
- Create an exceptions register with expiry dates.
- List online services and check MFA on each.
- Schedule asset discovery and scans.
- Set an enforcement date for application control.
- Restore a backup this month.
- Ask who requires an assessment, and to what standard.
Quick check
Can I have exceptions and still meet a level?
ASD says appropriate use of exceptions does not preclude being assessed as meeting a level, provided they are minimised, documented, approved and reviewed.
Is level three enough to stop any attacker?
No. ASD says level three will not stop an actor willing to invest enough time, money and effort.
How Safeguard helps automate this
Most of these mistakes are visibility problems: an unknown tool, an overdue patch, an exception nobody reviews. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between assessments. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which shows which vulnerable packages are reachable and deserve the fast patch window. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically. An independent assessor decides your rating, not Safeguard.
Sources
Last reviewed: 18 October 2026.
