Cloud security: the most common misconfigurations in Microsoft 365

2026-08-07 · by SECURITYSQUAD

"Moving to the cloud" sounds like a security gain, and it can be one. The catch: the provider secures the platform, but you are responsible for configuring your own environment. This shared model is regularly misunderstood, and the result is gaps that have nothing to do with the cloud itself and everything to do with its settings.

What Microsoft secures – and what it does not

| Microsoft | You | |---|---| | Data centres, hardware, hypervisor | Who holds which permissions | | Availability of the services | Which sign-in methods apply | | Patching the platform | Sharing and data outflow | | Baseline defence at platform level | Logging, evaluation, response | | | Backing up your data |

The last point surprises people most often. Microsoft protects you against its own data loss, not against yours: a user who empties a mailbox, or an attacker who encrypts files, is your problem. Recycle bin retention is not a backup.

The classic: missing multi-factor authentication – now with a deadline

The most common finding in our cloud assessments is both banal and dangerous: accounts that sign in with a username and password alone. One leaked password is enough.

Microsoft has stepped in here itself and now enforces MFA in stages:

From October 2024 for the Azure portal, Entra admin center and Intune admin center.
From February 2025 for the Microsoft 365 admin center.
From 1 October 2025 for Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools and REST endpoints – for write operations only; reads remain exempt.

Important for anyone who used the deferral: the postponement option for phase 2 ended on 1 July 2026. There is no opt-out.

The three pitfalls in this

User accounts acting as service accounts. Genuine workload identities – managed identities and service principals – are not affected by the requirement. A user account running a script overnight very much is. Those accounts break first, and by then nobody remembers what they belong to. Find them before they find you.

Scripts using username and password. The ROPC sign-in flow is fundamentally incompatible with MFA. Automation that authenticates this way will fail, no matter how good the password is.

Break-glass accounts. Emergency access accounts need MFA too. Microsoft recommends FIDO2 passkeys or certificate-based authentication; both satisfy the requirement without depending on a phone.

Too many permissions, checked too rarely

Permissions grow over time. Roles get assigned and rarely withdrawn, and in the end there are more global administrators than anyone would have guessed.

Three questions you can answer this week:

How many global administrators are there? More than a handful is almost always too many.
Are those rights assigned permanently, or activated on demand?
Are there highly privileged accounts that have not signed in for months?

Sharing that reaches further than intended

Documents in Microsoft 365 can be shared in a couple of clicks – externally too, and anonymously via a link that can be forwarded to anyone. Convenient, and quickly a data protection problem.

What makes sense is a default that does not offer anonymous links as the first option, an expiry date on external shares, and a regular report of what is currently shared outside. That last one is usually the most uncomfortable part of a first assessment.

Logs nobody keeps

Most environments ship with far more protection than is switched on: logging, alerts on suspicious sign-ins, inspection of attachments and links. Much of it lies idle.

With logging it is not only about switching it on but about retention. If an incident surfaces after the typical dwell time of about two weeks – and for espionage cases it takes far longer – you need logs reaching further back than the default. Discovering that during an incident means you can no longer reconstruct what happened.

That is why Entra ID sign-in logs and the unified audit log belong in a central evaluation, for instance a managed SIEM.

Legacy authentication

Old protocols without support for a second factor are the most convenient way to bypass MFA. Check whether such methods are still permitted in your tenant and whether they are still used – the sign-in logs will tell you. Usually exactly one old multifunction printer or line-of-business application hangs off them.

What you can do this week

Check and reduce the number of global administrators
Search for user accounts running as service accounts
Produce a list of external shares
Check log retention
Look at the tenant's Secure Score – not as a target, but as a map

Setting it up right once is not enough

Configurations drift, new features arrive with their own defaults, settings change with updates. An assessment gives clarity on the current state; only a recurring comparison keeps the environment from slowly sliding. The CIS Benchmarks exist for Microsoft 365 as well – they supply the testable target state for exactly this.

As at August 2026. MFA details per the Microsoft documentation "Plan for mandatory Microsoft Entra multifactor authentication".