Microsoft 365 Settings Most Companies Leave Wrong

Microsoft 365 is not a security configuration

Microsoft 365 gives a business a large number of security controls. That does not mean those controls are correctly configured when the tenant is created.

The problem is rarely that an organisation has no security features. More often, settings have accumulated over time. An old authentication method remains enabled. Administrator roles are broader than necessary. Mailbox forwarding was never reviewed. Audit logging is available but nobody checks it.

Microsoft also changes the platform continuously. For example, Microsoft says Unified RBAC became the default permission model for new Microsoft Defender for Office 365 Plan 2 organisations from July 2026. Existing organisations can activate it manually.

A Microsoft 365 security review therefore needs to look at the actual tenant configuration, not just the licence purchased.

Start with identity and administrator access

Identity is the first place to look because Microsoft 365 access starts with Entra ID.

Every user should have an appropriate authentication method and multi-factor authentication (MFA) policy. But simply asking whether MFA is "enabled" is not enough. You need to know how it is enforced, which users are excluded and what happens to accounts that cannot use the expected method.

Microsoft's own guidance for its education tenant configurations recommends modern authentication methods such as Microsoft Authenticator and FIDO2 security keys, while treating SMS as a weaker option rather than the preferred method.

Administrator accounts deserve a separate review. A normal user account should not also be a permanent Global Administrator just because that was convenient during setup.

Look at:

• Global Administrator assignments.
• Privileged role assignments.
• Break-glass or emergency access accounts.
• MFA requirements for administrators.
• Authentication methods registered to privileged users.
• Inactive administrator accounts.
• Guest accounts with elevated access.
• Service accounts and their permissions.

Emergency access accounts are useful, but they should be tightly controlled and monitored. They exist to prevent an administrative lockout, not to become convenient everyday accounts.

The other setting worth checking is self-service password reset. Microsoft recommends configuring appropriate authentication methods and requiring multiple methods where appropriate for password reset scenarios.

For a company with a growing Microsoft 365 environment, Microsoft 365 managed services can include administration and ongoing review rather than treating the tenant as something configured once and forgotten.

Conditional Access needs to reflect the real business

Conditional Access is where Microsoft 365 security becomes more useful than simply saying "MFA is on".

A Conditional Access policy can evaluate conditions such as the user, application, device, location, sign-in risk and authentication method, then apply a control such as requiring MFA or blocking access.

The problem is that organisations often accumulate policies without properly understanding their interaction.

A sensible baseline might require MFA for users accessing Microsoft 365. A stronger policy can apply additional controls to privileged roles. Other policies may require compliant or managed devices for sensitive applications.

But more policies are not automatically better.

An overly aggressive Conditional Access design can block legitimate work, create support problems or encourage administrators to create broad exclusions. Those exclusions then become the weakest part of the configuration.

The important settings to review include:

• Which users and groups are included.
• Which cloud applications are covered.
• Whether administrators have stronger requirements.
• Whether legacy authentication is blocked.
• Which locations are trusted and why.
• Whether device compliance is required where appropriate.
• Which users are excluded.
• Whether exclusions are documented.
• Whether policies are running in report-only mode or enforced.

Do not assume that seeing "MFA" somewhere in the tenant means every important access path is protected. Microsoft Q&A guidance illustrates the same issue: per-user MFA can appear disabled while Conditional Access or Security Defaults still require MFA. The actual sign-in and Conditional Access logs are needed to understand what happened.

Exchange Online has settings worth checking twice

Email remains one of the most exposed parts of a Microsoft 365 tenant.

Start with external forwarding. If users can automatically forward mail to external addresses, a compromised mailbox can become much more useful to an attacker. It can also create a data-loss problem without any malware being installed.

Review mailbox forwarding rules, transport rules and connectors. Understand why each exception exists.

Then review authentication and email protection settings. SMTP AUTH deserves particular attention because some older devices and applications still depend on it. Microsoft supports SMTP AUTH for specific scenarios, but organisations should not enable it broadly simply because an old application requires it.

Where possible, modern authentication should be used. If a legacy application genuinely needs SMTP AUTH, document the exception and restrict it to the smallest practical scope.

Email security also includes DKIM, SPF and DMARC. These controls address different parts of email trust and should be reviewed together rather than configured independently.

Another setting to review is administrative access to Defender and Exchange. Microsoft introduced Unified RBAC for Defender for Office 365 to provide more granular permissions. Microsoft says the model can give roles such as Security Analyst permission to remediate emails without allowing them to modify security policies.

That is useful because the principle is simple: give people enough permission to perform their job, not enough permission to change everything.

Logging, alerts and the settings nobody checks

A security control that nobody monitors is only partially useful.

Microsoft 365 produces substantial audit and sign-in information. The problem is deciding which events matter and who is responsible for reviewing them.

At minimum, investigate unusual administrator activity, suspicious sign-ins, authentication failures, privilege changes, new application permissions and unexpected mailbox configuration changes.

Sign-in logs are particularly useful when investigating authentication problems. They can show authentication details and Conditional Access results rather than forcing an administrator to guess which policy caused a sign-in to succeed or fail.

Application permissions deserve attention too. Modern applications can request delegated or application permissions to access Microsoft 365 data. A user approving an application can create a new access path that does not look like a normal mailbox password compromise.

Review consent and enterprise applications. Remove applications that are no longer required and investigate permissions that are broader than the application's business purpose.

The same principle applies to audit logs. Turning logging on is not the end of the process. Decide which events need alerting, how long useful records should be retained and who investigates them.

What companies get wrong

The most common mistake is treating Microsoft 365 licensing as equivalent to security.

A higher licence tier can provide additional security capabilities. It does not automatically configure every control correctly or guarantee that somebody is operating it.

The second mistake is copying a security baseline without considering the business.

A policy that blocks access from unmanaged devices may be sensible for a company handling sensitive information. It may be disruptive for a business where staff legitimately work from personal devices. The answer is not always to disable the policy. It may be to define which applications require managed devices and which workflows do not.

The third mistake is creating exclusions whenever something breaks.

That is how security configurations become inconsistent. If a policy blocks a legitimate application, investigate the reason and create the narrowest exception possible. A permanent "exclude this group" workaround is rarely a good long-term answer.

The fourth mistake is reviewing Microsoft 365 only after an incident.

Configuration drift happens quietly. Users leave. Administrators change roles. Applications are added. Temporary exceptions become permanent. New Microsoft features alter the available controls.

A review therefore needs to be recurring.

What to actually check in order

Start with administrator access. Reduce permanent privileged roles, verify emergency accounts and make sure administrators use strong authentication.

Next, review MFA and authentication methods. Confirm that users and privileged accounts are covered by the intended policies. Do not rely on a single screenshot or one admin page.

Then review Conditional Access. Map each policy to a specific purpose. Remove unnecessary exclusions and document the exceptions that remain.

After that, inspect Exchange Online. Check external forwarding, transport rules, connectors, SMTP AUTH and email authentication controls. Make sure old applications are not keeping weak authentication methods alive without a documented reason.

Then review application permissions. Identify applications with access to Microsoft 365 data and remove unnecessary permissions.

Finally, check logging and operational ownership. Decide which events matter, who receives alerts and what happens when something suspicious appears.

For organisations that want a broader baseline review, a structured security posture review can look at Microsoft 365 alongside the rest of the environment rather than treating the tenant in isolation.

The goal is not to turn every Microsoft 365 setting to its most restrictive value. That can make the system difficult to use and create its own operational problems. The goal is to know what each important setting does, why it has its current value, who owns it and what happens when the business needs to change it.