Protecting Microsoft 365 Admins: The Essential Guide to Identity Security in 2025

Singapore’s SMB IT leaders face a growing wave of identity-based attacks against Microsoft 365 environments. Even as basic security measures like multi-factor authentication (MFA) become widespread, attackers are rapidly evolving new techniques to bypass MFA and target privileged accounts. In this blog post, we’ll explore the latest identity-focused threats – from adversary-in-the-middle (AiTM) phishing with tools like EvilProxy and Modlishka to MFA fatigue and even AI-driven password cracking – and explain why Microsoft 365 administrators and other privileged identities are prime targets. We’ll then dive into Microsoft-native countermeasures you can implement today, such as phishing-resistant MFA (FIDO2 keys and passkeys), Conditional Access policies, just-in-time privileged access (PIM), emergency break-glass accounts, Defender for Office 365, and Privileged Access Workstations. A step-by-step security checklist tailored for Singapore SMBs is provided at the end to help you put these recommendations into action.

Introduction: Identity Attacks Are Getting More Sophisticated

Cyber threat actors are more determined than ever to compromise cloud identities, especially as organizations harden their defenses with MFA, passwordless logins, and better email filtering. Microsoft reports that MFA combined with blocking legacy authentication can thwart over 99.9% of common identity attacks. However, attackers have adapted by developing advanced techniques to steal credentials and session tokens, effectively bypassing traditional MFA protections. Social engineering remains central – tricking users into clicking malicious links or approving access – but now it’s augmented by phishing-as-a-service kits, token theft malware, MFA prompt abuse, and even AI-driven password cracking.

In Singapore’s digitally connected business environment, these threats are not abstract. Local SMBs are just as exposed – attackers know that compromising one trusted account (like a Microsoft 365 admin) can lead to a treasure trove of data or financial gain. Phishing and business email compromise (BEC) campaigns frequently hit organizations here and worldwide. According to Microsoft threat intelligence, a single AiTM phishing campaign in 2021–2022 targeted over 10,000 organizations globally to steal passwords and session cookies, bypassing MFA and leading to BEC fraud attempts. It’s crucial for IT leaders to understand how these cutting-edge attacks work in order to deploy the right defenses.

The Rising Threat of MFA-Bypass Attacks

Adversary-in-the-Middle (AiTM) Phishing and Token Theft

One of the most alarming developments is adversary-in-the-middle (AiTM) phishing, where attackers interpose a malicious proxy between the user and the real website to hijack the entire authentication process. In a typical AiTM attack, the victim clicks a link to a fake login page controlled by the attacker. The attacker’s server then proxies all traffic to the legitimate Microsoft 365 login endpoint, so the user sees the familiar Microsoft sign-in screen and even gets prompted for MFA. Behind the scenes, the attacker intercepts the username, password, and MFA code, then replays them to the real Microsoft server in real time. This yields a valid session cookie or token, which the attacker steals and uses to impersonate the user without further authentication. In effect, the attacker obtains the user’s authenticated session – completely bypassing MFA since they never “crack” it, but simply use the stolen session token.

Microsoft emphasizes that AiTM is not an MFA vulnerability per se – the MFA worked, but the attacker piggybacked on the authenticated session cookie. Armed with that session token, attackers can access cloud resources (email, SharePoint, Teams, etc.) as the user until the token expires or is revoked. Sophisticated adversaries will often promptly use the access to perform further malicious activities. For example, they might launch BEC scams by sending invoices from the compromised mailbox, search for sensitive data, or even phish other internal users to move laterally. Recent multi-stage attacks show AiTM being used as an entry point, followed by secondary phishing from the initially compromised account to escalate to higher-value targets.

. Similarly, Modlishka is an open-source tool that red-teamers (and threat actors) use as a transparent reverse proxy. It presents an almost pixel-perfect copy of the Microsoft 365 login page on the attacker’s domain, forwarding all requests to login.microsoftonline.com and capturing any credentials and MFA codes in transit. By grabbing the resulting ESTSAUTH or ESTSAUTHPERSISTENT session cookies from the HTTP responses, the attacker can hijack the authenticated session and access the Office 365 account as if they were the user. In short, tools like EvilProxy, Modlishka, and Evilginx enable attackers to bypass MFA without needing to crack it, by stealing the token that proves a successful login. Microsoft has observed multiple threat actors (from profit-motivated groups like Storm-0485 to nation-state actors) adopting these AiTM toolkits in the past year.

Token theft can also occur through other vectors beyond phishing websites. Malware on an endpoint can steal browser cookies or refresh tokens from memory or disk. There are even phishing techniques like device code phishing that abuse OAuth device login flows to trick users into generating tokens for the attacker. In all cases, the end goal is the same: obtain a valid authentication token or cookie to break into an account without needing the password or second factor. These attacks highlight why session tokens must be protected like passwords, and why additional context and policy are needed around authentication, as we’ll discuss in the countermeasures.

MFA Fatigue and Prompt Bombing

Not all MFA bypass attacks are high-tech; some exploit human behavior. MFA fatigue (or “prompt bombing”) attacks spam the target user with repeated authentication approval requests, hoping the user will eventually hit “Approve” out of annoyance or confusion. This technique has been used in several high-profile breaches. It abuses the fact that many MFA methods (like push notifications or phone calls) only require a simple approval, with no context, allowing attackers who have stolen a user’s password to bombard them with MFA prompts. Microsoft’s security team found that roughly 1% of users will accept an unexpected MFA prompt on the first attempt – a small but significant number. Attackers count on the odds that, after dozens of relentless prompts (often in the middle of the night), the user accidentally or reflexively approves one, thereby unwittingly letting the attacker in.

Such MFA push spam attacks have been rising in step with MFA adoption. They underscore the importance of user awareness as well as technical safeguards. Microsoft has responded by introducing features like number matching in Microsoft Authenticator to combat MFA fatigue. With number matching, when a sign-in occurs the user must input a two-digit code shown on the login screen into their Authenticator app – simply tapping “Approve” is no longer enough. This prevents lazy or unconscious approvals, because if the user didn’t initiate the sign-in, they won’t have the code. In fact, Microsoft made number matching the default for all Authenticator push MFA in 2023 due to the rise of fatigue attacks. In practical terms, enabling number matching and providing users with sign-in context (app name and location) can drastically reduce the success of MFA fatigue exploits. We’ll cover how to enforce these protections in Microsoft 365 shortly.

Password Attacks Supercharged by AI (PassGAN)

While MFA is crucial, we cannot forget that compromising weak passwords is still a common way attackers gain initial access – and they are now leveraging AI to speed up password cracking. A striking example is PassGAN, a deep learning tool that uses Generative Adversarial Networks to guess passwords with uncanny efficiency. In a recent report, researchers demonstrated that PassGAN could crack 51% of common passwords in under a minute (and over 65% within an hour) by learning from billions of real breached passwords. Even complex combinations that would take traditional brute-force tools days or weeks can be cracked in minutes by AI models that learn the patterns of human-created passwords.

For IT administrators, this is a warning that old password policies are no longer enough – an 8-character password with complexity might have been considered “strong” years ago, but modern attackers using AI can rip through those with alarming speed. In practice, this means encouraging users to choose much longer passphrases or, better yet, eliminating passwords through passwordless authentication. It’s also critical to prevent attackers from ever obtaining your password hashes (through good network security and up-to-date systems) and to enable smart lockout and risk-based sign-in detection in Azure AD so that online password spray attempts are thwarted. The rise of PassGAN and similar tools simply reinforces that passwords alone are a flimsy defense in 2025.

Why Microsoft 365 Admins and Privileged Identities Are Prime Targets

Within any Microsoft 365 tenant, global administrators and other privileged role accounts hold the keys to the kingdom. Attackers know this. Microsoft warns that accounts assigned to privileged admin roles are frequent targets of attackers, since compromising one can grant expansive access to systems and data. Think of a Global Admin account – it can manage user accounts, access all mailboxes, modify security settings, and more. If an adversary manages to control a Global Admin, they can potentially disable security policies, create backdoor accounts, or exfiltrate data at scale. Even roles like Exchange Admin or SharePoint Admin can be abused to read confidential communications or files.

For this reason, privileged identities require extra protection and oversight. These accounts typically have access to sensitive information and the ability to change configurations, so a single lapse can have outsized consequences. Real-world incidents have shown attackers specifically targeting IT administrators – for instance, by phishing MSPs or IT support providers – to then pivot into their client environments. In response, Microsoft and other security experts advocate a “hardened” approach to admin accounts, including strict MFA (ideally with phishing-resistant methods), device restrictions, and just-in-time access. We’ll outline concrete steps (like enabling phishing-resistant MFA policies for admins) in the next section.

Beyond the immediate IT staff, note that any user with elevated privileges or access to valuable data is a target. This could include global admins, but also roles like billing admins (who might access financial info), user account admins (who could create new accounts or reset passwords), or even C-level executives whose accounts often have access to sensitive business data. Attackers might start by compromising a low-level account via phishing, then request internal elevation (for example, using the compromised account to ask IT to reset an executive’s password, or sending consent links for malicious apps). Thus, protecting admin accounts is priority one, but don’t ignore other exposed users (like executives or finance managers) – they should also have strong MFA and monitoring due to the impact their compromise would have.

Microsoft 365 Countermeasures: Building an Identity Fortress

Thankfully, as attackers have evolved, so have the built-in defenses in Microsoft 365 (Azure AD / Entra ID). Singapore SMBs can leverage enterprise-grade security features in Microsoft’s ecosystem – often without needing any third-party product – to counter these identity threats. Below, we detail practical Microsoft 365 configurations and best practices (aligned with Microsoft Learn guidance and security best practices) to protect your organization:

1. Implement Phishing-Resistant MFA (FIDO2 Security Keys and Passkeys)

The most effective way to defeat MFA bypass schemes like AiTM phishing is to use authentication methods that are inherently phishing-resistant. Traditional one-time codes (from SMS or authenticator apps) can be stolen via proxy attacks, but modern standards like FIDO2 security keys and passkeys are immune to such interception. These methods use public/private key cryptography tied to the legitimate domain, so even if an attacker tricks a user into a fake site, the authentication won’t succeed because the key exchange is bound to the real domain (the phisher gets nothing of value). Microsoft has been championing passwordless, phishing-resistant tech – in fact, passkeys in Azure AD (Microsoft Entra ID) are now generally available, allowing users to login with a biometric or PIN backed by a FIDO2 key on their device.

For admins, Microsoft recommends requiring phishing-resistant MFA on all highly privileged roles. This means you might enforce a Conditional Access policy that only allows FIDO2 security keys, Windows Hello for Business, or certificate-based auth for your Global Admins and other critical accounts. If those users still need to set up these methods, Azure AD offers a feature called Temporary Access Pass to onboard them without a password. The key point is that phishing-resistant MFA (the strongest tier of authentication) should be the standard for admin accounts and eventually for all users as feasible. Azure AD’s authentication strength framework includes a built-in “Phishing-resistant MFA” level you can use in Conditional Access.

Consider starting with a pilot for FIDO2 security keys (which can be USB/NFC keys like YubiKeys or biometric keys) or enabling passwordless phone sign-in via Microsoft Authenticator – both are considered passwordless and MFA in one, and are resistant to replay. Passkeys (FIDO2 credentials stored in devices) are the next evolution, allowing users to sign in with Face/Touch ID or Windows Hello as easily as using a password, but with phishing-resistant security. By deploying these methods, you not only nullify AiTM-style attacks, you also improve user experience (no more typing codes). Microsoft is urging organizations to plan for a passkey rollout as a long-term strategy, and at minimum to prioritize phish-resistant MFA for privileged accounts immediately.

Practical tip: If your organization is using Microsoft 365 E3/Azure AD P1, you can’t explicitly require “phishing-resistant MFA” by policy (that feature is P2), but you can still enforce specific MFA methods. For example, you could create a policy requiring either passwordless Authenticator or FIDO2 for admin logins. If you have Azure AD P2 (or Microsoft 365 E5), you can leverage Authentication Strength policies to easily mandate “phishing-resistant MFA” for certain roles or apps. Always test these policies in report-only mode or with pilot users first to avoid lockouts.

2. Strengthen MFA for All Users – Enable Number Matching and Context

Even if you haven’t yet deployed full passwordless authentication for everyone, make sure the MFA you do use is configured as safely as possible. As discussed, MFA fatigue attacks prey on simple one-tap approvals. To mitigate this, ensure that Microsoft Authenticator push notifications have Number Matching enabled, and consider enabling additional context (so users see the sign-in location and application). Microsoft enabled number matching by default in May 2023 for tenants using Authenticator, specifically to counter MFA fatigue. When users sign in now, they will be prompted to enter a two-digit number displayed on the login screen into their Authenticator app, which “helps prevent users from falling for MFA fatigue attacks.”. This simple setting vastly reduces the likelihood that an employee will approve a rogue prompt, since the attacker would have to phish the code from them in real-time (highly unlikely if the user is aware).

If you haven’t already, you can enable number matching and display of geographic/app context in the Azure AD portal under Authentication Methods > Microsoft Authenticator settings. Also, educate your staff: they should be told that any unsolicited MFA prompt could be a sign of an attack, and to report it to IT security. Some organizations even adopt a “no MFA prompt goes uninvestigated” stance – if a user receives prompts they didn’t initiate, the associated account’s password is immediately reset as a precaution (since it likely means the password was compromised). Azure AD Identity Protection can help automate some of this by raising user risk when multiple denied MFA prompts occur, and even requiring a password change or blocking sign-in until remedied.

In summary, MFA remains a pillar of identity security – just make sure it’s configured in a modern, secure way. Use authenticator apps or FIDO2 rather than SMS/voice (which are less secure), enable anti-fatigue features like number match, and require MFA for all users, not just admins. Microsoft’s data shows MFA can block over 99.2% of identity attacks when deployed thoroughly, so extending MFA tenant-wide is one of the best defenses you have.

3. Enforce Conditional Access Policies for Layered Defense

Conditional Access is your “Swiss army knife” for enforcing granular access controls in Azure AD. It evaluates sign-in conditions (user role, location, device compliance, risk level, etc.) and can block or challenge logins that don’t meet your criteria. If you have Azure AD Premium (included in Microsoft 365 Business Premium, E3, E5, etc.), you should use Conditional Access to go beyond the basics. Key policies to consider in the context of recent threats:

• Require MFA for Admins and Sensitive Roles: Build a policy targeting all accounts in admin roles (Global Admin, Exchange Admin, etc.) to always require MFA (or specifically phishing-resistant MFA as noted) for interactive logins. This ensures that even if an admin’s password is known, an attacker can’t use it without the second factor. (With PIM, you can also require MFA on every role activation – more on PIM below.)
• Block Legacy Authentication: Legacy protocols (POP/IMAP/SMTP using basic auth, older Office clients, etc.) cannot enforce MFA and are frequently abused by attackers. In fact, “most compromising sign-in attempts come from legacy authentication” according to Microsoft. Create a Conditional Access policy to block all legacy authentication for all users. Microsoft’s security defaults do this by default, but if you are off security defaults, you need to implement it in CA. (Note: Basic auth for Exchange Online was disabled by Microsoft in 2022 for most tenants, but it’s good to have a CA policy as backup and to cover other protocols or re-enabled situations.)
• Require Compliance or Trusted Devices for Admin Access: Consider limiting admin accounts so they can only log in from Azure AD Hybrid joined or Intune compliant devices. This way, even if an attacker steals an admin’s credentials and tries to use them from an unknown device, access will be blocked. Privileged accounts should ideally not be used from personal or non-managed devices. A CA policy can enforce that (e.g., require device to be marked compliant for admin apps or tasks).
• Location-Based Policies: If your business is largely in Singapore and users rarely need to log in from other regions, you can use location conditions. For instance, you might block sign-ins originating from countries where you don’t do business (common threat locales) – or at least flag them for additional MFA. Also, for highly privileged accounts, you might restrict interactive login to only your office IPs or a VPN. Be careful to also exclude your emergency access accounts from these restrictions (discussed later).
• Risk-Based Policies (Identity Protection): If you have Azure AD P2 or Microsoft 365 E5, turn on user risk and sign-in risk policies. These use Microsoft’s machine learning to detect things like leaked credentials or atypical sign-in patterns. For example, it can auto-block or force password reset if an account is marked at high risk. Importantly, risk detection can help against token replay – Microsoft Entra ID (Azure AD) Identity Protection can flag anomalous token usage (like impossible travel or unfamiliar device for a cookie) which is exactly what happens in token theft scenarios. A policy could then block that sign-in or require re-authentication.

Think of Conditional Access as enforcing your Zero Trust rules: never trust a login just because credentials are correct – add other checks. Microsoft recommends using CA to “evaluate sign-in requests using additional identity-driven signals” like device, location, etc., to mitigate token replay and session hijacking attempts common in AiTM phishing. In practice, this might mean that even if an attacker steals a session cookie, if they try to use it from a new location or device, a CA policy forcing reauthentication or blocking unfamiliar contexts can stop them from getting in.

Finally, don’t forget to exclude your emergency break-glass accounts from CA policies (we cover these accounts below). Also exclude any service accounts that can’t do MFA. Test CA changes in Report-Only mode to see impacts before enforcing – the goal is to strengthen security without accidentally locking out legitimate users.

4. Use Security Defaults if Conditional Access is Unavailable

For smaller organizations that may not have an Azure AD Premium license, Microsoft provides Security Defaults – a one-click baseline of preconfigured security policies. Security Defaults will require all users to register for MFA, force admins to do MFA every time, block legacy authentication, and protect privileged activities by requiring extra authentication. It’s an excellent starting point if you have no custom policies. Microsoft enables Security Defaults by default on new tenants, because these basic controls drastically improve security at no cost (remember that stat: 99.9% of common identity attacks are stopped by MFA + disabling legacy auth). If you’re an SMB on Microsoft 365 Business Standard or other plans without Conditional Access, make sure Security Defaults are turned on in Azure AD.

However, if you have the ability to use Conditional Access (Azure AD P1/P2), Microsoft advises that Security Defaults may not be appropriate. Medium-to-large businesses with more complex requirements will want the flexibility of custom CA policies. In such cases, you typically disable Security Defaults and implement your tailored CA policies as discussed above. Just ensure you replicate the baseline protections: MFA for all users, MFA every login for admins, no legacy auth, etc., via your CA rules. The advantage is you can then layer more conditions (like device compliance, specific app control, or differing rules for groups).

In summary – Security Defaults is the “easy button” to secure identities for SMBs unsure where to start, and it aligns to best practices (MFA everywhere). But as you grow, graduating to Conditional Access gives you much more control. Either way, some form of baseline identity security must be in place. If you do nothing else, ensure MFA is enforced and legacy auth is blocked tenant-wide – those two steps alone mitigate the majority of opportunistic attacks.

5. Limit and Protect Privileged Accounts (Just-in-Time Admin Access)

Following the principle of least privilege, your Microsoft 365 tenant should have only a small number of permanent Global Administrators, and ideally no one should use those high-power accounts for day-to-day work like email or browsing. Microsoft recommends having separate accounts for administrative tasks vs. regular use. For example, an IT manager might have a normal user account for email/Teams, and a second account that is a Global Admin to be used only when needed. This reduces exposure (e.g., that admin account isn’t reading email where it could get phished).

Moreover, consider using Role-Based Access Control (RBAC) to distribute admin responsibilities in a granular way. Instead of everyone being Global Admin, assign more limited roles (Exchange Admin, User Admin, Teams Admin, etc.) as appropriate. This way, compromising one admin account doesn’t automatically mean total control of everything – the blast radius is smaller. Regularly audit who has admin roles and remove any unnecessary or dormant admin accounts. In an SMB with ~200 employees, you might have, say, 2 Global Admins, a couple of billing/admin roles, and maybe a Service Support admin. You definitely don’t want dozens of Global Admins – that only increases the target surface.

A powerful tool to manage privileged roles is Azure AD Privileged Identity Management (PIM). PIM (available with Azure AD P2 or Microsoft 365 E5) allows you to make admin roles “eligible” instead of permanently active. In practice, an IT staff member can be eligible for Global Admin, but not have those privileges until they activate them – which can require MFA and time-limit the access (say, 4 hours). This is essentially Just-in-Time (JIT) administration. PIM also provides workflow (you can require approval for role activation), audit logs of all activations, and even alerts if someone activates out of hours. By using PIM, you greatly reduce the window in which an attacker could abuse an admin account. Even if an admin’s credentials are stolen, the attacker might not realize the account has no active roles unless they go through the PIM activation (which would trigger MFA and likely an email to the real admin). Microsoft’s guidance is to use PIM for all administrative roles to lower the exposure duration of privileges.

If PIM is not an option, at least implement a routine process to revoke standing privileged roles that aren’t needed. For instance, some organizations do a weekly or monthly review of admin roles, and remove any that look unnecessary. Azure AD also now has an access reviews feature (P2) which can automate asking role holders to justify their access periodically.

Summary of privileged access best practices:

• Minimize Global Admins (use less-powerful roles wherever possible).
• Use separate admin accounts that are only used for admin tasks, not everyday work.
• Enable PIM for JIT elevation and auditing of admin roles.
• Require MFA on all admin accounts (we’ve said it before, but it can’t be overstated).
• Monitor admin activities – at 200+ users, it might be feasible to regularly check sign-in logs or set up alerts (Azure AD can send alerts for unusual admin sign-in patterns or if someone grants a new admin role).

By limiting who can be an admin and for how long, you shrink the bullseye that attackers are aiming for, and you make it more likely that any breach of a privileged account can be contained.

6. Maintain Emergency Access Accounts

Imagine you roll out strong Conditional Access policies – then a misconfiguration locks out all your admins (yes, it happens). To avoid an “all admins locked out” scenario, Microsoft recommends having at least two emergency access accounts (sometimes called “break-glass” accounts). These accounts are highly privileged (Global Admin) accounts that are kept outside of normal use, and crucially, are exempted from Conditional Access and MFA requirements. They are only to be used when normal admin access is lost (for instance, if a CA policy misfires or a widespread MFA outage occurs).

For a Singapore SMB, you might keep two break-glass accounts with extremely long, complex passwords (stored securely offline). These accounts should not be tied to any individual’s phone or email – use a dedicated email that admins know to check if needed (or no email at all). Exclude these accounts from all Conditional Access policies and do NOT require MFA on them (since the whole point is they work when MFA might be down). Monitor them closely – no one should be logging in with them unless it’s an emergency. Azure AD will log when these accounts are used; consider an alert if they ever sign in.

Emergency accounts ensure that even if your strict policies lock out every other admin, you can still get back in to fix the issue. They are a safety net. However, because they are so powerful and not protected by MFA, treat them like nuclear codes: protect the credentials rigorously. Some best practices include: use a password manager or sealed envelope in a safe for the creds, set the passwords to something on the order of 30+ characters, and log sign-in attempts. Rotate these passwords periodically (and test that you can log in with them).

Finally, never use the emergency accounts for routine admin work. They should have zero licenses and mailbox access to reduce risk (you don’t want them receiving email that could phish them). If you have a break-glass account with an email, do not use that email to sign up for any services or communications. The philosophy is: these accounts exist purely to rescue your tenant in dire situations.

7. Leverage Microsoft Defender for Office 365 (Advanced Threat Protection)

Thus far we’ve focused on identity and access, but remember that many attacks start with a phishing email. This is where Microsoft Defender for Office 365 (Plan 1 or 2) plays a vital role. Defender for Office 365 provides anti-phishing, anti-spam, and anti-malware filtering beyond the standard Exchange Online Protection, using features like Safe Links (URL rewriting and time-of-click scanning), Safe Attachments (sandboxing email attachments), and machine learning to detect phish that evade traditional filters. For example, AiTM phishing links might be uniquely generated per target – Defender for O365’s heuristic and ML algorithms can often catch these, or at least detonate the content if clicked. Microsoft notes that Defender for Office 365 (along with Exchange Online Protection) is designed to be the frontline defense to “ensure your organization has established essential defenses” at the email gateway.

As an IT leader, you should review and configure your anti-phishing policies in the Security portal. By default, the system has a standard policy, but you can tune it – enabling features like user impersonation protection (so emails that look like your CEO but aren’t really from their account get flagged), adjusting the thresholds, and specifying custom allowed/block lists. Make sure Safe Links and Safe Attachments are enabled for all users (these are part of Defender for O365 Plan 1/2). Safe Links, in particular, can neutralize a phishing URL by dynamically analyzing it when clicked and blocking access if it’s malicious. Microsoft even suggests applying Safe Links to internal emails as well, to help catch things like compromised account scenarios where a phish comes from an internal address.

Another useful feature is Attack Simulation Training in Defender for Office 365 Plan 2. It allows you to run internal phishing simulations and identify users who might be prone to clicking, then automatically assign training to them. Given that user awareness is part of the solution, this can be a good investment for ongoing security culture-building.

In short, configure Defender for Office 365 to its fullest: turn on anti-phishing policies, enable impersonation protection, apply Safe Links to all applicable channels (email, Teams), and use Safe Attachments for malware scanning. Combined with user education, this will reduce the likelihood of that initial phish email ever reaching your employees’ inboxes. And if it does get through and someone clicks, Defender’s URL detonation might still save the day. Microsoft’s recommended best practices for Exchange Online and Defender for O365 settings are a great reference – ensure you’re aligned with those guidelines.

Note: Defender for Office 365 is an add-on (or included in certain licenses like Office 365 E5 or Microsoft 365 Business Premium). If you don’t have it, at least maximize Exchange Online Protection (EOP) defaults, and consider third-party email security if needed. But the tight integration of Defender for O365 with the rest of Microsoft 365 (and features like Attack Simulator) make it a strong choice for SMBs that rely on Microsoft’s ecosystem.

8. Deploy Privileged Access Workstations (Secure Admin Devices)

To further protect your highest-impact accounts (admins, and perhaps sensitive users like finance), consider the physical environment where those accounts are used. A concept called Privileged Access Workstations (PAW), advocated by Microsoft, involves having a dedicated, locked-down machine for administrative tasks. The idea is to isolate admin operations from everyday web browsing and email, which are higher risk activities. If an administrator only logs into Azure AD or the Microsoft 365 admin center from a secured workstation (that is hardened, fully patched, runs up-to-date AV, and isn’t used for reading random emails or internet surfing), the risk of token theft via malware or of a phish on that machine is greatly reduced.

In other words, a PAW gives you confidence that when admin creds are used, they’re used on a trusted device that’s less likely to be compromised. In practice, for a small or mid-sized business, a PAW could be as simple as a separate laptop (with a very locked down configuration) that admins use only for admin duties. It could run a stripped-down Windows image with Group Policies or Intune policies preventing installation of unauthorized software, with SRP or WDAC app control, etc., and with administrative web portals bookmarked (and perhaps only those allowed). The PAW device itself should have a dedicated admin account that’s separate from the normal corporate user account.

If maintaining a separate physical machine for each admin is too burdensome, alternatives include using a secure virtual machine or Azure Virtual Desktop that is hardened and used for admin access. The key is to ensure that the device from which privileged credentials are used is much more secure than a general user’s PC. At minimum, enforce that admin accounts can only log in from domain-joined or compliant devices (as mentioned in Conditional Access above) – effectively that is a light form of PAW requirement.

For organizations managing on-premises AD as well, Microsoft’s ESAE (“red forest”) model heavily emphasizes PAWs for domain admin tasks. Even cloud-only SMBs can benefit from the concept: If your Global Admin only ever logs in from a clean, well-guarded environment, it’s a lot harder for an attacker to steal those credentials. As one example, an admin could keep a separate browser profile or use a different OS (like a Linux Live USB or a hardened Windows install) that is only for admin work. The inconvenience is minor compared to the security gain.

In summary, treat your admin workstations like high-security vaults. Use them for admin access and nothing else. Apply all hardening best practices (block internet access to unneeded sites, disable email access, enforce device compliance). Microsoft’s security roadmap for privileged access suggests “deploy Privileged Access Workstations for all administrators” as a critical step – this is particularly relevant if you administer not just cloud but also servers, etc. For a cloud-only SMB, the principle still holds: keep your admin access segregated and shielded from everyday threats.

---

By implementing the measures above, you create multiple layers of defense around your Microsoft 365 identities. No single solution is 100% foolproof, but in combination – phishing-resistant MFA, strict Conditional Access, minimal privilege, vigilant monitoring, and robust email filtering – you dramatically raise the bar for attackers. It’s about making your organization a hard target, so that hackers move on or, if they do try, you have traps and alarms to catch them.

Step-by-Step Security Checklist for Microsoft 365 (Singapore SMB Edition)

Finally, to help you put these recommendations into action, here’s a concise security checklist tailored for SMBs managing Microsoft 365 in Singapore. Use this as a roadmap to strengthen your identity security:

1. Enable MFA for All Users: Ensure every user in Microsoft 365 is enrolled in MFA. Use Microsoft Authenticator or other app instead of SMS where possible. (Tip: If you have no Conditional Access, turn on Azure AD Security Defaults to enforce MFA across the board.)
2. Implement Phishing-Resistant MFA for Admins: Require stronger authentication for Global Admins and other privileged roles. Deploy FIDO2 security keys or passwordless phone sign-in for these accounts. At minimum, enforce number matching in Authenticator for everyone to counter MFA fatigue.
3. Block Legacy Authentication Protocols: Use Conditional Access or Security Defaults to disable legacy auth (POP/IMAP/SMTP basic, older Office clients) tenant-wide. This closes a huge loophole that bypasses MFA.
4. Deploy Conditional Access Policies: If licensed (Azure AD Premium):
   • Require MFA on every login for admins and other critical users.
   • Restrict admin logins to compliant (Intune-managed) or specific devices.
   • Block or challenge risky sign-ins (consider Azure AD Identity Protection to auto-block unfamiliar locations or impossible travel).
   • Limit access from foreign countries if not needed (e.g., block sign-ins from outside Singapore/ASEAN as appropriate).
5. Use Privileged Identity Management (PIM) for JIT Access: If available, enable Azure AD PIM for admin roles. Make admins “eligible” and require activation (with MFA) for a limited time when they need it. This reduces standing privileged access.
6. Minimize and Monitor Privileged Accounts: Audit who has admin roles in M365. Reduce Global Admin count to the bare minimum (2-4 individuals at most for ~200 users). Remove unused roles. Set up alerts for changes to role assignments.
7. Create Two Emergency Access Accounts: Set up two Global Admin accounts solely for break-glass emergencies. Exclude them from Conditional Access policies and MFA requirements. Secure their credentials (long random passwords, stored offline). Do not use these accounts except for disaster recovery.
8. Configure Microsoft Defender for Office 365 (Plan 1/2): If you have Business Premium or Office 365 E5 (or as an add-on), ensure anti-phishing policies are tuned (enable impersonation protection, etc.). Activate Safe Links and Safe Attachments for all users. Consider enabling Defender’s preset Security policies to apply best-practice settings. Regularly review quarantine and logs for phish attempts.
9. Enable Mailbox Intelligence and Other Advanced Threat Protections: Utilize features like Mailbox Intelligence and Spoof filtering in anti-phishing policies (these help detect emails that look unusual for the recipient). Also, turn on Attack Simulation Training in Defender for O365 Plan 2 to run phishing drills and educate users.
10. Establish Privileged Access Workstations (PAWs): Designate or build secure admin workstations for IT staff. These should be tightly locked down and used only for admin tasks. Enforce that admin accounts do not sign in from regular user devices. If a dedicated machine per admin is not feasible, use a secure VM or Azure Virtual Desktop session for admin work.
11. Apply Least Privilege in All Services: Beyond Azure AD roles, check admin roles in Exchange, SharePoint, Teams, etc. (via the Microsoft 365 admin center). Ensure people only have the roles needed for their job. Remove global access where a smaller scope role exists (e.g., someone who just manages Teams shouldn’t be a Global Admin).
12. Enable Azure AD Audit Logs and Monitoring: Make sure Azure AD sign-in logs and audit logs are being retained and monitored. Even on a P1 license, you get basic logging – review it for unusual login locations or multiple failed MFA attempts (which could signal an attack). If possible, integrate logs with a SIEM or at least regularly export them for analysis.
13. Educate and Phish-Test Your Users: Train employees about modern phishing (links can look identical to Microsoft pages, attacks may steal tokens, etc.). Conduct periodic phishing email simulations to keep awareness up. Emphasize to never approve MFA requests they didn’t initiate. This human element is part of a strong defense-in-depth.
14. Stay Updated on Security Features: Microsoft continuously updates Azure AD and Office 365 security capabilities (for example, new policy settings, or improvements like continuous access evaluation). Follow the Microsoft Tech Community blogs or product updates relevant to identity security. For instance, features like token protection (tying tokens to device) are emerging to combat token theft – keep an eye on these for future adoption.
15. Regularly Review Your Secure Score: Microsoft Secure Score in the security center gives a snapshot of your tenant’s security posture and recommendations. While not all suggestions may apply, it’s a good baseline to check if you missed something obvious (like enabling MFA for all admins, which is a Secure Score item). Treat it as a guided to-do list for incremental improvements.

By following this checklist, Singapore SMBs can significantly harden their Microsoft 365 environments against the most common and advanced identity attacks. Cyber threats will continue to evolve – from AiTM phishing to AI-fueled password cracking – but with a proactive, layered approach grounded in Microsoft’s best practices, you can stay one step ahead. Remember that security is an ongoing process: keep fine-tuning your policies, educate your users, and leverage Microsoft’s security ecosystem (which is built to address exactly these challenges). With vigilance and the right configurations in place, even a lean IT team can defend successfully against attacks that bypass traditional defenses.

Stay safe, stay updated, and prioritize identity security – it’s your strongest shield against the modern threats targeting our increasingly cloud-based workplaces.