Locking Down Your Microsoft 365 Tenant: Why Default Settings Aren't Enough

Microsoft 365 has become the operational backbone of most small and mid-sized businesses — email, files, identity, collaboration, and increasingly the device management layer all live in one tenant. That consolidation is enormously convenient. It also means that a single compromised account can hand an attacker your email, your documents, your contact lists, and a trusted platform from which to attack your customers and vendors.

Here's the uncomfortable truth: a Microsoft 365 tenant configured with out-of-the-box settings is not secure. Microsoft provides the tools to lock a tenant down properly — but most of them are not fully enabled by default, and many of the most important ones require deliberate design decisions that generic setup guides never address.

We regularly take over tenants from businesses that believed they were protected because "it's Microsoft — they handle security." What we find instead: no conditional access policies, legacy authentication still enabled, every user able to consent to third-party apps, no alerting on suspicious sign-ins, and global admin accounts used for daily email. This article walks through what proper tenant hardening actually involves.

Why Attackers Love an Unhardened Tenant

Business email compromise (BEC) remains one of the costliest forms of cybercrime, and Microsoft 365 tenants are its primary hunting ground. The typical attack is unglamorous: a phishing email harvests a password, the attacker signs in from infrastructure designed to evade detection, sets up a mailbox rule to hide their activity, studies invoice patterns for a few weeks, then sends a payment redirect request from your real domain to your real customer.

No malware. No exploit. No alarm — unless your tenant was configured to raise one. Every stage of that attack chain can be blocked or detected by controls that already exist in Microsoft 365. The gap is almost never the platform; it's the configuration.

Conditional Access: The Foundation of Tenant Security

If you implement nothing else from this article, implement conditional access. Conditional access policies in Microsoft Entra ID are the policy engine that evaluates every single sign-in against rules you define: who is signing in, from where, on what device, to which application, and at what risk level. Based on those signals, access is granted, blocked, or granted only with additional requirements.

A well-designed conditional access framework typically includes:

Risk-Based Policies: Letting the Platform Fight for You

Microsoft Entra ID Protection (available with Entra ID P2 licensing, included in Microsoft 365 Business Premium's bigger siblings like E5, or as an add-on) continuously scores two things: sign-in risk — the probability that a specific authentication attempt isn't actually the user — and user risk — the probability that an identity itself has been compromised, informed by signals like credentials appearing in dark-web dumps.

These risk signals draw on the telemetry Microsoft sees across billions of authentications daily: impossible travel, anonymized IP addresses, password-spray patterns, token anomalies, and unfamiliar sign-in properties. Risk-based conditional access policies put that intelligence to work automatically:

• Elevated sign-in risk → require fresh MFA or block outright. A sign-in from an anonymizing VPN at 3 a.m. local time shouldn't be treated like a login from the office.
• High user risk → force a secure password reset or block access entirely until an administrator investigates. If Microsoft has seen your user's credentials in a breach corpus, the account should not continue operating as if nothing happened.

The practical effect: your tenant responds to compromise indicators in real time, around the clock, without waiting for a human to notice. For lean internal IT teams, this is some of the highest-leverage security automation available anywhere.

Privileged Access: Your Admins Are the Crown Jewels

Most tenants we audit have too many global administrators, and those accounts are used for everyday work. One phished admin equals total tenant compromise — every mailbox, every file, every setting.

Dedicated Admin Accounts

Administrative privileges should live in separate, cloud-only accounts that have no mailbox, no licenses beyond what administration requires, and are never used for browsing or email. Daily work happens in a standard account; elevation happens deliberately.

Least Privilege and Role Scoping

Global Administrator should be reserved for a tiny number of break-glass scenarios. Entra ID includes dozens of scoped admin roles — Exchange Administrator, User Administrator, Helpdesk Administrator — that grant exactly what a function requires and nothing more. The number of standing global admins in a small business tenant should be countable on one hand, with most guidance suggesting two to four.

Just-in-Time Elevation

With Privileged Identity Management (PIM), admin roles are held as eligible rather than permanently active. An engineer activates the role when needed, for a limited window, with MFA and justification, and the activation is logged. Standing privilege — the thing attackers hunt for — simply doesn't exist most of the time.

Break-Glass Accounts

Every tenant needs at least one emergency access account excluded from conditional access policies, protected by a long credential stored offline, and monitored so that any use triggers an immediate alert. Without one, an overly aggressive policy change can lock your entire organization — including its admins — out of the tenant.

The Controls Everyone Forgets

Application Consent Governance

By default, any user in your tenant can grant third-party applications access to their data — and "consent phishing" exploits exactly that. A user clicks a link, sees a legitimate-looking Microsoft permissions prompt, and authorizes a malicious app to read their mail and files indefinitely — no password stolen, no MFA bypassed, and the access survives password resets. User consent should be restricted to verified publishers and low-risk permissions at most, with an admin consent workflow for everything else.

Mailbox Rules and Mail Flow Hardening

The first move of nearly every BEC actor after compromising a mailbox is creating rules that auto-delete or forward security warnings and replies. External auto-forwarding should be disabled tenant-wide, and alerts should fire whenever suspicious inbox rules are created. Layer on the anti-phishing, safe links, and safe attachment policies in Microsoft Defender for Office 365, plus properly configured SPF, DKIM, and DMARC so your domain can't be trivially spoofed.

External Sharing Discipline

SharePoint and OneDrive default to fairly permissive sharing. Anonymous "anyone with the link" sharing should be disabled or aggressively time-limited, guest access should be reviewed on a schedule, and Teams external access should be scoped to the domains you actually collaborate with.

Audit Logging and Alerting

Unified audit logging must be verified as enabled, with retention configured to meet your compliance requirements — and someone must actually be watching. Logs that no one reviews are forensic evidence, not protection. Alert policies should cover the events that matter: new inbox forwarding rules, mass file downloads, sign-ins flagged as high risk, new admin role assignments, and conditional access policy changes.

Data Loss Prevention and Sensitivity Labels

Once identity and access are hardened, the next layer is the data itself. DLP policies can detect and block Social Security numbers, credit card data, or patient information leaving the tenant through email or sharing links, while sensitivity labels apply encryption that travels with the document — even after it's downloaded.

Secure Score Is a Map, Not a Destination

Microsoft Secure Score gives every tenant a numerical security rating against Microsoft's recommended controls, and it's a genuinely useful prioritization tool. But chasing the number isn't the goal — some recommendations don't fit every business, and some critical work (like designing sensible conditional access exclusions, or testing your policies against real attack paths) isn't fully captured by the score. Treat it as a map of what to evaluate, reviewed quarterly, not a vanity metric to maximize.

Where to Start

If your tenant has never had a deliberate security review, the highest-impact sequence looks like this:

• Enforce MFA for all users and block legacy authentication — these two moves alone shut down the majority of opportunistic account takeover.
• Audit and reduce admin role assignments; create dedicated admin and break-glass accounts.
• Build a baseline conditional access framework: MFA everywhere, geo-restrictions, device requirements for sensitive access.
• Restrict user app consent and disable external auto-forwarding.
• Enable risk-based policies if your licensing supports them — and if it doesn't, evaluate whether an upgrade costs less than your current exposure.
• Verify audit logging, configure alert policies, and assign actual ownership of reviewing them.

None of this requires exotic third-party tooling. It requires expertise, deliberate configuration, testing against lockout scenarios, and ongoing maintenance — which is exactly why tenant hardening is one of the most valuable things a competent managed IT provider does for the businesses it serves.

---

Your Microsoft 365 tenant is either a hardened perimeter or an open door — and the difference has nothing to do with how much you pay Microsoft and everything to do with how the tenant is configured and maintained. If you can't say with confidence which conditional access policies are active in your tenant right now, that's the answer worth acting on.