Why the Essential Eight matters
Start with the environment and the evidence, not a product list. ASD designed the Essential Eight for internet-connected IT networks. Its principles can inform mobile and operational environments, but the model was not designed specifically for them. A factory control network, specialist medical system or SaaS-only workflow needs a scope and risk assessment rather than an unqualified claim that the same checklist covers everything. ASD Essential Eight maturity model.
The model is a minimum set of preventative measures, not a complete security programme or a guarantee against intrusion. Monitoring, incident response, supplier access, privacy and business continuity still need attention. Decide what systems the assessment covers and what sits outside it before leadership agrees a maturity target.
ASD announced consultation on an expanded Essentials series in June 2026, with feedback on the enterprise IT chapter due by 12 July 2026. The notice describes strong alignment with existing Essential Eight investment. It does not itself establish a binding retirement date. Keep improving current controls and check published ASD guidance before changing the framework named in an assessment or contract. ASD Essentials series consultation notice.
For the transition context, read our Essentials series guide.
Eight controls, three jobs
The three jobs below are a useful way to explain investment, but ASD does not treat the controls as independent options. Patching helps close the entry route; restricted privilege limits what a stolen identity can do; protected backups help recovery if prevention fails. An exception in one control can weaken several others. Plan a consistent maturity level across the eight strategies. ASD Essential Eight maturity model.
The Essential Eight is usually drawn as a wheel, which hides the useful part. The eight controls are not eight equal boxes to tick. They do three different jobs: stop the attack landing, contain it if it does, and get you back on your feet.
Job one
Stop malicious code running
Four controls that close the front door.
Application control
Only approved software is allowed to execute. Everything else is blocked by default.
Patch applications
Discover installed software and apply the asset-specific ASD deadlines. Do not put critical exposed services on a generic two-week patch cycle.
Configure Office macro settings
Macros off for users who do not need them, blocked from the internet, and scanned when they are allowed.
User application hardening
Turn off the risky bits users never asked for: web ads, Java in the browser, legacy scripting.
Job two
Limit how far an incident spreads
Three controls that decide whether one compromised account becomes a company-wide event.
Restrict administrative privileges
Admin rights granted on request, reviewed regularly, and never used for email or web browsing.
Patch operating systems
Same urgency as applications, and unsupported versions retired rather than nursed along.
Multi-factor authentication
On for every user, every remote service, and phishing resistant where it matters most.
Job three
Get the business back
The control everyone assumes is handled, and the one ransomware tests first.
Regular backups
Backed up on a schedule that matches what you can afford to lose, kept where an attacker with admin rights cannot reach them, and restored as a test rather than as a surprise.
Choosing and assessing maturity levels
A target is different from an assessed result. Choose the target using the sensitivity of your data, service dependencies, likely attacker techniques and contractual requirements. Then assess each strategy against the published criteria. Do not average the scores or call the whole environment Level Two because MFA and patching are at that level while application control remains unenforced.
Phishing resistance is not an administrators-only Level Three requirement. The model specifies phishing-resistant MFA for users of online services and systems at Level Two; Level Three extends the requirements further. Ordinary push approval and time-based codes do not provide the same resistance. Account recovery, compatible devices and exceptions need to be planned alongside passkeys or hardware keys. ASD Essential Eight maturity model.
ML0
Level zero
Weaknesses an opportunistic attacker can walk through.
ML1
Level one
Holds up against widely available tooling and commodity attacks.
ML2
Level two
Holds up against attackers willing to spend time on you specifically.
ML3
Level three
Holds up against adaptive attackers with real resources.
The eight controls in detail
Keep an evidence register for every control: requirement, system scope, owner, configuration evidence, test result and review date. For application control, show a blocked unauthorised executable on a representative device. For patching, show discovery, deployment and verification dates. For MFA, demonstrate a denied sign-in using an unapproved method. For backups, show a completed restoration, not just successful backup jobs.
ASD patch deadlines depend on the asset, vulnerability and target level. At Level One, online services and internet-facing operating systems have a 48-hour deadline from release when a vendor rates a vulnerability critical or a working exploit exists. Non-critical cases for those exposed services have a two-week deadline. Office suites, browsers, PDF tools and security products also have specified two-week requirements; other applications and internal operating systems have separate criteria. Use the actual model rather than one deadline for all software. ASD Essential Eight maturity model.
Regular backups cover data, applications and settings, with retention and frequency matched to business criticality. They must support restoration to a common point in time and be tested in disaster recovery exercises. Higher maturity levels add tighter restrictions on privileged access and deletion. Offline or appropriately immutable copies can support those outcomes, but a 3-2-1-1-0 design is not itself an Essential Eight maturity assessment. ASD Essential Eight maturity model.
1. Application control
BaselineWhat it means
Allow approved software on the required systems. Pilot policies and progress from audit to enforcement.
Common mistakes
Allowing broad writable paths, omitting servers or remaining in audit mode without a decision date.
Why it matters
Reduces the opportunity for unauthorised executables, scripts and other in-scope content to run. Demonstrate blocked execution, not policy presence alone.
2. Patch applications
BaselineWhat it means
Discover installed and exposed applications. Apply the deadline for the asset, severity, exploit availability and target maturity level.
Common mistakes
Tracking Windows updates but omitting browser extensions, PDF software, exposed services or unsupported applications.
Why it matters
Closes known vulnerabilities and makes overdue exposure visible. Record discovery, mitigation and verification dates.
3. Configure Microsoft Office macros
BaselineWhat it means
Disable macros for users who do not need them. Block internet-sourced macros and control authorised use under the target-level requirements.
Common mistakes
Broad trusted locations, unnecessary macro permissions or exception decisions with no expiry or owner.
Why it matters
Reduces execution of malicious macro content. Test the effective setting and the approved business workflow.
4. User application hardening
BaselineWhat it means
Apply managed browser and Office settings, restrict risky content and follow the hardening requirements for the target level.
Common mistakes
Only deploying a policy name without confirming settings reached each device. Leaving legacy features and unsupported software enabled.
Why it matters
Reduces unnecessary browser and document attack paths. Retain configuration and test evidence.
5. Restrict administrative privileges
BaselineWhat it means
Use separate privileged and daily-work accounts, approve required access and review it regularly.
Common mistakes
Using admin accounts for email, keeping stale privileges or overlooking service accounts and supplier access.
Why it matters
Limits the reach of a compromised account. Show role assignments, access reviews and how privileged sessions are controlled.
6. Patch operating systems
BaselineWhat it means
Inventory operating systems and network devices. Apply asset-specific patch deadlines and replace unsupported platforms.
Common mistakes
Indefinite deferrals, missed reboots, unmanaged devices or reporting deployment without checking the installed result.
Why it matters
Reduces exploitable operating-system exposure. Evidence should identify overdue assets and their remediation or approved mitigation.
7. Multi-factor authentication
BaselineWhat it means
Map authentication routes to the model. Level Two requires phishing resistance for users of online services and systems, with further coverage at Level Three.
Common mistakes
Protecting email but missing remote access, permitting weaker fallback methods or leaving account recovery untested.
Why it matters
Reduces credential-only access. Demonstrate the permitted methods and how an unapproved sign-in is denied.
8. Regular backups
BaselineWhat it means
Back up data, applications and settings to support a common recovery point. Match frequency and retention to business needs and test restoration.
Common mistakes
Showing successful jobs without a restore test, exposing deletion permissions or omitting SaaS data and application settings.
Why it matters
Provides an evidenced recovery path. Check backup access and deletion restrictions against the chosen maturity level.
A practical implementation roadmap
Treat the schedule below as an example, not a promised delivery time. Start by recording the current state and assigning owners across all eight strategies. Close urgent exposed vulnerabilities and test recovery early, while discovery and application-control audit work proceed in parallel. A complex legacy application or shared workstation can change the sequencing.
For each rollout, define a pilot group, the business workflow to test, the change window and the rollback plan. Record exceptions with an owner, expiry date, risk approval and compensating controls. Do not leave application control in audit mode indefinitely or broaden trusted paths simply to make blocked software run. ASD allows appropriately managed exceptions, but they need evidence and regular review. ASD Essential Eight maturity model.
An example six-month sequence, adjusted to the assessment and business dependencies:
Month 1
MFA everywhere (control 7). Patch critical OS and app CVEs (controls 2 and 6). Low effort, highest impact.
Month 2
Backup review and immutability (control 8). Office macro hardening (control 3). Measurable wins quickly.
Month 3
Admin account review and segregation (control 5). Remove unnecessary admin rights. Privileged account workflow.
Month 4
User application hardening (control 4). Managed browser policies. Disable legacy Java. Office attack surface reduction.
Month 5
Application control (control 1) in audit mode. Build allowed-software inventory. Move to enforce for pilot group.
Month 6
Application control enforce mode. Final gap audit. Document for insurance renewal. Plan ML2 or ML3 uplift.
Common gaps to check
Check coverage, not just policy existence. Confirm that servers, spare laptops, remote staff, VPN accounts and third-party applications are included where required. Test a newly enrolled device and a returning off-network device. Review whether the policy actually reached them and whether a failed deployment generated an owned task.
App control never reached enforce mode
Audit mode is not control. Must move to enforce or it does not count.
Patches managed manually via RDP
Automated patching with reporting is expected. Manual does not scale and will fail.
Macros allowed from trusted locations
Trusted locations bypass macro policy. Remove them.
Domain admin used as daily account
Separate privileged work from email and browsing. Review where the privileged account can sign in.
Recovery evidence is missing
Check protected copies, retention, deletion rights and a common-point-in-time restore against the target level. An immutable-storage label alone does not demonstrate compliance.
No MFA on VPN
Often overlooked. Remote access without MFA fails Essential Eight.
How SMB1001 certification fits
Reuse evidence where the standards overlap, but map the requirements separately. A certification under SMB1001 does not automatically establish an Essential Eight maturity level, and an Essential Eight assessment does not automatically confer SMB1001 certification. Keep the scope, version, assessor and evidence for each clear to customers and procurement teams.
Essential Eight gives you the technical baseline. SMB1001 wraps it in a certifiable, tiered standard that procurement teams, insurers and enterprise clients increasingly ask for. For most Australian SMBs we work with, this is the most practical certification pathway alongside Essential Eight uplift.
Built for SMBs
Five tiers from Bronze to Diamond. Achievable, affordable, and updated annually.
Separate certification evidence
Keep the certification scope and version available. Check each buyer or insurer requirement rather than assuming universal recognition.
Real Bytes is CyberCert Gold
We hold the certification ourselves. We guide you from the same playbook we ran on our own business.
Insurance, assessment and evidence
Use dated evidence to answer the actual insurer or buyer questionnaire. There is no universal promise that Level One secures cover or Level Two lowers premiums. Terms depend on the policy, business and risk. Explain exclusions and approved exceptions rather than describing partial deployment as organisation-wide compliance.
ASD does not require every organisation to obtain independent Essential Eight certification. An independent assessment may be required by a government policy, regulator or contract. Distinguish your internal assessment, an external assessment and a separate certification scheme when preparing an evidence pack. ASD Essential Eight maturity model.
Related: Cyber Insurance Readiness, IT Risk Guide, SMB1001 certification.
Common questions
What does the Essential Eight cover?
How should we choose an Essential Eight maturity level?
When is phishing-resistant MFA required?
Do all vulnerabilities need patching within 48 hours?
Do we need an Essential Eight certificate?
Should we pause Essential Eight work for the Essentials series?
Achieve Essential Eight Maturity
We run Essential Eight uplifts end to end: gap assessment, ML1 to ML3 roadmap, implementation, audit, and quarterly reviews. Delivered by senior Brisbane-based engineers.

Remote Support