Maintaining Essential Eight maturity: recurring tasks

The patch cadences in the Essential Eight are minimum frequencies, so a scan that runs late is a gap in the evidence, even if the vulnerabilities it finds are later fixed. The ML1 patching requirements set fortnightly automated asset discovery, daily vulnerability scanning for online services and internet-facing operating systems, weekly scanning for common user applications, and fortnightly scanning for workstation operating systems. An assessor will look for proof that each of these ran on schedule across the whole review period, not just a clean report from the most recent run.

Three records have to line up for that proof to hold: the scanner schedule, the asset inventory the scanner draws from, and the ticket trail that shows findings were acted on. A missed scan window leaves a hole in the schedule, and a host that joined the network after the last discovery run is absent from the inventory, so it is never scanned at all. Tickets opened from findings then need a timestamp and closure record that connects back to the scan that raised them. Confirm with your own tooling whether scan job history is retained long enough to cover the assessment period, whether failed or skipped jobs generate an alert, and whether discovery feeds directly into the scanner's target list.

Confirm also whether your internal policy sets a stricter cadence or shorter patch deadlines than the ML1 minimums. Those internal targets are the ones you will be measured against during routine operations, and an assessor may test against them even when the Essential Eight minimum is met. Document any exceptions with an owner, a reason and an expiry date, so a deferred scan or an extended patch window reads as a managed decision rather than a silent lapse. The patch deadlines themselves are set in the patch applications strategy, so reconcile those figures before writing the cadence procedure.

Privileged access under the Essential Eight needs two expiry tests, and an assessor will check both. The first is inactivity: privileged access must be disabled after 45 days without use (ISM-1648). The second is age: privileged access must be disabled after 12 months unless someone has revalidated it (ISM-1647). The inactivity test catches accounts that were left behind by a project or a role change. The age test forces a periodic decision about whether each administrator still needs the access at all. Both tests apply to every privileged account, including accounts that are rarely used for emergencies, so they belong on the same recurring schedule as the other tasks on this page.

Evidence for these tests is a combination of three things. The first is an identity export from the directory that lists every privileged account, its group memberships and its status. The second is last sign-in data for each of those accounts, which shows whether the 45-day test was met. The third is a documented revalidation decision for each account approaching the 12-month limit, recording who approved the continued access, why it is still required and when it will be reviewed again. An assessor will usually sample accounts and ask to see all three for the same person, so the export, the sign-in data and the decision record must agree with each other and carry dates.

Before relying on this process, confirm three things with your own environment. Ask your directory administrators how inactivity is calculated for privileged accounts, including whether sign-in timestamps are replicated across domain controllers or tenants and whether service accounts are excluded. Confirm where revalidation records are kept and who can edit them, since a decision record that the administrator can change is weak evidence. Finally, confirm how disabled accounts are reported, so that a deactivation counts as evidence rather than a silent change. The tooling you choose should answer these questions in writing before the first assessment cycle.

Microsoft describes Essential Eight assessment and remediation, using its own guides, as a point-in-time activity. That framing matters because an assessment records how systems were configured on the day it was performed, not how they are configured today. A workstation fleet that met the application control expectations in March can drift by September after a new installer is approved, a group policy is overridden for a pilot team, or a privileged account is granted a role during an incident and never removed. The level you were assessed at is only as durable as the settings that produced it, so the recurring work in this topic exists to detect that change before an assessor or an attacker does.

Microsoft recommends Microsoft Purview Compliance Manager to monitor for compliance and configuration drift. The tool includes Essential Eight premium templates for all three maturity levels, which means the assessment controls can be tracked against the same level you are targeting. Before relying on it, confirm with Microsoft or your licensing partner which Purview license tier includes Compliance Manager premium templates, whether your Microsoft 365 and Entra ID tenants are in scope, and whether it can read the Intune, Defender and Windows Update signals your environment actually uses. Ask which controls it evaluates automatically and which require a manual attestation, because a dashboard that shows green for controls it cannot observe gives a false sense of coverage.

Decide before the next assessment cycle which owner reviews drift reports, how often, and what triggers an out-of-cycle check, such as a new privileged role, a change to the application control policy or a new internet-facing service. A monitoring tool records the drift; someone in the organization still has to decide whether it breaks the level. Self-hosted or open-source platforms can cover parts of this gap, so compare what the tool sees with what your own configuration baseline says it should see.