Not legal advice. I am an engineer. This article describes technical controls and evidence in Microsoft 365. Whether they satisfy the notice for your institution is for your compliance function and, where needed, your legal advisers to decide. Always work from the current text on the MAS website.
What the notice covers
MAS Notice FSM-N06 on cyber hygiene was issued on 9 May 2024 under the Financial Services and Markets Act 2022, applies to banks in Singapore and took effect on 10 May 2024. Section IV sets out six practices:
| Paragraph | Practice, in short | Where it lives in Microsoft 365 |
|---|---|---|
| 4.1 | Every administrative account is secured against unauthorised access or use | Entra ID roles, PIM, Conditional Access, emergency accounts |
| 4.2 | Security patches applied within a timeframe commensurate with the risk; compensating controls where no patch exists | Intune update rings, Windows Autopatch, update reports |
| 4.3 | A written set of security standards for every system, and conformity with it | Security baselines, compliance policies, documented deviations |
| 4.4 | Controls at the network perimeter that restrict unauthorised traffic | Mostly outside Microsoft 365; Defender firewall settings on endpoints |
| 4.5 | Malware protection on every system where available | Defender Antivirus, Defender for Endpoint, Exchange Online Protection |
| 4.6 | MFA for administrative accounts on critical systems, and for all accounts on systems used to access customer information through the internet | Conditional Access, authentication strengths |
The notice defines an administrative account as one with full privileges and unrestricted access to an operating system, database, application, security appliance or network device. In a Microsoft 365 tenant, Global Administrator and the other highly privileged roles fit that description. If Microsoft 365 is used to access customer information through the internet, which is the normal case, 4.6 (b) reaches every user.
4.1 Administrative accounts
- Separate, cloud-only admin accounts, not the daily mailbox account.
- Few permanent Global Administrators. Other admins get eligible assignments in Privileged Identity Management with justification and a time limit.
- Two emergency accounts with FIDO2 keys, excluded from Conditional Access, monitored on every sign-in.
- Phishing-resistant MFA required for directory roles, sign-ins restricted to managed devices where possible.
Evidence: who holds which role, permanently or eligible.
Connect-MgGraph -Scopes "RoleManagement.Read.Directory","Directory.Read.All"
$roles = @{}; Get-MgRoleManagementDirectoryRoleDefinition -All | ForEach-Object { $roles[$_.Id] = $_.DisplayName }
$active = Get-MgRoleManagementDirectoryRoleAssignment -All -ExpandProperty Principal |
Select-Object @{n="Role";e={$roles[$_.RoleDefinitionId]}}, @{n="Principal";e={$_.Principal.AdditionalProperties.userPrincipalName ?? $_.Principal.AdditionalProperties.displayName}}, @{n="Type";e={"Active"}}
$eligible = Get-MgRoleManagementDirectoryRoleEligibilitySchedule -All -ExpandProperty Principal |
Select-Object @{n="Role";e={$roles[$_.RoleDefinitionId]}}, @{n="Principal";e={$_.Principal.AdditionalProperties.userPrincipalName ?? $_.Principal.AdditionalProperties.displayName}}, @{n="Type";e={"Eligible"}}
$active + $eligible | Sort-Object Role, Principal | Export-Csv ".\admin-roles-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformationThe script uses PowerShell 7 syntax. Active assignments include permanent ones and currently activated PIM roles; listing eligible schedules needs Entra ID P2 for PIM.
4.6 Multi-factor authentication
Two policies cover the paragraph in most tenants: one requiring a phishing-resistant authentication strength for directory roles, one requiring MFA for all users on all resources, plus a policy that blocks legacy authentication, which cannot do MFA. Roll them out as described in Conditional Access in phases.
Evidence has three parts: the policies themselves, who is registered for which methods, and sign-ins that show the policies working.
Connect-MgGraph -Scopes "Policy.Read.All","AuditLog.Read.All","UserAuthenticationMethod.Read.All"
# 1. The policies, as JSON with a timestamp
Get-MgIdentityConditionalAccessPolicy -All | ConvertTo-Json -Depth 20 |
Out-File ".\ca-policies-$(Get-Date -Format yyyyMMdd).json" -Encoding utf8
# 2. Registration: who has MFA, who has a phishing-resistant method
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Select-Object UserPrincipalName, IsAdmin, IsMfaRegistered, IsPasswordlessCapable, @{n="Methods";e={$_.MethodsRegistered -join ","}} |
Export-Csv ".\mfa-registration-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
# 3. Sign-ins with legacy protocols in the last 7 days (should be none once blocked)
$since = (Get-Date).ToUniversalTime().AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -All |
Where-Object { $_.ClientAppUsed -in "Exchange ActiveSync","Other clients","IMAP4","POP3","Authenticated SMTP" } |
Select-Object CreatedDateTime, UserPrincipalName, ClientAppUsed, @{n="Status";e={$_.Status.ErrorCode}}4.2 Security patches
For Windows devices managed with Intune, update rings or Windows Autopatch set deadlines, and the Windows update reports in Intune show which devices are behind. The notice asks for a timeframe commensurate with the risk, so write the timeframes down: for example, how many days for a critical security update, and what happens with devices that miss the deadline.
A simple, repeatable snapshot of operating system versions and last check-in:
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice -All -Property DeviceName, OperatingSystem, OsVersion, LastSyncDateTime, ComplianceState, UserPrincipalName |
Select-Object DeviceName, OperatingSystem, OsVersion, LastSyncDateTime, ComplianceState, UserPrincipalName |
Export-Csv ".\devices-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformationCompare the OS build with Microsoft's current release information, and treat devices that have not checked in for weeks as their own finding: an unmanaged device is an unpatched device. Microsoft 365 itself is patched by Microsoft; what you own is the endpoints, the Office apps on them and anything still on-premises.
4.3 Security standards, 4.5 malware protection
A written standard for Microsoft 365 can be short: the baseline you follow (for example the CIS Microsoft 365 benchmark or Microsoft's security baselines in Intune), the settings you deliberately deviate from, and why. Conformity is then shown by compliance policies in Intune and by a regular, read-only assessment of the tenant. For malware protection, Defender Antivirus on every managed Windows device, reported through Intune or Defender for Endpoint, and Exchange Online Protection with anti-malware policies for mail.
Keep the evidence longer than Microsoft does
Microsoft keeps Entra audit and sign-in logs for 30 days with Entra ID P1 or P2, and 7 days without. The Unified Audit Log is kept for 180 days with Audit (Standard). If an examiner asks about a role assignment from last year, the portal will not have it. Export the scripts' output on a schedule, store it with a timestamp where it cannot be changed casually, or stream the logs to a Log Analytics workspace with the retention you need.
Checklist
- Separate cloud-only admin accounts; permanent Global Administrators kept to a minimum
- PIM for other privileged roles, with justification and time limits
- Two monitored emergency accounts with FIDO2 keys
- Phishing-resistant MFA for directory roles; MFA for all users; legacy authentication blocked
- Written patch timeframes per severity; update rings or Autopatch enforcing them
- Written security standard with documented deviations; compliance policies in Intune
- Defender Antivirus reported on every managed device; anti-malware policies in Exchange Online
- Evidence scripts scheduled, output stored with timestamps beyond Microsoft's log retention