Microsoft 365 default settings expose tenant security gaps

At a glance

What this is: This is an analysis of how Microsoft 365 default settings and missing CIS controls create avoidable identity and email exposure.

Why it matters: It matters because IAM, NHI, and human identity teams all inherit the same weak defaults when device registration, MFA enrollment, and external collaboration are left open.

By the numbers:

• 29 net-new controls are now included in the CIS v6.0.0 posture baseline for Microsoft 365 tenants.
• In a default Microsoft 365 tenant, any standard user can register a new device to Entra ID, complete MFA enrollment on any laptop, and inherit baseline access through the user's own account.

👉 Read Abnormal AI's analysis of Microsoft 365 CIS v6 posture gaps

Context

Microsoft 365 defaults are a governance problem before they are a technical one. When device registration, MFA enrollment, guest collaboration, and mail-flow exceptions are left in their out-of-the-box state, the platform behaves as an unreviewed identity surface rather than a controlled enterprise environment.

That matters for IAM because the same tenant can expose human sign-in paths, delegated admin rights, and messaging trust assumptions at once. In practice, security teams are not just managing users, they are managing the policy gaps that let those users, devices, and external connections become footholds.

The article shows why CIS v6 matters: it converts a broad set of tenant defaults into explicit checks across Entra, Intune, Teams, Defender, and Exchange. The starting position described here is typical, not exceptional, which is exactly why it persists.

Key questions

Q: How should security teams reduce Microsoft 365 identity risk from default settings?

A: Start by treating default tenant settings as temporary, not acceptable. Restrict device registration, require managed devices for MFA enrollment, disable weak authentication methods, and review Exchange and Teams trust exceptions in the same change cycle. The goal is to remove inherited trust paths before attackers use them as a foothold.

Q: Why do Microsoft 365 defaults create such a wide attack surface?

A: Because identity, device, email, and collaboration controls are distributed across multiple admin planes, and many tenants never review them together. A user who can enroll a device, register MFA, or communicate through an allow-listed channel can convert a small compromise into broad tenant access more easily than many teams assume.

Q: What breaks when sender allow lists are too broad in Microsoft 365?

A: Broad allow lists let partner-compromise and spoofed messages bypass the scanning layer entirely, which removes the tenant's last chance to inspect malicious email. They also create a false sense of trust, because messages that look administratively approved are often the easiest ones for attackers to exploit.

Q: Who is accountable for Microsoft 365 trust exceptions that remain open?

A: Accountability should sit with the IAM or platform owner who approved the exception, plus the security team that owns continuous review. CIS-style baselines are useful because they make those exceptions visible, measurable, and auditable instead of leaving them buried in scattered admin settings.

Technical breakdown

Entra device registration and MFA enrollment defaults

Microsoft Entra ID can allow standard users to register devices and complete MFA enrollment unless those paths are restricted by policy. That creates a legitimate enrollment surface that attackers can abuse after credential compromise, because the attacker is not breaking the protocol, they are using the tenant's accepted authentication and device-trust workflow. CIS v6 calls out this condition through controls that limit who can join devices, cap devices per user, and require managed devices for MFA registration. The technical issue is that identity proof and device proof are being accepted too early, before the tenant has decided whether the endpoint belongs inside the trust boundary.

Practical implication: restrict device join and MFA registration to managed, approved paths before relying on device trust in Conditional Access.

OAuth device code flow and token theft risk

OAuth device code flow is designed for devices that cannot easily present a browser-based login, but it can be abused to separate the user from the device and still obtain tokens. In the Storm-2372 pattern referenced here, the attacker uses a legitimate Microsoft flow to harvest session access without touching the password or triggering a conventional MFA prompt. That makes this a protocol-abuse problem, not a password-strength problem. Blocking device code flow removes one of the cleanest routes from phishing to token issuance, especially where long-lived sessions or unmanaged endpoints are in play.

Practical implication: disable device code flow tenant-wide unless there is a tightly justified exception and compensating monitoring.

Allow lists and external collaboration as bypass channels

Email and collaboration controls fail when the tenant treats trusted senders, unmanaged Teams users, and trial tenants as safe by default. Static allow lists, safe lists, and blanket sender-domain exceptions are attractive because they reduce alert volume, but they also create blind spots where partner-compromise and impersonation traffic bypasses the scanning pipeline entirely. The same pattern appears in Teams external access and guest governance, where unmanaged external users can initiate conversations unless specifically blocked. In each case, the control failure is trust inheritance without continuous revalidation.

Practical implication: remove broad allow lists and external collaboration exceptions, then reintroduce only tightly scoped, monitored trust relationships.

Threat narrative

Attacker objective: The attacker wants to turn legitimate tenant trust settings into a reliable path for token theft, phishing delivery, and tenant-level access expansion.

1. Entry begins with a legitimate Microsoft authentication path, such as OAuth device code phishing, or with a compromised tenant trust relationship like a blanket allowed sender domain.
2. Escalation occurs when the attacker uses the accepted identity or mail-flow path to register access, enroll MFA, or send messages that bypass scanning and look trusted to the tenant.
3. Impact follows when the compromised identity or allow-listed channel is used to expand access, deliver phishing, or turn a single account into a broader tenant compromise path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Default trust is the real vulnerability in Microsoft 365 posture. The article shows that out-of-the-box tenant settings can quietly grant device registration, MFA enrollment, and external communication rights before any meaningful review occurs. That is not a single control failure, but a trust model that assumes the baseline is safe until proven otherwise. Practitioners should read this as a reminder that unreviewed defaults are policy decisions, not neutral settings.

Device code phishing exposes a weak assumption about authentication flows. Conventional MFA logic assumes the challenge and the device stay bound together closely enough to make abuse visible. That assumption breaks when an attacker can separate the user interaction from the endpoint and still obtain usable tokens through a legitimate Microsoft flow. The implication is that protocol choice now shapes attacker opportunity as much as password policy does.

Inherited allow lists create identity blind spots across email and collaboration. When inbound anti-spam, Teams external access, and guest collaboration rely on broad trust exceptions, the tenant stops distinguishing between known partners and compromised partners. That is why partner-compromise BEC and unmanaged collaboration channels remain so effective. Practitioners should treat inherited trust as a standing exposure surface, not a convenience feature.

Control coverage only works when tenant policy is evaluated as a system. The article's move from CIS v3 to CIS v6 is meaningful because the risk is spread across Entra, Intune, Defender, Teams, and Exchange, not isolated in one admin pane. A point-in-time review of one control family misses the compound effect of weak device trust plus weak mail trust. Security teams need a cross-plane view of identity, device, and messaging governance.

Microsoft 365 security now depends on reducing trust amplification, not just blocking known techniques. The named concept here is trust amplification, where a small identity or mail-flow exception becomes a much larger access path after compromise. That is the pattern behind device registration abuse, token theft, and partner-compromise delivery. The practical conclusion is that narrow exceptions matter less than how quickly they can be withdrawn and revalidated.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities, according to the same research.
• For a broader control lens, see Top 10 NHI Issues for the governance patterns that typically drive exposure across machine identities and access exceptions.

What this signals

The practical signal for IAM and security teams is that tenant posture reviews need to move from isolated configuration checks to trust-path mapping. When identity, device, email, and collaboration exceptions are evaluated together, the hidden blast radius becomes visible before an attacker finds it.

Trust amplification: a small number of default or inherited exceptions can multiply risk across the tenant when they are allowed to persist unreviewed. That is the pattern behind OAuth abuse, unmanaged device enrollment, and mail-flow bypass, which means continuous exception review should be treated as a governance control, not an admin housekeeping task.

With 1.5 out of 10 organisations highly confident in securing NHIs according to The State of Non-Human Identity Security, the market signal is clear: identity programmes still overestimate their control coverage. Teams that formalise baseline hardening and exception expiry will be better positioned as Microsoft 365 continues to absorb more identity, device, and collaboration trust.

For practitioners

• Review tenant defaults as if they were active permissions Audit Entra, Intune, Defender, Teams, and Exchange baseline settings together, then document which defaults intentionally remain open and why.
• Block device code flow unless you have a hard business exception Disable the OAuth device code sign-in path tenant-wide, and require an explicit approval and monitoring pattern for any workflow that still depends on it.
• Remove broad sender and connection allow lists Replace blanket allowed domains, safe lists, and static IP exceptions with narrowly scoped controls that are reviewed and logged as trust exceptions.
• Tighten device and MFA registration gates Require managed devices for both authentication and MFA registration, and limit device join to approved users or groups only.

Key takeaways

• Microsoft 365 default settings can silently grant device, MFA, email, and collaboration trust that attackers can turn into access.
• The upgrade to CIS v6 matters because it covers the control gaps that let legitimate flows like OAuth device code and allow-listed mail bypass tenant defenses.
• Security teams should treat exception cleanup, managed-device enforcement, and cross-plane review as core identity governance work, not optional tuning.

Key terms

• Device Code Flow: An OAuth authentication method designed for devices that cannot complete a normal browser login. In abuse cases, it lets an attacker separate the user from the trusted device while still obtaining tokens, which makes it a phishing and token-theft concern rather than a password problem.
• Trust Amplification: A condition where a small identity or policy exception expands into a much larger attack path after compromise. In Microsoft 365, broad allow lists, unmanaged device enrollment, and default external access settings can multiply the effect of one stolen credential or one trusted sender.
• Conditional Access: A policy layer that decides whether authentication should succeed based on device state, risk, location, or other context. It is only effective when the tenant's device and enrollment rules are aligned with the access policy, otherwise the control boundary becomes inconsistent.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: Microsoft 365 posture gaps and CIS v6 control updates. Read the original.