Most NZ government agencies and critical infrastructure operators targeting Essential Eight compliance are working toward Maturity Level 2. ML2 is the level at which the ACSC considers an organisation to have addressed a significant proportion of adversary techniques — but it's substantially more demanding than ML1, and assessors regularly find gaps in organisations that believe they're compliant.
This post covers what each of the eight mitigation strategies actually requires at ML2, and where organisations most commonly fall short.
What ML2 means structurally
At ML1, controls address commodity threats — the low-skill, opportunistic attacks that make up the bulk of incident volume. At ML2, the controls are calibrated against more targeted adversaries who will actively probe for gaps in basic defences.
The ACSC defines ML2 as: "Aligned with the intent of the mitigation strategy." That's a significantly higher bar than ML1's "partly aligned" standard. Evidence requirements are more specific, exception management is more formal, and coverage gaps that would pass an ML1 review will fail at ML2.
Application control
ML1: Prevents execution of unapproved executables in standard user locations.
ML2 requires:
- Application control covering all user-accessible paths, including temp folders, browser download directories, and user profile paths
- Annual review and revalidation of the approved application list
- Controls on Windows Script Host, PowerShell execution policy, and macro execution in Office applications
- Blocked execution from network shares for standard users
The most common gap: organisations implement AppLocker or equivalent for standard executable paths but leave PowerShell and script execution unconstrained for standard users.
Patch applications
ML1: Critical patches applied within one month.
ML2 requires:
- Critical patches for internet-facing services within two weeks of release
- High-severity patches within one month
- Unsupported software (no vendor patches available) must be removed or formally risk-accepted with compensating controls documented
- Coverage: all applications on all internet-facing systems, not just priority applications
Common gap: patch coverage is good for Tier 1 applications but incomplete for third-party components (browser extensions, plugins, Java, PDF readers) that are frequently exploited.
Configure Microsoft Office macro settings
ML2 requires:
- Macros disabled by default for all users
- Only signed macros from trusted publishers permitted
- Macros from the internet blocked, including from email attachments
- Logging of macro execution enabled
Organisations running unmanaged macro policies or allowing unsigned macros from internal shares will fail ML2 assessment on this control.
User application hardening
ML2 requires:
- Web browsers: disable Java, Flash (if still present), ads from non-trusted domains
- Microsoft Office: Object Linking and Embedding (OLE) packages blocked
- PDF readers: disable JavaScript execution within PDFs
- Internet Explorer retired or blocked
Restrict administrative privileges
ML1: Admin accounts separate from standard user accounts.
ML2 requires:
- Privileged access workstations (PAWs) or equivalent — admin accounts must not be used for web browsing, email, or standard productivity tasks
- Just-in-time access for privileged operations where feasible
- Annual review of admin account holders with justification documented
- MFA mandatory on all privileged accounts
- Admin accounts not to have email or internet access
The PAW requirement is frequently the hardest to implement operationally and the most common ML2 gap for agencies that have addressed the simpler account separation requirement.
Patch operating systems
ML2 requirements mirror patch applications:
- Critical vulnerabilities on internet-facing systems patched within two weeks
- High-severity within one month
- Unsupported OS versions removed or compensating controls documented and risk-accepted
Multi-factor authentication
ML2 requires:
- MFA on all internet-facing services (email, VPN, remote access, SaaS applications)
- MFA on privileged accounts for all internal systems (not just internet-facing)
- MFA resistant to replay attacks — SMS OTP does not meet ML2 for privileged accounts
- Phishing-resistant MFA (hardware keys or FIDO2) required for admin accounts at some agency classifications
Organisations using SMS-based MFA for privileged access will not meet ML2 for this control.
Regular backups
ML2 requires:
- Backups of business-critical data, configuration, and software
- Backups stored offline or in an immutable state (cannot be encrypted or deleted from the primary network)
- Backup restoration tested at least annually with results documented
- Backup access restricted to backup administrators only
Cloud backups that are accessible from the same credentials as the primary environment do not meet the offline/immutable requirement.
Preparing for ML2 assessment
Before engaging an assessor, review:
- Application control coverage — run a test to confirm script execution is blocked for standard users
- Patch coverage — confirm third-party application patching is included in scope
- Privileged access — document PAW or equivalent implementation, confirm no admin account email or internet access
- MFA — audit all privileged accounts and confirm SMS OTP is not the sole second factor
- Backup isolation — confirm backups cannot be accessed or deleted from the primary environment
The ACSC Essential Eight Maturity Model documentation is the authoritative reference. The November 2023 update made material changes to ML2 and ML3 requirements — if your gap assessment was done against an earlier version, re-run it.
AccreditAZ maps your current control implementation against the current Essential Eight maturity model, identifies gaps by control and maturity level, and generates the evidence documentation required for assessment. If you're managing Essential Eight alongside NZISM, see our guide on multi-framework compliance to avoid duplicating effort across both. Start your assessment to see where you stand against ML2.