Introduction
Microsoft 365 offers powerful collaboration and productivity tools, but default settings often leave numerous security gaps. This post aims to highlight five common misconfigurations we frequently encounter in our audits, along with practical steps to address them. During this post, we'll look at the following five areas:
- Security Defaults
- Conditional Access Planning
- Guest Invite Settings
- User App Consent Settings
- External Collaboration Settings
This is not exhaustive but hopefully aims to highlight some key areas for improvement across your tenant.
Security Defaults: Helpful Intentions, Harmful Limitations
Microsoft introduced Security Defaults to help organisations without dedicated IT teams get a baseline of security features enabled. When turned on, Security Defaults enforce a standard set of policies like MFA (multi-factor authentication) for all users and block legacy authentication protocols. Security Defaults are enabled by default for all new tenants. While this is a good starting point for ensuring a base layer of protection, Security Defaults are not designed for flexibility or scalability. For businesses with more complex needs or desire to control their own identity security, Security Defaults can often be more of a constraint than a benefit.
The Main Issue Relying on Security Defaults
Security Defaults do not allow organisations to take fine-grained control over their identity security and with Security Defaults enabled, it prohibits the use of Conditional Access policies. Ultimately, this leaves organisations without the ability to build policies that suit their use cases and needs.
Don't Disable Security Defaults Blindly
Disabling Security Defaults does open the door to greater control, but that door swings both ways. Without a clearly defined and well-executed Conditional Access strategy, it's easy to accidentally weaken your organisation's overall security posture.
Bottom line: If you're planning on disabling Security Defaults, have a plan and act on it immediately. That starts with designing Conditional Access properly, not just creating a few policies, but thinking it through and following a well-designed framework. Utilise 'report-only' mode where appropriate to put policies in an audit mode to gather statistics and remediate blocks before flicking the switch.
Conditional Access: Not Just "Set and Forget"
We've spoken about Conditional Access above, but Conditional Access is arguably the most powerful tool in Microsoft 365's security toolkit, however, it only delivers value when it's planned, maintained, and aligned to your business needs.
A common issue we see in audits is that Conditional Access policies are:
- Unstructured: Created reactively over time without a coherent strategy
- Overlapping: Multiple policies apply to the same users with conflicting or redundant rules
- Forgotten: Policies are enabled once and never revisited, even as the business evolves
- Exception without Supplemental Coverage: Exceptions happen; however, users or groups are often included in an exception without supplemental policies to reduce the attack surface of the exception
Why a Strategic CA Design Matters
Poorly planned Conditional Access can lead to:
- Access gaps: Users bypass MFA due to policy exclusions or misalignment
- Operational friction: Legitimate users are blocked or slowed down, leading to productivity loss and policy pushback
- Unmanaged growth: "Policy sprawl" leads to hard-to-audit, hard-to-maintain environments
Following a planned approach or a framework can help clarify your Conditional Access policies and keep your policies organised and clear to their intent.
One of the recommended ways to achieve this is to adopt personas for your users in your organisation. Identifying user groups and identifying the applications and resources that they require access to, from where and on what device, will help to streamline your deployment.
An example of a few personas may be Internals, Externals, Devs, Admins, Emergency Access. Don't hesitate to use sub-sets where required too!
Our Recommendations
- Determine your personas ahead of time
- Utilise report-only mode first before deployment
- Leverage a clear naming convention
- Monitor sign-in logs and policy impacts regularly
- Follow up exceptions with suitable supplemental policies
- Implement what works for your organisation
Guest Invite Setting Defaults: Who's Inviting Whom?
By default, Microsoft 365 tenants allow all users to invite external guests into the tenant. While collaboration is a core benefit of Microsoft 365, this setting poses a real risk when not managed correctly.
What This Means
Any user either intentionally or accidentally can invite an external user (e.g. a personal email address, contractor, or competitor) into the tenant. That guest could then be granted access to files, Teams channels, or SharePoint sites.
Why This Is Risky for Businesses
- Lack of visibility and control
- Potential for data leakage
Recommendation: Restrict Guest Invites
In the Entra portal:
Identities > External Identities > External Collaboration Settings, under Guest invite settings change the setting to:
- "Only users assigned to specific roles can invite" — This will mean only users with certain roles assigned will be able to invite guests into your tenant.
This ensures that guest access is deliberate, auditable, and controlled.
User App Consent Settings: A Backdoor You Didn't Notice
Another commonly overlooked area is user consent to applications. By default, Microsoft 365 allows users to consent to third-party applications requesting access to their Microsoft 365 data (e.g. Outlook, OneDrive, Teams).
What's the Risk?
- A user can unknowingly grant a malicious app access to their email, calendar, or files
- Once consented, dependant on the permissions these apps can read data, send mail on the user's behalf, or exfiltrate information
How App Consent Works
When an app is registered (either by a developer or third party), it can request OAuth permissions to read or manage user data. If users are allowed to approve these requests, a single click can lead to a wide-scale breach.
Recommendation: Restrict User Consent
Navigate to Entra > Enterprise Applications > Security > Consent and permissions:
- Toggle this to "Do not allow user consent"
- Ideally utilise the Admin Consent Workflow to allow users to request access, which must be approved by an appropriate admin
Additionally, regularly audit consented applications in your environment to ensure applications are known and trusted, also checking the permissions and authentication methods these applications hold.
External Collaboration Settings: Everyone Is Welcome… by Default
When you first spin up a Microsoft 365 tenant, the external collaboration settings are wide open. That means:
- You can share files, folders, or sites with any external domain
- No restrictions are applied to guest domains or user types
- The defaults for file sharing permit the creation of anyone links
This is great for collaboration speed—but terrible for data protection and governance.
Risks of Allowing All Domains
- Anyone with a public email address (e.g. Gmail, Outlook) can become a guest
- Increased likelihood of data leakage
Recommendation: Implement a Safe List or Block List
In Entra > External Identities > External Collaboration Settings > under Collaboration restrictions, configure:
- Allow invitations only to the specified domains (most restrictive)
This setting ensures that only those users from known and trusted domains can be invited to collaborate with, greatly reducing the chance of accidental data oversharing and data exfiltration.
Wrapping Up
In this post, we've hopefully shone a light on a few common misconfigurations that with a few small changes can provide organisations with an increased security posture. A lot of these settings are often found at their defaults, indicating that organisations aren't aware of the risks they face until it's too late.
If you'd like help securing your Microsoft 365 tenant or want to explore your configuration in more depth, get in touch for a tailored audit or review.
