The settings that quietly weaken a Microsoft 365 tenant are rarely the ones that show up at first glance. They do not trigger alerts. They do not show up in a weekly digest. They build up during a rushed deployment or arrive with an inherited configuration, and they persist because nobody on the team thinks to look.
This article walks through seven of the most common. Each one covers why it matters, what it looks like in the tenant, and what good actually means.
Legacy authentication that never got turned off
Legacy authentication covers clients and protocols that cannot complete a modern authentication flow: older mail protocols such as IMAP and POP3, SMTP AUTH, and Office clients too old to handle a multi-factor challenge. Microsoft has deprecated Basic Authentication for most Exchange Online protocols, but SMTP AUTH and certain client paths can still be re-enabled or left active, and other workloads carry their own legacy surfaces. Where any of these remain available, an attacker can attempt credential-based access without ever meeting a Conditional Access policy or an MFA prompt.
The specific risk is that a valid username and password is all that is required. If a credential turns up in a breach dump, or is found through password spray, a legacy path offers a side door around the identity controls you rely on everywhere else.
The observable indicators are straightforward: sign-in logs showing successful authentications with legacy client strings, or the absence of a Conditional Access policy that blocks legacy authentication across all users. Both are visible in Entra ID. Neither needs a third-party tool to find, but they are often missed because the logs are not reviewed regularly.
For organisations working towards Cyber Essentials, this maps to the expectation that access to services is properly controlled. A legacy authentication path that cannot enforce MFA is one of the clearest gaps against that expectation.
MFA gaps in administrative roles
Most organisations have MFA enabled at some level. The gap is usually not whether MFA exists, it is whether it is enforced consistently for accounts that hold administrative roles.
This surfaces in a few ways. A Global Administrator account created during initial setup may predate the MFA policy. A service account used for admin tasks may have been excluded from Conditional Access to stop a workflow breaking. A third-party integration may have been granted an admin role as a workaround that nobody revisited.
The problem in every case is the same. A compromised administrative account can modify the MFA configuration, remove Conditional Access policies, and consent to applications. The blast radius of one unprotected admin account is far larger than a standard user account.
Checking this means reading role assignments in Entra ID and cross-referencing them against Conditional Access inclusions and exclusions. Pay particular attention to accounts excluded from policy "temporarily" months or years ago.
See how ScanPosture maps MFA coverage across role assignments.
Conditional Access policies with broad exclusions
A Conditional Access policy that excludes a large group, all guest accounts, all service accounts, or all legacy clients is often protecting far less than the person who built it intended. Exclusions usually go in for legitimate reasons: a service broke, a rollout needed phasing, or a workflow could not complete under the new conditions. The exclusion goes on, the workflow resumes, and the exclusion stays.
Over time, exclusions grow and real coverage shrinks. The distance between what the policy says and what it enforces becomes significant.
The useful question is not whether a policy exists, but what share of your sign-in traffic it actually covers. An excluded group holding 30 per cent of your user base is a meaningful gap, not a footnote.
This also relates to the Cyber Essentials expectation that access controls apply consistently. Broad exclusions are one of the most common reasons controls look complete on paper while leaving practical gaps in operation.
Service principals and consented apps with high-permission grants
Every application connecting to your tenant through an Entra ID app registration or service principal represents a trust decision. Some were made deliberately, reviewed, and are well understood. Many were made quickly, or by a user clicking accept on an OAuth consent prompt.
It helps to be precise about the two kinds of consent. Delegated permissions act on behalf of the signed-in user and are limited to what that user can already do. Application permissions act as the app itself, with no user in the loop, and can reach broadly across the tenant. Admin consent applies a grant on behalf of the organisation rather than a single user, which is why an application permission such as Mail.ReadWrite or Files.ReadWrite.All, once admin-consented, can read and modify content across mailboxes and OneDrive without any further prompt.
Those grants persist until someone reviews and revokes them. Reviewing the service principal and app consent inventory is rarely on a defined schedule. It tends to happen reactively, after an incident or a review. Doing it proactively is straightforward, because the data is all in Entra ID.
Guest access without expiry or review
External collaboration in Microsoft 365 is useful and widely used. Guest accounts let external parties reach Teams channels, SharePoint sites, and shared files without a full licence. The operational problem is that guest accounts are rarely deprovisioned once the collaboration ends.
A guest account created for a project two years ago may still hold active access to a SharePoint site or Teams channel. The external user may have changed roles, changed employers, or simply have no further reason to hold it. Without a review process, the account just sits there.
This is an access control issue, not only housekeeping. A guest account that is no longer needed is an access path with no remaining business justification. If those credentials are compromised, the attacker inherits whatever the guest account could reach.
Entra ID supports access reviews for guest accounts. The questions worth asking are whether yours are configured, whether they run on a defined schedule, and whether reviewers actually complete them. Plenty of organisations have reviews configured but find completion rates low because the process is inconvenient or the notifications go unnoticed.
Unrestricted external sharing in SharePoint and OneDrive
SharePoint and OneDrive sharing operates at two levels. The tenant level sets the most permissive boundary, and the site level can be more restrictive but never more permissive than the tenant. When the tenant setting allows sharing with anyone through an anonymous link, every site inherits that as a possible option unless a site-level restriction overrides it.
The practical consequence is that a user creating a site or uploading a document can, by default, generate a link that works for anyone who holds it, with or without an account in your tenant. That link does not expire unless you configure expiry, and it can be forwarded.
Most IT managers know anonymous sharing exists. The real questions are whether they know the current tenant setting, which sites have such links active, and whether any limit applies to how long those links stay valid. The honest answers are often not certain, no, and none.
This sits against the Cyber Essentials expectation that access to data is restricted to those with a legitimate need. Anonymous links with no expiry pull directly against that.
Privileged roles assigned directly rather than through PIM
Permanent role assignment means an account holding Global Administrator, Exchange Administrator, or another privileged role keeps that role at all times, whether or not it is performing a task that needs it. Just-in-time access through Entra ID Privileged Identity Management activates the role for a defined window and lets it expire automatically.
The difference matters because permanent assignment creates standing high-value targets. A compromised account that permanently holds a privileged role gives an attacker continuous elevated access. An account that has to activate through PIM gives an attacker far less, and adds an activation step that can be monitored, alerted on, or gated behind justification.
PIM is part of Microsoft Entra ID P2. Licensing and entitlement vary by agreement type and bundled SKU, so confirm what is available in your own tenant before relying on a specific control. Where P2 is present, many organisations have never configured PIM. The capability is there; the control is not in use.
Understand how ScanPosture surfaces permanent role assignments and PIM configuration gaps.
What to do with this
None of these seven issues needs specialist tooling to identify. The data lives in Entra ID, the Microsoft 365 admin centre, and the sign-in and audit logs. The difficulty is not finding it once you know to look. The difficulty is building a regular process that surfaces these conditions before they become a problem, and tracking whether they are improving or drifting over time.
If you want to see where your tenant stands across these areas, ScanPosture produces a structured findings report against your Microsoft 365 and Entra ID configuration, including mapped technical alignment to Cyber Essentials readiness criteria. It shows what is observable now, what has drifted, and what is worth prioritising.
ScanPosture shows alignment and readiness against selected technical controls related to this model. It does not itself certify compliance or replace formal assessment, certification, or legal advice.
