Microsoft 365 Is Secure by Default — But Not by Configuration

Most organisations we assess in the UAE and wider GCC assume that moving to Microsoft 365 moved their security problem to Microsoft. It moved part of it. Microsoft secures the platform; you remain responsible for identity, access, data and configuration. That split is where most incidents begin.

Below are the four configuration gaps we find most often, and what to do about each.

1. Multi-factor authentication is enabled, but not enforced

Enabling MFA per user is not the same as enforcing it. We routinely find tenants where MFA is switched on for most staff, while service accounts, contractors and senior executives sit outside the policy — usually because an exception was made during rollout and never revisited.

Use Conditional Access to require MFA for all users, then add narrow, documented exclusions with an expiry date. Disable legacy authentication protocols at the same time; they bypass MFA entirely and remain one of the most reliable routes into a tenant.

2. Global Administrator accounts are used for daily work

It is common to find five or more standing Global Administrators in a tenant of fifty people, several of them used for email and browsing. Every one of those sessions is a high-value target.

Reduce standing Global Admins to two break-glass accounts, excluded from Conditional Access, stored offline and monitored for use. Give administrators separate accounts for privileged work, and assign the narrowest role that does the job — Exchange Administrator or User Administrator rather than Global Administrator.

3. Sharing defaults are wider than anyone intended

SharePoint and OneDrive ship with permissive sharing so that collaboration works out of the box. Left untouched, that often means any user can create anonymous links to any document, with no expiry.

Set organisation-level sharing to authenticated guests rather than anyone, apply an expiry to guest links, and review external sharing reports monthly. Where you handle regulated or client-confidential material, apply sensitivity labels so protection travels with the file rather than depending on where it is stored.

4. Nobody is reading the audit log

Microsoft 365 records a great deal — impossible-travel sign-ins, new mailbox forwarding rules, mass downloads, consent grants to third-party applications. Retention is limited by licence, and none of it helps if no one is alerted.

Confirm unified audit logging is on, create alert policies for the handful of events that genuinely indicate compromise, and route them somewhere a person actually looks. Mailbox forwarding to external addresses is the single highest-value alert to configure first — it is the most common way data leaves quietly after an account takeover.

Where to start

None of the above requires new licensing in most tenants, and all of it can be done in a short, focused engagement. If you want a starting point, check your Microsoft Secure Score, then work through the four areas here in order — identity first, privilege second, data third, monitoring fourth. That sequence closes the widest gaps soonest.

One more default is worth checking while you are in the tenant. Unless custom DKIM has been enabled for your domain, Microsoft 365 signs outbound mail as yourtenant.onmicrosoft.com. The signature verifies, but it does not belong to the domain your recipients actually see, so it fails DMARC alignment and leaves your domain easier to spoof than it looks. We explain that distinction, and how to fix it, in DMARC alignment: strict vs. relaxed.

If you would like an independent review of your Microsoft 365 configuration, get in touch and we will walk through it with you.

Share this article

1 thought on “Microsoft 365 Is Secure by Default — But Not by Configuration”

  1. Pingback: DMARC Alignment Explained: Strict vs. Relaxed Alignment - Shielded Networks

Comments are closed.