Essential Eight Identity Security Audit Checklist

Which Essential Eight controls are identity controls

The Essential Eight is eight mitigation strategies published by the Australian Cyber Security Centre (ACSC): application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication, and regular backups.

Of those eight, exactly two are observable from identity infrastructure data, specifically from an Entra ID tenant. Strategy 5 (E8-5), restrict administrative privileges, is directly about who holds privileged roles, how those roles are assigned, and whether privileged access is time-bound rather than standing. Strategy 7 (E8-7), multi-factor authentication, is directly about who has MFA enforced, which methods they use, and whether enforcement has gaps.

The other six strategies are not identity controls. Application control and patch applications concern endpoint and software inventory. Office macro settings and user application hardening concern client configuration. Patch operating systems concerns device and server patch cadence. Regular backups concerns data protection and recovery testing. None of these can be assessed from Entra ID sign-in logs, role assignments, or Conditional Access policies, and any tool or checklist that claims to give you “Essential Eight coverage” from identity data alone is either overstating its scope or quietly assessing something else and calling it E8.

That scope boundary matters for this article and for anyone preparing an audit. If your organisation is being assessed against the full Essential Eight, E8-5 and E8-7 are only two of eight lines on the assessment, and you’ll need separate evidence streams for the other six from your endpoint management, patch management, and backup platforms. What follows here covers E8-5 and E8-7 only, in the depth an identity-focused audit actually needs.

E8-5 audit checklist for Entra ID

Privileged role inventory. Start with a complete list of every Entra ID directory role that carries meaningful privilege, at minimum Global Administrator, Privileged Role Administrator, User Administrator, Application Administrator, and any custom roles with write permissions to identity or access configuration. For each role, record every principal holding it and, critically, whether that assignment is standing (permanently active) or PIM-eligible (activated on demand, time-bound, and logged).

This distinction is the crux of what an assessor is actually checking. A standing Global Administrator assignment means that account has full tenant privilege every hour of every day, whether or not anyone is using it, and it is a permanently available target for compromise. A PIM-eligible assignment means the account has no privilege by default and must actively request and justify elevation, which is logged, time-bound, and (ideally) requires approval or MFA at activation. Two organisations can have identical Global Administrator headcounts and be in completely different postures depending on which model they use. An assessor who sees “12 Global Admins” without the eligible/active breakdown hasn’t learned anything useful yet.

What good looks like: a small number of standing assignments (ideally limited to genuine break-glass accounts), with the working population of admins holding PIM-eligible assignments they activate only when needed.

What the assessor wants as evidence: an exported role assignment report (Entra ID’s Roles and administrators blade, or a Graph API pull) showing role name, principal, and assignment type (eligible vs active/standing), dated at the time of assessment, not a screenshot from six months prior.

Privileged access validation and expiry. A role inventory only tells you the current state. The audit question is whether that state is actively maintained: are eligible and active assignments reviewed on a recurring cadence, do they expire rather than persist indefinitely, and is there a documented access review process behind them (Entra ID Access Reviews or an equivalent manual process).

What good looks like: PIM-eligible assignments with a maximum activation duration, active assignments with expiry dates rather than “permanent,” and a scheduled access review (typically quarterly) that produces a record of who was reviewed, who was removed, and who approved the outcome.

What the assessor wants as evidence: access review history showing at least one completed cycle, not just a review configured but never run. A configured-but-never-executed access review is a common audit finding, because it looks compliant in the settings pane and proves nothing about actual practice.

Separate admin accounts and break-glass hygiene. Check whether administrators use dedicated admin UPNs, distinct from their daily-use accounts, for any privileged activity. An admin who does email, browsing, and Teams chat from the same account they use to manage Conditional Access policies has collapsed the separation the control depends on: a phished daily-use session is now a phished privileged session.

Separately, verify break-glass (emergency access) accounts exist, are excluded from Conditional Access as required for their purpose, and are actively monitored, not just created once and forgotten. A break-glass account with no sign-in monitoring is itself a standing risk that undermines the rest of the E8-5 posture.

What good looks like: privileged activity happening only from accounts that have no standard daily-use function, and break-glass accounts with alerting configured on any sign-in event.

What the assessor wants as evidence: a documented list of admin accounts mapped to their human owners’ standard accounts, showing the separation, plus sign-in log evidence (or alert configuration) demonstrating break-glass account usage is monitored.

E8-7 audit checklist for Entra ID

MFA coverage by user population. MFA coverage is not one number. It needs to be broken down by population, because the risk profile of each group is different and an assessor will ask for each separately: member (employee) users, guest users, and privileged/admin accounts.

Admin accounts deserve the tightest scrutiny of the three. A gap in general member MFA coverage is a real finding, but a gap in admin MFA coverage is a critical one, since it directly undermines the E8-5 control above too: a privileged account without MFA is one credential away from full compromise. Guest accounts are frequently the weakest point in practice, because they authenticate against their home tenant’s policies, not always your own, and coverage gaps here are easy to miss without deliberately checking.

What good looks like: MFA registration and enforcement at or near 100 percent for admins, with a defensible, documented reason for any gap in the general population (for example, service accounts that are separately controlled), and explicit visibility into guest MFA status rather than an assumption that it’s covered.

What the assessor wants as evidence: an MFA registration report (Entra ID’s authentication methods reporting, or Graph API) broken out by these three populations, not a single aggregate percentage.

Phishing-resistant methods and maturity level mapping. Coverage alone isn’t the whole picture. Method strength matters, and this is where maturity level actually bites. SMS and voice call MFA are weak: both are vulnerable to SIM-swap and social engineering, and neither meets the bar for higher maturity levels. Authenticator app push and time-based one-time passcodes are stronger but still phishable through real-time relay attacks. FIDO2 security keys and Windows Hello for Business are phishing-resistant, meaning the credential can’t be relayed or replayed by an attacker sitting between the user and the real sign-in page.

ML1 and ML2 tolerate a broader mix of methods, provided phishing-resistant options are prioritised where practical. ML3 expects phishing-resistant methods specifically for privileged users at minimum, and increasingly as the default expectation across the organisation. An assessor checking maturity level 3 identity controls will specifically ask what proportion of admin MFA registrations are FIDO2 or Windows Hello, not just what proportion have MFA at all.

What good looks like: SMS and voice progressively deprioritised or blocked as a registrable method, and phishing-resistant methods mandated for all privileged accounts at minimum.

What the assessor wants as evidence: a method-type breakdown per user population (again, exportable from Entra ID’s authentication methods reporting), showing the shift toward phishing-resistant methods over time, not just a current snapshot.

Conditional Access gaps and exclusions. This is the single most common finding in identity audits: a Conditional Access policy exists, targets MFA correctly, and looks complete in the portal, but has exclusions (specific users, specific groups, specific applications, or legacy authentication protocols that bypass modern auth entirely) that quietly carve a hole in coverage.

Every exclusion needs a documented, current justification. Exclusions accumulate over time as exceptions are granted under pressure and never revisited, and a policy with a growing exclusion list that nobody can explain is exactly the kind of finding an experienced assessor goes looking for first.

What good looks like: MFA-enforcing Conditional Access policies covering all users and all cloud apps by default, with a short, named, justified exclusion list, reviewed on the same cadence as privileged access reviews, and legacy authentication blocked entirely.

What the assessor wants as evidence: the policy configuration itself (assignments, conditions, exclusions), the sign-in log evidence showing the policy is actually applying (not just configured), and a record of when the exclusion list was last reviewed.

The evidence an assessor actually asks for

This is the part most guidance skips. A single screenshot of a settings pane, taken the day before the assessment, is not evidence of a control operating effectively. It’s evidence the control existed at one point in time. Assessors, particularly for ML2 and ML3, are looking for operating effectiveness: proof the control has been working consistently, not just that it’s switched on today.

A defensible evidence pack for E8-5 and E8-7 typically includes:

• Dated exports (CSV or JSON from Graph API, not manual screenshots) of role assignments, MFA registration status, and Conditional Access configuration, ideally from more than one point in time so a reviewer can see the state hasn’t been assembled for the occasion.
• Access review completion records, showing review cycles actually ran and produced outcomes, not just that reviews are configured.
• Sign-in log samples demonstrating Conditional Access policies are applying in practice, including evidence of blocked legacy authentication attempts if that’s part of the claim.
• A documented, current exclusion list for every Conditional Access policy, with named owners and justification for each entry.
• A change log or history showing standing privileged assignments have decreased or stayed low over time, rather than a single current-state count with no trend behind it.

The common thread is recurrence. One good screenshot proves nothing on its own. A defensible pack proves the control was true last month, is true today, and has a mechanism (access reviews, monitoring, recurring export) that will keep it true next month. That’s what separates a control that’s “configured” from one an assessor will actually sign off as “effective.”

How maturity levels change the bar

Neither E8-5 nor E8-7 is a single pass/fail line. Each has a different bar at ML1, ML2, and ML3, and the gap between those bars is exactly what an assessor is calibrating against.

E8-5, restrict administrative privileges

• ML1: privileged accounts are identified and their access is limited to what’s needed for the role. Standing access is common and accepted.
• ML2: privileged access is time-limited or just-in-time (PIM-eligible) where practical, and access is validated on a recurring review cycle.
• ML3: privileged access is just-in-time by default, standing assignments are exceptional and justified, and privileged activity is actively logged and monitored for anomalies, not just reviewed periodically.

E8-7, multi-factor authentication

• ML1: MFA is enforced for privileged users and remote access, with any phishing-resistant or non-phishing-resistant method accepted.
• ML2: MFA is enforced for all users accessing sensitive data or privileged functions, with a preference toward stronger methods and reduced reliance on SMS/voice.
• ML3: phishing-resistant MFA (FIDO2, Windows Hello for Business) is required for all privileged users at minimum, and is the default expectation more broadly, with weak methods actively blocked rather than merely discouraged.