Microsoft 365 Isn't Secure by Default: The Configuration Baseline We Build and Maintain

Most companies assume that once they pay for a Microsoft 365 license, security comes included. It does not. Microsoft secures the platform itself, the data centers, the physical network, and the underlying infrastructure. Everything above that layer, how sign in works, who can see what, whether an email that looks like it came from your CEO actually did, is left to whoever configures the tenant. Out of the box, a lot of that is left wide open.

We hear a version of the same surprise on almost every first call with a new client. They assumed the defaults were adequate because the product is Microsoft and the plan is called "Business Premium" or "E5." Then we run an assessment and find legacy authentication still allowed, audit logging turned off, guest accounts nobody remembers inviting, and DKIM keys nobody has ever rotated. None of that is unusual. It is simply the default state of a tenant that nobody has deliberately hardened.

Why the out of the box configuration is not enough

Microsoft ships every tenant with a baseline that favors compatibility over restriction. That makes sense from Microsoft's side. A brand new customer needs everything to work on day one, and the safest way to guarantee that is to leave optional protections off until someone turns them on. The result is that features like Safe Links, DMARC enforcement, and conditional access sit dormant in every plan that includes them, waiting for an administrator who knows they exist and knows how to configure them correctly.

Below is the configuration baseline we put in place in every tenant we manage. It is grouped the way we actually work through it during onboarding, and we have expanded on why each change matters rather than just listing the setting name.

The Microsoft 365 security baseline we configure

Security and anti-phishing

Phishing is still the most common way attackers get into a Microsoft 365 tenant, so this is where we start.

• Phishing protection for Microsoft Forms. Attackers have started building fake login pages and payment requests inside Microsoft Forms because it is a trusted Microsoft domain that most spam filters do not flag. This setting scans internally created forms for the patterns malicious ones use.
• Enhanced login page branding protection. This helps Microsoft Defender recognize adversary in the middle attacks, where a fake sign in page sits between your user and Microsoft to steal both a password and a live session token, defeating MFA in the process.
• DMARC on the onmicrosoft.com domain. Every tenant has a default onmicrosoft.com address whether you use it for email or not, and attackers can still spoof it. Publishing a DMARC policy closes that gap even on the domain you never intended anyone to send from.
• Safe Links across email, Teams, and Office apps. Links are checked at the moment someone clicks them, not just when the message first arrives, which catches malicious pages that were clean when delivered and turned harmful later.
• Safe Attachments. Every attachment is opened in an isolated environment and scanned for malicious behavior before it reaches the inbox, catching threats that signature based antivirus alone would miss.
• Approved domains added to Defender Spoof Intelligence. This tells Microsoft which external domains are legitimate for your organization to receive mail from, cutting down false positives while keeping unknown spoofed senders blocked.

Auditing and reporting

You cannot investigate an incident you have no record of, and this is the layer most tenants skip entirely.

• Unified Audit Log enabled. This is the single source of truth for who did what across Exchange, SharePoint, Teams, and Entra ID. It is off by default in some tenants, and if an incident happens before it is turned on, that history is gone for good.
• Mailbox auditing across the tenant. Logs every mailbox access, forwarding rule change, and permission change, which is often the first thing we check when a client suspects a compromised account.
• Reporting configured to show usernames instead of anonymized identifiers. Microsoft anonymizes some reporting data by default for privacy reasons, which is reasonable in principle, but it makes day to day investigation slower when you need to know exactly who triggered an alert.

Identity and access management

Identity is the perimeter now, not the network, so this is the largest category and the one we spend the most time on.

• Email address sign-in as an alternate login method. Gives users a fallback way to authenticate without weakening the primary sign in path.
• FIDO2 security key authentication. A phishing resistant hardware factor for the users and roles that need the strongest available protection.
• Hardware token authentication support. Covers environments where a physical key or app is not practical for every user, such as shared workstations or field devices.
• Microsoft Authenticator one-time password functionality. A reliable fallback authentication method that does not depend on cell signal or SMS delivery.
• Passwordless authentication with number matching and location information. Number matching stops the "MFA fatigue" attack where a user gets flooded with approval prompts and taps yes just to make them stop. Location context adds another signal for the user to catch a sign in attempt that is not actually theirs.
• Temporary Access Pass functionality. Lets IT issue a short lived, secure credential to onboard a new employee or recover a locked out user without ever creating or emailing a password.
• Windows LAPS for local administrator password management. Rotates local admin passwords automatically on every device, so a single leaked local admin password cannot be reused across the whole fleet.
• Administrator self-service password reset. Reduces help desk tickets while keeping the reset process itself governed by MFA rather than a phone call that could be social engineered.
• Cross-tenant access configured to trust MFA from external organizations. When your team collaborates with a vetted partner organization that already enforces its own MFA, this avoids forcing a second, redundant authentication step.
• Application registration creation disabled for standard users. Prevents an employee, or an attacker inside a compromised account, from quietly registering an app with broad permissions to your tenant's data.
• Microsoft 365 group creation restricted. Without this, any user can spin up a new Team or SharePoint site with its own permissions and sharing settings, which is exactly how tenants end up with dozens of ungoverned sites nobody can account for.
• Microsoft 365 tenant creation restricted. Stops standard users from creating an entirely separate tenant that IT has no visibility into and no way to manage.
• Automatic password expiration disabled. This looks counterintuitive but it matches current Microsoft and NIST guidance. Forcing frequent password changes pushes people toward small, predictable variations of the same password, which is easier for an attacker to guess. A strong password paired with MFA is safer than a mediocre password that just changes every ninety days.

Guest user security

Every guest account is a door into your tenant that lives outside your own employee lifecycle process.

• Guest users restricted from viewing directory information. An external partner working on one project should not be able to browse your full employee directory, org chart, and contact details.
• Inactive guest accounts disabled. Guest access is almost always granted for a specific project and almost never removed once that project ends. Automatically disabling accounts that have gone quiet closes that gap without anyone having to remember to do it manually.

Exchange Online and email configuration

Email is still where most of the working day happens, and small configuration gaps here tend to have outsized consequences.

• Direct sign-in disabled for shared mailbox accounts. Shared mailboxes should only be accessed through delegation, never signed into directly with a password that multiple people know and nobody rotates.
• Legacy TNEF and winmail.dat formatting disabled. This old formatting standard causes attachment and rendering problems for external recipients and has no real upside left in a modern environment.
• DKIM email signing enabled on supported domains. Cryptographically signs outgoing mail so receiving servers can verify it actually came from you, which is one of the three pillars of email authentication alongside SPF and DMARC.
• DKIM keys rotated from 1024-bit to 2048-bit encryption. The original default key length is weaker than current standards recommend, and rotating it is a one time fix that meaningfully strengthens every signed message going forward.
• External sender warnings enabled in Outlook. A simple visual flag that reminds a user an email originated outside the organization, which catches a meaningful share of impersonation attempts before anyone clicks anything.
• Cloud based message recall enabled. Lets a user pull back a message sent to the wrong recipient or with the wrong attachment, including for recipients on other Microsoft 365 tenants.
• Auto-expanding archives enabled. Keeps mailboxes from hitting size limits that push users toward workarounds like local PST files, which are themselves a security and data loss risk.
• Quarantine notification settings configured. Makes sure legitimate email caught by spam filtering is actually reviewed by someone, rather than silently disappearing and never being noticed.
• Sending from configured alias addresses enabled. Lets a user send as an approved secondary address without the workarounds that often lead to weaker, unmonitored mail flows.
• Message size limits configured. Set deliberately rather than left at whatever Microsoft defaults to, based on how the organization actually shares files.
• Legacy Outlook Report Phishing and Report Message add-ins removed. These older add-ins have been superseded by newer built in reporting and left in place they create confusion about which button a user should actually press.

SharePoint security

• Downloading of infected or malicious files blocked. SharePoint scans files at rest, and this setting stops a flagged file from being downloaded even if a user has permission to the site, adding a layer beyond endpoint antivirus alone.

Branding and sign-in experience

• Tenant branding applied to Microsoft 365 sign-in pages and portals. Consistent, recognizable branding on the login screen is a small thing, but it is also one of the fastest tells for users trained to spot a fake login page. A generic, unbranded sign in screen should feel wrong to your team.

Configuration drift is the real risk

Everything above solves the day one problem. The harder problem is that a Microsoft 365 tenant does not stay hardened on its own. New employees get added without being swept into the right conditional access groups. Microsoft changes default behavior with feature updates that can quietly re-enable something you turned off. Someone on the IT team flips a setting during a troubleshooting call and forgets to flip it back. A guest account from a project that wrapped up eight months ago is still sitting there with access nobody remembers granting.

Individually, none of those moments look like a security incident. Together, over a year or two, they add up to a tenant that has quietly drifted away from the baseline it started with, without anyone deciding that should happen.

This is why we do not treat this list as a one time project. It is a recurring part of how we manage every tenant for the life of the client relationship. We review configuration on a regular cadence, watch for settings that have changed since the last review, and update the baseline itself as Microsoft's platform and the threat landscape change. Our managed security services cover exactly this, ongoing configuration management rather than a one time hardening pass that starts decaying the day it is finished.

If you want a clearer picture of where your own tenant currently stands, our vulnerability assessment is the fastest way to see the gap between where you are and this baseline before committing to ongoing management.

Frequently asked questions

Is Microsoft 365 secure out of the box?

Not fully. Microsoft secures the underlying platform and infrastructure, but many protective features such as Safe Links, DMARC enforcement, and audit logging are either off by default or require deliberate configuration. A default Microsoft 365 tenant is functional, not hardened.

What is Microsoft 365 configuration drift?

Configuration drift is what happens when a tenant's security settings gradually diverge from the baseline it was set up with, through new employees, product updates, temporary changes that never get reverted, and guest accounts that outlive the project they were created for. It happens gradually and is rarely noticed until something goes wrong.

How often should Microsoft 365 security settings be reviewed?

We review managed tenants on a recurring basis rather than a single annual check, since drift accumulates continuously and Microsoft changes default behavior with feature updates throughout the year. A once a year review still leaves months of unnoticed drift in between.

What is the difference between Microsoft 365 security features and Microsoft 365 security configuration?

Security features are the capabilities Microsoft includes in a given license, such as Safe Attachments or conditional access. Security configuration is the deliberate work of turning those features on, setting them up correctly for your organization, and keeping them that way over time. Paying for the license gets you the feature. Configuration is what actually makes it protect you.

If you want to know exactly where your own tenant stands against this baseline, our managed security team can walk through your current configuration and show you the specific gaps, before you commit to anything.