Implementation guidance for Australian Essential Eight controls in Microsoft environments - ISM controls with PSPF mappings
| Property | Value |
|---|---|
| ISM Control | ISM-1504 |
| Revision | 3 |
| Updated | Dec-23 |
| Guideline | Not provided |
| Section | Authentication hardening |
| Topic | Multi-factor authentication |
| Essential Eight | ML1, ML2, ML3 |
| PSPF Levels | NC, OS, P, S, TS |
Multi-factor authentication (MFA) strengthens access control by requiring an additional verification factor for users accessing the organisation’s online services that process, store or transmit sensitive data1. If the only service uses Entra ID SSO authentication, create a Conditional Access policy requiring MFA for that app using the Entra ID Portal2.
“Sensitive data” in the Australian Government context means data classified as OFFICIAL: Sensitive or higher under the PSPF. This includes personal privacy information, legal-privilege material, health records, and other information where disclosure could cause limited to significant harm.3
The required CA grant control varies by maturity level. At ML1, any MFA method satisfies the control. At ML2 and ML3, the CA grant must use Require authentication strength → Phishing-resistant MFA, restricting authentication to FIDO2 keys, Windows Hello for Business (TPM), certificate-based authentication, or device-bound passkeys only.45
[!NOTE] The MFA for Volume Licensing Central Conditional Access policy will be created in the Microsoft Entra ID Portal to require multifactor authentication for all users accessing the Volume Licensing Central app. It will be applied via Conditional Access targeting Volume Licensing Central and will enforce MFA for all sign-ins.
Security Defaults: If your tenant supports it, you can enable Security Defaults to require MFA broadly. This solution applies MFA to sign-ins across apps, not just Volume Licensing Central. [Not provided in source documentation]2
Per-User MFA (Legacy): As a fallback, enable MFA on a per-user basis for Volume Licensing Central users. This is less scalable and is generally not recommended over Conditional Access. [Not provided in source documentation]2
Note: The above alternatives are described in the source as fallback options if Conditional Access is not available. They apply MFA in broader or per-user scopes rather than a targeted policy for Volume Licensing Central. 2
| Maturity Level | Acceptable MFA methods | Recommended CA grant control |
|---|---|---|
| ML1 | Any registered MFA method (push notification, OATH token, SMS) | Require multi-factor authentication (legacy grant) |
| ML2 | Phishing-resistant: FIDO2, Windows Hello for Business (TPM), CBA, device-bound passkeys | Require authentication strength → Phishing-resistant MFA |
| ML3 | Same phishing-resistant methods; centralised MFA event logging to SIEM is mandatory | Require authentication strength → Phishing-resistant MFA + forward sign-in logs to Sentinel |
[!NOTE] Use “Require authentication strength” (available in Entra Conditional Access under Access controls → Grant) rather than the legacy “Require multi-factor authentication” grant when targeting ML2/ML3, as it enforces the specific method set and cannot be satisfied by weaker methods such as SMS OTP.5
Configure Essential Eight MFA conditional access policies ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
Mandatory MFA for Volume Licensing Central – Partner Guidance ↩ ↩2 ↩3 ↩4 ↩5 ↩6
ISM controls and multi-factor authentication — Microsoft Learn ↩
Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users ↩ ↩2 ↩3
Authentication strengths in Conditional Access — Microsoft Learn ↩ ↩2