These are not edge cases. They are the default condition.
Most small law firms and CPA practices set up Microsoft 365 once, probably with help from whoever sold them the licenses, and then never revisit the security configuration. The setup gets done. The firm gets to work. Nobody goes back.
The problem is that Microsoft 365's default settings are not security-optimized. They are usability-optimized. Microsoft's defaults prioritize ease of access and collaboration, which makes sense for onboarding. It does not make sense for a firm handling confidential client files, financial records, or real estate transactions.
These five settings are not obscure. They are not buried in administrative consoles that require a specialist to find. They are findable by anyone with admin access. They are just not on most firms' radar, which is why they remain wrong for years.
SharePoint External Sharing Is Set to Anyone
This is the one that creates the most exposure and the most surprise when I point it out. SharePoint Online and OneDrive have an external sharing setting that controls who can access files and folders shared from your tenant. The options range from "Only people in your organization" to "Anyone," which allows sharing with no authentication required whatsoever.
The default for new Microsoft 365 tenants is "Anyone." That means any user in your organization can generate a shareable link to any file and send it to anyone, and that person can open the file without logging in or providing any credentials. No Microsoft account required. No authentication. Just a link.
For a law firm or CPA practice, this means a staff member can send a client document to opposing counsel, a client, or anyone else via a link that is completely unauthenticated. If that link gets forwarded, the file is accessible to whoever has it.
I have found client files, financial records, and case materials shared via "Anyone" links at nearly every firm I assess. The staff members who created those links typically have no idea the links are unauthenticated. They used the share button because it was easier than attaching a file to an email.
In the SharePoint admin center, go to Policies, then Sharing. Change the external sharing level for both SharePoint and OneDrive to "New and existing guests" at most, which requires recipients to authenticate. The setting to aim for in most law firms is "Existing guests only" or "Only people in your organization." Existing "Anyone" links can be audited and revoked from the same admin center.
Legacy Authentication Protocols Are Not Blocked
Legacy authentication refers to older protocols that client applications use to connect to Microsoft 365, specifically Basic Authentication, which sends credentials without the token-based approach that supports MFA. Examples include older Outlook clients, ActiveSync for mobile devices configured a certain way, IMAP and POP3 access, and SMTP authentication for certain line-of-business applications.
The critical detail is this: connections using legacy authentication bypass Conditional Access policies entirely. If you have MFA enforced through Conditional Access, which you should, an attacker who obtains a user's password can still authenticate via a legacy protocol and get full access to that account. Your MFA does nothing.
Microsoft disabled Basic Authentication for most Exchange Online services in late 2022. However, it can still be re-enabled through Exchange admin settings, SMTP Auth for specific mailboxes can still be active, and older tenant configurations may have it still running. Many firms I assess have at least one account with SMTP Auth enabled because it was set up for a printer, a fax-to-email service, or an older line-of-business application and was never revisited.
Create a Conditional Access policy in Microsoft Entra ID that blocks legacy authentication protocols. Under Conditions, select Client Apps, and check "Exchange ActiveSync clients" and "Other clients." Set the Access control to Block. Then review the Exchange admin center for any mailboxes with SMTP Auth individually enabled and disable it where it is not required for a specific documented purpose.
MFA Gaps in Per-User MFA Configuration
This one requires a bit of explanation because there are two ways to enforce MFA in Microsoft 365, and they are not equivalent.
The older method is per-user MFA, configured in the Microsoft 365 admin center under Active users. This method has a known gap: it can be bypassed through legacy authentication protocols, as described above. It also does not account for modern scenarios like trusted locations, device compliance, or risk-based access.
The current method is MFA enforcement through Conditional Access policies in Entra ID. This method applies to all modern authentication sign-ins, can be configured with exceptions for specific trusted conditions, and integrates with Microsoft's identity protection risk scoring.
What I find consistently: firms that were set up a few years ago have per-user MFA enabled for most accounts, but not all of them. There is almost always a service account, a shared mailbox, an old admin account, or a former employee's account that was missed. And because per-user MFA was configured manually, there is no policy enforcing it for new accounts added after setup. New users get added without MFA until someone notices.
Check your per-user MFA status report in the Microsoft 365 admin center and look for any accounts showing "Disabled" or "Enabled" rather than "Enforced." Enabled means the user has been offered MFA but it is not required yet. Disabled means no MFA at all. Then check whether you have a Conditional Access policy requiring MFA for all users, which would supersede the per-user settings.
Create a Conditional Access policy requiring MFA for all users, with a separate policy or exception for break-glass emergency access accounts. Once a Conditional Access policy is in place and confirmed working, per-user MFA settings become secondary. The Conditional Access policy should be the enforcing mechanism, with no gaps for new accounts.
Guest Access in Microsoft Teams Is Open by Default
Teams guest access allows people outside your organization to be added to Teams channels and have access to the files, conversations, and meetings in those channels. It is a legitimate and useful feature. It is also on by default with broad permissions.
The default guest access configuration allows external guests to share files, create and delete channels, add apps, and access all content in channels they are added to. For most law firms, this is far more access than a client or outside counsel needs for collaboration purposes.
The deeper issue is that guest access in Teams connects to the broader Azure AD B2B identity infrastructure, and guests may have more access across SharePoint than intended depending on how permissions are configured. A guest added to a Teams channel gets access to the associated SharePoint site, and if that site has overly broad permissions, the exposure compounds.
I also find, in most firm assessments, that there are guests in the tenant who were added for a specific project and never removed. The project ended. The guest access did not.
In the Teams admin center, go to Org-wide settings, then Guest access. Review which capabilities guests have and restrict sharing and app permissions to what is actually needed. In the Entra ID admin center, review the list of guest users under External Identities and remove any who no longer have an active business relationship with your firm. Set a review cadence of at minimum once per quarter.
Mailbox Auditing Is Not Reviewed and Alerts Are Not Configured
Microsoft 365 does enable mailbox auditing by default for most account types, which is good. What firms almost universally fail to do is configure alerts on the audit logs and actually review them.
Audit logging without review is just a forensic capability. It helps you figure out what happened after an incident. Alerts are what give you a chance to catch something while it is happening.
The specific scenarios worth alerting on in a law firm or CPA practice include mass file downloads from SharePoint or OneDrive, inbox rules that forward email to external addresses, login activity from unusual locations or impossible travel events, and changes to admin roles. These are the patterns that appear in business email compromise, insider threat, and account takeover incidents.
What I find in assessments: mailbox auditing is technically on, but no one has configured any alerts, no one reviews the sign-in logs, and the firm would have no way of knowing if an employee's account were forwarding all incoming email to an external address. That specific scenario, an inbox forwarding rule created by an attacker after account compromise, is one of the most common post-compromise actions I see in incident reports.
Logging tells you what happened. Alerting gives you a chance to stop it. Most firms have one but not the other.
In the Microsoft Purview compliance portal, go to Audit and confirm auditing is enabled. Then go to the Microsoft 365 Defender portal and configure alert policies for the scenarios relevant to your firm: suspicious inbox forwarding rules, mass download events, impossible travel sign-ins, and admin role changes. Microsoft provides default alert policies but they require review and tuning. On Microsoft 365 Business Premium, Microsoft Defender for Business includes additional anomaly detection that reduces the manual configuration burden considerably.
None of this is obscure. That is the point.
These are not advanced security configurations. They are not enterprise-tier features that require specialized licensing. They are settings that every Microsoft 365 Business Premium tenant can configure, and most of them should have been addressed at initial setup.
They persist because nobody went looking for them. The environment got set up to work, not to be secure. Over time, the gap between what was configured and what should have been configured grows, because new staff get added, new projects create guest access, and no one circles back.
If you are a managing partner or firm administrator reading this, the question is straightforward. Can your IT provider tell you, specifically, what your SharePoint external sharing setting is set to right now? Can they tell you whether legacy authentication is blocked? Do they send you a report on guest access in your Teams environment each quarter?
If the answer to any of those is "I am not sure," that is your starting point.
Want to see exactly where your M365 environment stands?
A Lowery Solutions security assessment covers all five of these areas and more, with prioritized findings and a clear path to remediation.
Request a Security AssessmentBuilt for Austin law firms, CPA practices, and title companies on Microsoft 365.