Have you made sure that your Microsoft 365 security setup keeps hackers out?
Cybersecurity Tools in M365 Are Vast – But There’s a Catch
What Do Other Security Risks Look Like in Practice?
Why Does It Matter – the Recap
How Can You Stay In Control of M365 Cybersecurity?
Download Our Interactive Guide
Contrary to popular belief, a Microsoft 365 (M365) environment is not necessarily secured because you’ve enabled Multi-Factor Authentication (MFA) or you’ve hit a good Secure Score. They are just part of the puzzle and misconfigurations and oversights are far more common than you’d think. A false sense of security results in overconfidence in your cybersecurity setup which can, unfortunately, also be your downfall.
While you have vast controls over your security setup in M365, the default configuration is unsafe—think admin accounts without MFA, audit logs disabled or legacy authentication still in place. It’s like closing the window but not locking your front door.
Real-world risk is hidden in the detail. Your Secure Score is merely a useful hygiene checklist, aiming at low-hanging fruit, as the scoring engine is weighted towards “checkbox” settings. What you should be considering is the broader kill-chain, the human element and operational readiness. Ask yourself the question: Can an attacker still phish, move laterally, escalate and persist if every Secure Score recommendation is green? If the honest answer is “yes”, it’s high time for you to look at your configuration in detail.
Microsoft research shows MFA can stop 99.2% of account compromise attacks. Especially for admins - who have power over security settings in M365 - enabling MFA is absolutely crucial to keep their accounts safe from cybercriminals. However, blanket grant controls such as ‘Require MFA’ lead to excessive MFA prompts, and “approve-all” behaviour. Instead, create Conditional Access policies (Microsoft Entra ID P1 or P2) that only require/ trigger MFA prompts once specific conditions are met.
You should always apply the principle of least privilege. Do not include emergency access or break-glass accounts in Conditional Access policies in case you misconfigure a policy. Why? If all your administrators happened to be locked out, these accounts will help you to regain access.
The benefit of Conditional Access policies lies in their granularity. If you leave rules to broad, any misconfiguration will also hit everyone at once. Practically speaking, you’re in a riskier situation even for roll-back because you may have to disable the policy entirely. If you leave conditions at their default (think any location, any platform, any client app, any device state), your policy doesn’t distinguish between trusted and high risk context. As a consequence, a threat actor could sign in from Tor - a browser designed to provide anonymity and privacy - or a ransomware-infected device and would be treated the same as a managed laptop on the corporate network. On the other hand, you waste licences and unnecessary MFA prompts in low-risk scenarios, which can irritate users and encourage MFA fatigue. While a blanked MFA approach may pass the audit, users may turn to auto-approve MFA which benefits hackers who are trying to bypass MFA prompts. Access should always be role based.
Audit logs are crucial for compliance and business purposes, as it documents all activity within Azure/M365 across your organisation such as event names, their description, the time, who created it from where etc. They’re a crucial tool to track user activity for safety purposes and helps security team investigate breaches.
Everyone is in “Global Admin” or “SharePoint Admin” rather than a narrowly scoped role (e.g. “Exchange Recipient Admin” or “Teams Communications Admin”).
Third-party or custom apps are allowed full read and write access instead of least-privilege scopes.
A security group that grants access to sensitive SharePoint or Exchange resources contains other groups whose membership isn’t regularly audited.
Sites or Teams default to “everyone except external users” as owners or members, meaning every new hire or contractor immediately gains site-owner privileges.
Service accounts, automation scripts or ex-employees still carry Exchange, Teams or Intune admin licences long after they should have been decommissioned.
The truth is, cybercriminals don’t need new vulnerabilities Microsoft will patch with the next update to entice them to attack. While these do pose a risk, threat actors will simply exploit anything that’s been left open. Most successful breaches happen despite tools (albeit misconfigured) being in place.
We recommend that you
Your M365 security posture isn’t about what you have, but how you’ve set it up. Download our guide containing the most important aspects - including video tutorials - below.