How to tell if your Microsoft 365 is misconfigured: 15 risk signs that often go unnoticed

Quick summary: 15 signs that Microsoft 365 may be misconfigured

1. Low or ignored Secure Score: critical recommendations remain unreviewed or have no owner.
2. Too many global administrators: more privileges than necessary increase the impact of a compromised account.
3. Incomplete MFA: some users or administrators can still sign in with only a password.
4. Conditional Access missing or poorly designed: everyone is protected “the same way”, or dangerous exceptions remain in place.
5. Legacy authentication allowed: older protocols continue accepting less secure connections.
6. Emergency accounts poorly protected: break-glass accounts exist, but they are not monitored or are used too often.
7. Uncontrolled external sharing: SharePoint, OneDrive, or Teams allow more exposure than necessary.
8. Email domains without properly configured SPF, DKIM, and DMARC: this increases the risk of spoofing and impersonation.
9. Defender for Office 365 in basic mode: Safe Links, Safe Attachments, or anti-phishing policies are not tuned.
10. Audit without follow-up: logs exist, but nobody reviews them or turns events into alerts.
11. No labels, DLP, or retention: sensitive data is shared or retained without a clear rule.
12. Unmanaged devices accessing corporate data: compliance or app protection policies are not required.
13. Application consent without governance: third-party apps receive excessive or permanent permissions.
14. Suspicious forwarding and mailbox rules: an attacker can exfiltrate email without the user noticing.
15. Licenses assigned incorrectly: security capabilities are paid for but not enabled, or critical users are left without adequate protection.

When should you review your Microsoft 365 configuration?

You do not need to wait for an incident to review Microsoft 365. In fact, the best audits are preventive: they detect small problems before they become breaches, data loss, or business disruption.

Typical moments when a review delivers significant value

• After a migration to Microsoft 365: email, files, or Teams were migrated, but security was not reviewed in depth.
• Before an external audit: it is better to arrive with evidence, policies, and clear owners.
• After rapid growth: more users, more devices, more guests, and more connected applications.
• When hybrid work is adopted: access from home, mobile devices, BYOD, and non-corporate networks.
• After changes in IT or partner teams: many decisions are inherited, and nobody remembers why they were configured that way.
• If there are concerns about phishing or compromised accounts: forwarding, unusual sign-ins, or alerts that have not been investigated.

A Microsoft 365 security review should not feel like an uncomfortable inspection. When properly planned, it is a way to regain control, reduce noise, and prioritize what truly matters.

Introduction: why a Microsoft 365 environment that “works” may not be secure

One of the most common mistakes is confusing availability with security. The fact that Outlook sends emails, Teams allows meetings, and OneDrive synchronizes files does not mean Microsoft 365 is properly configured.

Microsoft 365 is a very powerful platform, but also a very broad one: identity, email, collaboration, devices, applications, data, compliance, and auditing. If each part is configured in isolation, it is easy to leave gaps: one user with MFA, another without MFA; one SharePoint site locked down, another open to anonymous links; a retention policy in one area, none in another.

This guide helps identify 15 Microsoft 365 risk signs that often go unnoticed. Its purpose is not to create fear, but to help you review calmly, prioritize, and make reasonable decisions.

1. Review methodology: how to detect risks without blocking the business

In practice: a good Microsoft 365 audit does not aim to “lock everything down”; it aims to reduce risk without breaking productivity.

The review should start with a simple idea: not every area carries the same risk. A user without access to sensitive data is not the same as an account with administrative permissions. An internal communication site is not the same as a repository containing contracts, payroll, or customer information.

Recommended phases

1. Inventory: users, administrators, licenses, domains, devices, groups, sites, guests, and applications.
2. Configuration review: identity, Conditional Access, email, collaboration, data, devices, and auditing.
3. Risk-based prioritization: separate critical risks, high risks, medium risks, and maturity improvements.
4. Remediation plan: concrete actions, owners, expected impact, and effort.
5. Validation: test changes with pilot groups before applying them across the whole organization.

2. Quick map of signs, impact, and priority

In practice: not all findings carry the same weight; fix first what can open the door to a serious incident.

3. Sign 1: low or ignored Secure Score

In practice: Secure Score is not everything, but ignoring it often indicates a lack of security governance.

Microsoft Secure Score helps measure your security posture and recommends improvement actions. The problem is not whether you have a “perfect” score; the problem is when nobody reviews the recommendations, nobody prioritizes them, and nobody closes critical actions.

How it shows up

• Old recommendations have no owner.
• Changes are applied without documenting why.
• The IT team looks at Secure Score only when there is an audit or an incident.
• There is no list of “accepted actions” and “deferred actions”.

What to review

• Pending actions for identity, email, devices, and data.
• Recommendations with high impact and low effort.
• Business-justified exceptions.

How to fix it

Create a review routine, assign owners, and turn Secure Score into a prioritization tool, not an isolated “ranking”. What matters is improving in a controlled way and demonstrating progress.

Official resource: Microsoft Secure Score.

4. Sign 2: too many global administrators

In practice: the more global administrators you have, the greater the impact if one account is compromised.

The Global Administrator role is one of the most sensitive permissions in the tenant. In many organizations, it was granted “for convenience” and never removed. The result is an unnecessarily large attack surface.

How it shows up

• Support users, former partners, or personal accounts are still Global Administrators.
• Privileged Identity Management (PIM) or just-in-time access is not used.
• There is no separation of duties: email, security, billing, users, devices.
• Administrator accounts also read email or are used for daily work.

What to review

• List of administrative roles in Entra ID.
• External or old accounts with privileges.
• Use of least-privileged roles for specific tasks.
• PIM activation for sensitive access.

How to fix it

Reduce the number of global administrators, use specific roles, and apply the principle of least privilege. For occasional tasks, PIM allows permissions to be activated only for the time required.

Official resources: Best practices for roles in Entra ID · Privileged Identity Management.

5. Sign 3: incomplete or poorly applied MFA

In practice: partial MFA creates a false sense of security.

Many organizations believe they have MFA “enabled”, but exceptions appear during review: old users, shared accounts, administrators, legacy protocols, or applications that do not go through MFA.

How it shows up

• Administrators without strong MFA.
• Users excluded “temporarily” who were never included again.
• MFA applied only to certain groups.
• Weak or poorly controlled authentication methods.

What to review

• MFA status by user and role.
• Allowed authentication methods.
• Users excluded from Conditional Access policies.
• Sign-in logs where MFA was not satisfied.

How to fix it

Apply MFA consistently, especially for privileged accounts. If the organization already uses Conditional Access, it is advisable to design policies by risk, location, device, and application type.

Official resources: Security defaults · Conditional Access.

6. Sign 4: Conditional Access missing or chaotic

In practice: Conditional Access should protect without creating a mountain of exceptions that are impossible to maintain.

Conditional Access allows you to apply controls based on user, risk, application, location, device, or session. But it can also become a maze: duplicated policies, dangerous exclusions, overlapping rules, and nobody knows which policy actually applies.

How it shows up

• Many policies have no clear description.
• Users or groups are excluded without justification.
• Test modes are not used before applying changes.
• There are no specific policies for administrators, risky locations, or unmanaged devices.

What to review

• Active, report-only, and disabled policies.
• Exclusions by user, group, application, or location.
• Coverage for administrators and sensitive users.
• Relationship with Intune and device compliance.

How to fix it

Simplify. A few well-designed policies are better than many rules that are impossible to audit. Document the objective, scope, exclusions, and validation criteria for each policy.

7. Sign 5: legacy authentication allowed

In practice: allowing legacy authentication leaves open a door that many modern defenses do not cover well.

Legacy authentication is associated with older protocols that do not properly support modern controls such as MFA. If it remains allowed, an attacker can attempt access using less protected methods.

How it shows up

• Sign-ins with old protocols appear in logs.
• Legacy applications still connect through non-modern methods.
• There is no policy to block legacy authentication.

What to review

• Sign-in logs in Entra ID filtered by client/protocol.
• Real dependencies on legacy applications.
• Blocking policies and temporary exceptions.

How to fix it

Identify dependencies, communicate the change, and block legacy authentication with Conditional Access or security defaults, depending on licensing and maturity.

Official resource: Block legacy authentication with Conditional Access.

8. Sign 6: uncontrolled emergency accounts

In practice: break-glass accounts are necessary, but dangerous if nobody monitors them.

Emergency accounts are used to access the tenant if a policy locks everyone out or a serious incident occurs. The problem appears when they are used as normal accounts, are not monitored, or have weak passwords.

How it shows up

• No documented emergency account exists.
• It exists, but nobody reviews its sign-ins.
• The password is not properly safeguarded.
• The account is used for daily tasks.

What to review

• Number of break-glass accounts.
• Role assignment and exclusions.
• Alerts on sign-in.
• Usage and custody procedure.

How to fix it

Keep emergency accounts separate, monitored, and governed by a clear procedure. If they are used, an alert and post-use review should be triggered.

9. Sign 7: SharePoint, OneDrive, and Teams are too open

In practice: external collaboration is necessary, but without governance it becomes information leakage.

SharePoint, OneDrive, and Teams make it easy to share content with customers, suppliers, and partners. The risk appears when “anyone with the link” links are allowed, guests are not reviewed, or sensitive sites rely on inherited permissions.

How it shows up

• Users share sensitive documents through open links.
• There is no expiration or guest review.
• All sites have the same sharing level.
• Site owners do not know who has access.

What to review

• Organization-level sharing settings.
• Settings per site and per OneDrive for sensitive users.
• External guests and allowed domains.
• Sites with sensitive data and unique permissions.

How to fix it

Define levels by content type. Not everything should be shared in the same way. A public marketing site does not need the same restrictions as a repository for contracts or financial information.

Official resources: External sharing in SharePoint and OneDrive · Manage sharing settings.

10. Sign 8: incomplete SPF, DKIM, and DMARC

In practice: if email authentication is not properly configured, others can attempt to impersonate your domain.

SPF, DKIM, and DMARC help validate that emails sent from a domain are legitimate. Many organizations configured SPF when enabling Microsoft 365, but left DKIM or DMARC incomplete.

How it shows up

• The domain has SPF, but DKIM is not enabled.
• DMARC is missing or set to a policy that is too permissive and not monitored.
• External tools send email on behalf of the domain without being inventoried.
• Customers receive suspicious emails that “appear” to come from the company.

What to review

• SPF, DKIM, and DMARC DNS records for all domains and subdomains that send email.
• Third-party services that send as the organization.
• DMARC reports and authentication failures.

How to fix it

Inventory all legitimate senders, configure SPF carefully, enable DKIM for custom domains, and deploy DMARC progressively. The key is to move forward without accidentally blocking valid email.

Official resources: Email authentication in Microsoft 365 · Configure DMARC.

11. Sign 9: Defender for Office 365 without tuned policies

In practice: having Defender does not mean you are making full use of it.

Microsoft Defender for Office 365 can protect against phishing, malicious links, dangerous attachments, and impersonation. But many organizations stay with default settings or do not differentiate between risk profiles.

How it shows up

• Safe Links or Safe Attachments are not applied to all users who need them.
• There are no specific policies for executives, finance, or users who are more frequently targeted.
• Anti-phishing protection does not account for impersonation of key domains or users.
• Users receive recurring phishing without training or policy tuning.

What to review

• Anti-phishing, Safe Links, and Safe Attachments policies.
• Protection against user and domain impersonation.
• VIP or high-risk users.
• Alerts, campaigns, and attack patterns.

How to fix it

Apply recommended policies, tune them by risk profile, and combine technology with training. The goal is not only to block, but to reduce dangerous clicks and speed up response.

Official resources: Recommended settings for EOP and Defender for Office 365 · Safe Links · Safe Attachments.

12. Sign 10: audit and alerts without real review

In practice: having logs is not very useful if nobody looks at them or turns them into actionable alerts.

Microsoft Purview Audit makes it possible to record user and administrator activities. The risk is not usually that auditing does not exist, but that there is no process: nobody reviews, nobody investigates, and nobody knows what to do when a suspicious event occurs.

How it shows up

• There are no owners for log review.
• There are no alerts for critical changes.
• Administrator access is not reviewed.
• When there is a suspicion, nobody knows where to look for evidence.

What to review

• Unified audit status.
• Roles for searching audit logs.
• Alerts for critical activities: creation of forwarding rules, role changes, policy changes, or mass deletions.
• SIEM integration, where applicable.

How to fix it

Define which events matter, who reviews them, and how an alert is escalated. If everything is critical, nothing is. A few well-designed alerts are better than an avalanche that nobody can handle.

Official resources: Audit solutions in Microsoft Purview · Search the audit log.

13. Sign 11: no labels, DLP, or retention

In practice: if the organization does not classify or govern data, it depends too heavily on each user’s “common sense”.

Microsoft Purview enables sensitivity labels, retention policies, and data loss prevention (DLP). When no minimum strategy exists, sensitive documents may be shared incorrectly or retained longer than necessary.

How it shows up

• There are no labels such as “Internal”, “Confidential”, or “Personal data”.
• There are no retention rules for critical information.
• Users can share sensitive documents without warnings or blocks.
• There are no criteria for what to keep, what to delete, and when.

What to review

• Sensitivity labels for documents, email, Teams, groups, and sites.
• DLP policies in Exchange, SharePoint, OneDrive, and Teams.
• Retention policies by information type.
• Exceptions and affected users.

How to fix it

Start small: simple labels, critical scenarios, and policies in test mode where it makes sense. Classification should help users, not become a burden.

Official resources: Sensitivity labels in SharePoint and OneDrive · Retention in Microsoft Purview · Data Loss Prevention.

14. Sign 12: unmanaged or non-compliant devices

In practice: if any device can access corporate data, identity control is only half done.

Many incidents do not start with a password, but with a device that is not updated, encrypted, locked, or protected. Intune and Conditional Access allow organizations to require minimum conditions before granting access to corporate resources.

How it shows up

• Users access data from personal devices without app protection.
• There are no compliance policies for Windows, macOS, or mobile devices.
• A compliant device is not required for sensitive applications.
• Old devices continue accessing resources even though they do not meet standards.

What to review

• Devices registered, joined to Entra ID, or managed by Intune.
• Compliance and configuration policies.
• Mobile application protection.
• Conditional Access based on device compliance.

How to fix it

Define reasonable minimums: encryption, screen lock, updated operating system, antivirus, and compliance. For BYOD, use app protection when you do not want to manage the entire device.

Official resources: Compliance policies in Intune · Intune and Conditional Access.

15. Sign 13: application consent without governance

In practice: an app with excessive permissions can become an elegant backdoor.

In Microsoft 365, many applications connect through OAuth permissions and Microsoft Graph. Some request very broad permissions: read email, read files, access calendars, or act without a user. Without governance, dangerous permissions are approved without sufficient review.

How it shows up

• Users can consent to applications without control.
• There is no admin consent approval flow.
• Old applications still have elevated permissions.
• Service principals and granted permissions are not reviewed.

What to review

• User consent settings.
• Admin consent workflow.
• Enterprise applications with high-impact permissions.
• Apps without an owner or without recent use.

How to fix it

Restrict user consent, enable an approval flow, and periodically review application permissions. The goal is not to block innovation, but to prevent an unknown app from having access to the entire tenant.

Official resources: Configure user consent · Admin consent workflow.

16. Sign 14: suspicious external forwarding and mailbox rules

In practice: a malicious forwarding rule can extract information from a mailbox for weeks without visible noise.

After compromising an account, an attacker can create rules to forward emails, hide messages, or move sensitive communications. It is a classic sign of compromise and should be monitored.

How it shows up

• Users say they “do not receive” certain emails.
• Rules exist that move messages to strange folders.
• Automatic forwarding to external addresses appears.
• Defender generates alerts about suspicious rules or anomalous activity.

What to review

• Mailbox rules and inbox rules.
• SMTP forwarding and external forwarding.
• Defender alerts related to forwarding.
• Recent activity for affected users.

How to fix it

Block or limit automatic external forwarding, monitor the creation of suspicious rules, and review mailboxes after any compromised-account alert.

Official resources: Control automatic external forwarding · Investigate suspicious forwarding rules.

17. Sign 15: licenses assigned incorrectly or capabilities not enabled

In practice: many organizations pay for security they do not use, or leave critical users with insufficient licensing.

A Microsoft 365 misconfiguration is not always technical. Sometimes it is about licensing: users with Business Premium but Intune not configured, Defender without policies, Purview without labels, or critical profiles with licenses that do not cover their risks.

How it shows up

• Advanced plans are paid for, but their controls have not been enabled.
• High-risk users have basic licenses without sufficient protection.
• There is no mapping between user role, risk, and license.
• The organization buys “the same for everyone” even though profiles are different.

What to review

• Licenses assigned by profile.
• Capabilities that are actually enabled: Intune, Defender, Purview, Entra ID.
• Critical users: leadership, finance, HR, IT, customer service.
• Cost of unused licenses.

How to fix it

Build a profile map: what each role needs, which license it has, and which controls are active. This allows you to optimize cost and security at the same time.

Related service: Software License Procurement & Sales for Businesses.

18. Improvement plan: what to fix first

In practice: do not try to fix everything at once; start with what reduces the most risk with the least friction.

Priority 1 — Close critical doors

• MFA for administrators and critical users.
• Blocking legacy authentication.
• Reducing global administrators.
• Reviewing external forwarding and mailbox rules.
• Alerts for critical administrative changes.

Priority 2 — Control collaboration and email

• Review external sharing in SharePoint, OneDrive, and Teams.
• Complete SPF, DKIM, and DMARC.
• Tune Defender for Office 365 policies.
• Create baseline Conditional Access policies.

Priority 3 — Maturity and governance

• Sensitivity labels and retention.
• DLP for critical scenarios.
• Intune and device compliance.
• Application governance and consent.
• License optimization by profile.

19. Practical review checklists

Identity checklist

• Global administrators reviewed and justified.
• MFA applied to administrators and critical users.
• Conditional Access documented and free from dangerous exclusions.
• Legacy authentication blocked or with a retirement plan.
• Break-glass accounts monitored.

Email checklist

• SPF, DKIM, and DMARC configured on active domains.
• Defender for Office 365 reviewed: Safe Links, Safe Attachments, and anti-phishing.
• Automatic external forwarding controlled.
• Suspicious mailbox rules monitored.

Collaboration and data checklist

• External sharing reviewed at organization, site, and OneDrive level.
• External guests reviewed periodically.
• Sensitivity labels defined.
• Retention and DLP applied to critical data.

Devices and apps checklist

• Corporate devices registered and compliant.
• Application protection for mobile devices and BYOD, where applicable.
• Application consent governed.
• Apps with high permissions reviewed.

20. KPIs to measure security improvement in Microsoft 365

Security should be measured. You do not need a complex dashboard from day one: simple and actionable indicators are enough to get started.

21. Frequently asked questions about misconfigured Microsoft 365

22. Official resources and useful links

Official Microsoft documentation

• Microsoft Secure Score
• Security defaults in Microsoft Entra ID
• Conditional Access
• Block legacy authentication
• Best practices for administrative roles
• External sharing in SharePoint and OneDrive
• Email authentication: SPF, DKIM, and DMARC
• Recommended settings for Defender for Office 365
• Audit in Microsoft Purview
• Sensitivity labels in SharePoint and OneDrive
• Device compliance with Intune
• Configure user consent for applications

Related MSAdvance services

• Microsoft 365 Security & Compliance
• Modern Workplace Microsoft 365
• Software License Procurement & Sales for Businesses
• Microsoft 365 Migration
• All services

23. Conclusion and next steps

A misconfigured Microsoft 365 environment does not always show obvious signs. Often, everything seems to work until a compromised account appears, a document is shared by mistake, a domain is spoofed, or an audit asks for evidence that nobody has prepared.

The best way to reduce risk is to review the tenant with a method: identity, email, collaboration, devices, data, applications, and auditing. You do not need to solve everything in one day. What matters is prioritizing, fixing what is critical, and building a sustainable foundation.