Microsoft 365 Security: 8 Settings Texas SMBs Miss

If you want the wider picture first, our Microsoft 365 managed services overview covers licensing, migration and support. This post is narrower. It’s the list we work through when a Texas business hands us a tenant that nobody has hardened since the day it was created, which is a surprisingly common way for a tenant to arrive.

Everything below cites Microsoft’s own documentation, including the exact PowerShell parameter names and the exact default values, so you can check your own tenant against it rather than take our word for it. Where a setting is genuinely fine by default, we say so instead of padding the list.

What counts as a Microsoft 365 security setting

A Microsoft 365 security setting is a tenant-level control that changes how identity, email, or file sharing behaves for every user at once. It lives in the Microsoft 365 admin center, the Defender portal, the Microsoft Entra admin center, or Microsoft Purview. It isn’t antivirus on a laptop, and it isn’t something a single user can switch on for themselves.

That distinction matters more than it sounds. Most of the security spending we see at 30-person Texas companies goes to endpoint tools, while the controls that would actually have stopped the last incident were sitting in a portal nobody had opened in 2 years.

Why a default tenant is not a secure tenant

Microsoft builds defaults for the widest possible customer base, which means the defaults have to avoid breaking anyone’s mail flow. Safe for everyone and secure for you are different design goals, and the gap between them is where attackers live.

The FBI’s 2025 Internet Crime Report put verified business email compromise losses at $3,046,598,558 across 24,768 complaints, which works out to roughly $123,000 per reported incident. BEC ran second only to investment fraud. Almost none of it needs malware. It needs one mailbox and a convincing reply.

Microsoft Secure Score gives you a rough read on where you stand, and the reported average across Microsoft’s customer base has sat around 35 to 40 percent. Treat that number as a work queue rather than a grade. A tenant at 40 percent usually has 6 or 7 free switches waiting.

Default protection compared with the Standard and Strict presets

The values below come straight from Microsoft’s recommended settings reference. The left column is what your tenant does today if nobody has changed it.

1. Impersonation protection is off until you turn on a preset policy

This is the one that surprises people. Microsoft documents it plainly. The default anti-phishing policy in Defender for Office 365 gives you spoof protection and mailbox intelligence for all recipients, and then states that the other impersonation protection and phishing threshold settings aren’t configured in the default policy.

Read that again with your CFO in mind. An email from a lookalike domain, signed with your controller’s name, sails through a default tenant untouched because TargetedUserProtectionAction is set to take no action at all. Turn on the Standard or Strict preset security policy and that same message gets quarantined.

Preset policies are not enabled by default either. An administrator has to switch them on and assign them. You can protect up to 350 named users for impersonation in a preset, and domain impersonation covers your accepted domains automatically once the preset is live.

2. Your bulk email threshold is still parked at 7

Bulk complaint level runs from 1 to 9, and the default policy only acts at 7 or above. Standard drops it to 6 and Strict to 5. The lower you go, the more marketing-shaped mail lands in junk, and the fewer grey-area messages reach the person who forwards things without thinking.

There’s a real trade-off here and we’d rather name it than pretend otherwise. Move a sales team to Strict without warning and you’ll get tickets the same afternoon about a missing supplier newsletter. We usually run Standard for the whole company and Strict for finance and leadership, which is exactly what preset policies are built to let you do.

3. Audit records expire at 180 days and nobody notices until it matters

Audit Standard, which is what E1 and E3 include, retains records for 180 days. Microsoft raised that from 90 days for logs generated on or after 17 October 2023, so if you read a guide older than that you may still be planning around the wrong number.

E5 buys you one year of default retention, and this is where the fine print bites. Per Microsoft’s audit log retention documentation, that longer window applies to Exchange, SharePoint, OneDrive and Microsoft Entra ID. Teams, Power Platform and Defender events still fall back to 180 days unless somebody writes a custom retention policy.

Why it matters. Business email compromise gets discovered late, often when a vendor calls about an invoice that was paid to the wrong account 7 months ago. If your audit trail stopped at 180 days, your forensics stop there too, and so does your insurance claim.

The good news is that mailbox auditing itself is on by default and the default owner actions already include the ones you’d want, including MailItemsAccessed, UpdateInboxRules, HardDelete and Send. Microsoft’s mailbox auditing reference lists the full set. One caution. If you add custom actions to a mailbox, you drop out of the default set, and any actions Microsoft adds later won’t apply to you automatically.

4. Legacy authentication still has a door open somewhere

Legacy protocols can’t do MFA. That’s the whole problem in one sentence. Microsoft’s security defaults block legacy authentication and require MFA for everyone at no extra licensing cost, which makes them the right answer for a tenant with no Entra ID P1.

SMTP AUTH is the stubborn one. It’s what your copier, your alarm panel, your line-of-business app and that one 2016 accounting server use to send mail. Microsoft’s updated deprecation timeline has basic authentication for client submission being disabled by default for existing tenants by the end of December 2026, with administrators still able to re-enable it if they must.

Do the inventory now rather than in December. Every device that sends mail, what it authenticates with, and who owns the vendor relationship. We’ve never done this exercise at a Texas SMB and found fewer than 3 surprises, and the copier is almost always one of them.

5. Users can still consent to OAuth apps on their own

Consent phishing skips the password entirely. A convincing prompt asks for permission to read mail and files, the user clicks accept, and the attacker holds a token that survives a password reset. No MFA challenge, because the user already passed it.

Microsoft’s guidance in configure how users consent to applications is to restrict user consent to apps from verified publishers, and only for permissions you have classified as low impact. Check what your tenant actually does today, because the setting varies with when the tenant was created and whether anyone changed it.

Turn on the admin consent workflow at the same time. Without it, a blocked user just sees an error and finds a workaround. With it, they get a request button and you get a queue you can review, which is the difference between a control that holds and a control that gets switched back off in a week.

6. Nobody is watching inbox rules, even though forwarding is already blocked

Here’s a correction to advice you’ll still find on plenty of MSP blogs, including versions of our own older material. External auto-forwarding is not wide open by default any more. Microsoft’s outbound spam policy has shipped with automatic forwarding set to Automatic system-controlled since September 2020, and that setting blocks it. A blocked message bounces with 5.7.520 Access denied, Your organization does not allow external forwarding, which Microsoft documents in its external email forwarding guidance.

So the setting is fine. The monitoring is not. Attackers adapted years ago and now build rules that never touch an external address. A rule that moves anything containing the words invoice, wire, or bank into RSS Feeds and marks it read hides an entire fraud conversation from the mailbox owner while the attacker reads it from a session you can’t see.

UpdateInboxRules is already in the default mailbox audit set, which means the evidence is being written. The question is whether anything alerts on it. If the honest answer is no, that’s your gap, and it isn’t a setting so much as somebody’s job.

While you’re in there, check remote domain settings and any per-mailbox ForwardingSmtpAddress values separately. Forwarding involves 2 independent controls, and a mailbox-level forward configured before the policy tightened can still behave differently from what you’d expect.

7. The root SharePoint site still shares with Anyone

Your root communication site at tenant-name.sharepoint.com defaults to a sharing setting of Anyone, which means unauthenticated links. Most SMBs never look at it because they think of SharePoint as the site collections they created on purpose.

Two changes are worth knowing about for 2026. Anyone links now expire automatically after 30 days by default, extendable to 180. And Microsoft Entra B2B integration is on by default for all tenants from May 2026, which turns external recipients into proper guest accounts with an audit trail you can actually follow and revoke when somebody leaves a vendor.

Set the tenant ceiling to New and existing guests if you collaborate externally, or to Only people in your organization if you don’t, then loosen individual sites that genuinely need it. Microsoft explains the per-site override in change the sharing settings for a site. Tenant tight, site loose, never the reverse.

8. Break-glass accounts are not ready for mandatory MFA

Mandatory MFA is not a proposal any more. Per Microsoft’s mandatory MFA plan, Phase 1 began in October 2024 for the Azure portal, Entra admin center and Intune admin center, rolled to the Microsoft 365 admin center from February 2025, and Phase 2 started on 1 October 2025 for Azure CLI, Azure PowerShell, the mobile app, IaC tools and REST API endpoints. Microsoft states there’s no way to opt out.

If you needed more time, the postponement window for Phase 2 runs to 1 July 2026, which is now behind us for most tenants. The part that catches people is buried in the same document. Break-glass and emergency access accounts are required to complete MFA once enforcement begins, and any user exclusions you configured stop applying.

Microsoft’s recommendation is to move those accounts to a passkey using FIDO2, or to certificate-based authentication. Both satisfy the requirement. Do it before you need the account, because the moment you need a break-glass account is precisely the moment you can’t troubleshoot why it won’t sign in.

The other trap is service accounts. A user identity running a nightly script is in scope for Phase 2 enforcement. Managed identities and service principals are not. If your backup job or your ERP sync authenticates as a person, that’s a migration, not a checkbox.

How these settings line up with Texas SB 2610

Texas Senate Bill 2610 took effect on 1 September 2025 and creates a safe harbor against exemplary damages for businesses under 250 employees that hold sensitive personal information and maintain a recognised cybersecurity program. The obligations scale with headcount, and the program has to exist before a breach, not after one.

We are not your lawyers and this isn’t legal advice. What we can tell you is that the evidence auditors and insurers ask for maps almost one to one onto the list above, and our Texas SB 2610 compliance guide walks the documentation side in more detail.

The order we work these in over 30 days

Sequence matters, because 2 of these settings generate helpdesk tickets and the rest don’t. Do the invisible ones first so you bank the risk reduction before anyone starts complaining about junk mail.

1. Days 1 to 3. Audit MFA coverage, confirm break-glass accounts use FIDO2 or certificate-based authentication, and list every user identity acting as a service account.
2. Days 4 to 7. Inventory every device and app using SMTP AUTH. Name an owner for each one and open the vendor tickets now.
3. Days 8 to 10. Restrict user consent to verified publishers with low-impact permissions, and switch on the admin consent workflow with a named reviewer.
4. Days 11 to 14. Set the tenant SharePoint sharing ceiling, then re-open only the sites that need external access.
5. Days 15 to 18. Enable the Standard preset security policy for everyone. Add your 350 protected users, weighted to finance and leadership.
6. Days 19 to 22. Move finance and leadership to the Strict preset. Tell them first, and give them the quarantine notification link on day one.
7. Days 23 to 26. Write a custom audit retention policy for the workloads that would otherwise drop to 180 days, and confirm what your licence actually covers.
8. Days 27 to 30. Stand up alerting on inbox rule creation and unusual mailbox access, and decide who reads those alerts on a Tuesday morning.

What actually changes once these are on

The visible change is boring, and that’s the point. Quarantine digests start arriving. A handful of legitimate newsletters need releasing in week one. Somebody’s scanner stops emailing until you fix its authentication, which is the one moment in the project where you’ll wish you’d read step 2 more carefully.

The invisible change is the one you’re paying for. A lookalike domain that would have reached your controller’s inbox gets quarantined instead. A consent prompt gets queued for review rather than accepted at 4:50 on a Friday. An inbox rule created at 2am generates an alert instead of silence.

None of this replaces the rest of a security program. You still need backups you’ve tested, patching that runs on a schedule, and people who’ve been trained recently enough to remember it. What these 8 settings do is close the specific gaps that Microsoft leaves open on purpose, using licensing you already own. That’s an unusually good ratio, and it’s why we start here on Microsoft 365 engagements in Houston and across the rest of Texas.

If you’re planning a tenant move rather than a cleanup, sequence the hardening into the project instead of bolting it on afterwards. Our Microsoft 365 migration checklist for Texas businesses covers where each of these belongs in a cutover, and our older piece on improving Microsoft 365 email security features covers the user-facing habits that sit alongside the tenant settings.

Questions Texas SMBs ask about Microsoft 365 security settings

Do I need Microsoft 365 E5 to fix any of this?

How long does it take to turn on the preset security policies?

Will any of this break Outlook for our users?

We already have MFA on everyone. Are we covered?

What does Texas SB 2610 actually require us to have in place?

How do we know whether someone already changed these settings?