TL;DR: Default Microsoft 365 settings still let standard users register devices, enroll MFA, and abuse OAuth device code flow, while CIS v6 adds 29 new controls across Entra, Intune, Teams, Defender, and Exchange, according to Abnormal AI. The deeper issue is that tenants treat platform defaults as acceptable until an attacker proves otherwise, which turns unreviewed identity settings into a governance failure.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Abnormal AI's blog post: Default Microsoft 365 tenant settings leave device registration, MFA enrollment, OAuth device code flow, and partner-mail allow-listing exposed unless admins actively benchmark and tighten them.
Why it matters: IAM and security teams need to treat Microsoft 365 defaults as an identity governance problem, because unmanaged platform settings can enable tenant-wide compromise paths even when core controls appear to exist.
Context
Microsoft 365 tenant security is often decided by defaults, not by the controls teams think they have in place. In this case, the risk is not the absence of identity or messaging controls, but the fact that standard users can inherit broad capability from platform settings that were never reviewed.
A secure Microsoft 365 programme therefore has to manage Entra ID, Intune, Teams, Defender, and Exchange as one governance surface. When those settings remain unreviewed, the tenant baseline is effectively whatever the platform shipped, not what the organisation intended.
That matters for IAM and NHI governance because a compromised user account can become a device registration path, an MFA enrollment path, or a messaging bypass path without any separate admin decision being made.
Key questions
Q: What breaks when Microsoft 365 permissions and settings are left unmanaged?
A: Attackers inherit a much larger blast radius. Excessive permissions and risky settings make it easier for a phishing or collaboration lure to become account abuse, data exposure, or lateral movement. When posture management is missing, the environment itself becomes part of the attacker’s pathway.
Q: Why does OAuth device code flow increase account takeover risk?
A: It lets an attacker obtain a valid token through a legitimate Microsoft authentication path without stealing a password or necessarily triggering the victim's normal MFA experience. That matters because the attack targets the session issuance process, not just the credential, so password policy alone cannot stop it.
Q: How should teams prioritise Microsoft 365 hardening work?
A: Start with controls that remove silent trust paths, especially device join, MFA registration, device code flow, and inbound mail allow-lists. Those settings determine whether one compromised account can become a broader tenant issue, so they deserve priority over cosmetic policy tuning.
Q: How can organisations tell whether Microsoft 365 controls are actually working?
A: Look for declining numbers of stale guests, reduced broad-group memberships, faster removal of obsolete delegated access, and shorter exposure windows for sensitive repositories. If those measures do not improve over time, the programme may be producing reports without changing actual access conditions.
Technical breakdown
Why default Microsoft 365 tenant settings create hidden trust paths
Microsoft 365 combines identity, endpoint, collaboration, and mail controls into one administrative plane, but the default posture is not the same as an intentional posture. If standard users can register devices, enroll MFA, or exploit weak collaboration defaults, the tenant has granted trust before governance has evaluated the path. The core technical problem is not a missing feature. It is that multiple control planes are permissive until an admin narrows them, so the attack surface exists at configuration time rather than exploit time.
Practical implication: Treat tenant defaults as untrusted until Entra, Intune, Teams, Defender, and Exchange settings are explicitly benchmarked.
How OAuth device code flow bypasses password and MFA assumptions
OAuth device code flow is a legitimate authentication pattern, but attackers abuse it by moving the user to a separate device while harvesting the token on another channel. That means the password is not stolen, and an MFA prompt may never appear on the victim's device. Once the user completes the flow, the attacker receives a valid session token, which shifts the problem from credential theft to session theft. CIS now treats blocking the device code flow as a baseline defensive control because the abuse pattern survives normal password policy hardening.
Practical implication: Block device code flow where it is not explicitly required, and review any legacy dependence on it as an authentication exception.
Why open device registration and weak email allow-lists widen tenant blast radius
When any user can join a device to Entra ID, the tenant gives an attacker a way to attach unmanaged hardware to a trusted identity. If that is paired with permissive MFA enrollment or weak partner-mail allow-lists, the attacker can move from one compromised account into broader access or delivery paths. The same logic applies to inbound email controls: a blanket allowed domain can prevent scanning entirely, turning trust in a partner relationship into a bypass mechanism. This is governance debt expressed as control inheritance.
Practical implication: Restrict device join, require compliance before trust is extended, and remove blanket inbound allow-lists that bypass inspection.
Threat narrative
Attacker objective: The objective is to turn one trusted Microsoft 365 foothold into broader tenant access, token theft, or mail-bypass capability that evades normal identity controls.
- Entry occurs through a standard Microsoft 365 user account or a partner message path that already has platform trust, rather than through obvious malware delivery.
- Credential or token abuse follows when OAuth device code flow, MFA enrollment, or unmanaged device registration lets the attacker obtain valid access without triggering the expected control path.
- Escalation happens when that access is paired with permissive tenant defaults, allowing the attacker to expand from one identity into device trust, collaboration channels, or mail delivery paths.
- Impact is tenant-level exposure, because the attacker can bypass scanning, establish persistence through trusted settings, and widen the blast radius of the compromise.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Unreviewed defaults are the real Microsoft 365 governance gap. The article shows that the platform's out-of-the-box state can leave device registration, MFA enrollment, and email trust paths open until someone actively benchmarks them. That is not a tooling problem. It is a governance failure in which the control exists but the organisation has never asserted its intended baseline. Practitioners should treat default state as an unaudited security posture, not as a safe starting point.
OAuth device code abuse exposes an authentication assumption, not just a phishing trick. The technique works because many identity programmes still assume the user completes authentication on the same device and in the same session context. Once those assumptions break, password strength and ordinary MFA hardening no longer describe the full risk. The implication is that authentication policy has to account for token issuance paths, not only interactive login events.
Microsoft 365 posture management now sits at the intersection of human IAM and NHI-style trust inheritance. A tenant that allows unmanaged devices, permissive collaboration, and blanket allow-lists is creating reusable trust paths that outlive a single login event. This is where identity governance becomes cross-domain: human user access, device trust, and service-level message handling all shape the same attack surface. Practitioners should govern the full trust chain, not just the account.
Benchmark-driven control coverage is becoming the minimum viable control model for Microsoft 365. CIS v6 matters here because it translates a sprawling tenant into a set of enforceable checks across Entra, Intune, Teams, Defender, and Exchange. That does not mean the benchmark is a substitute for internal risk decisions. It means teams need a defensible baseline before they can even talk about exceptions. The practical conclusion is to measure the tenant against a current standard and then decide where business need justifies deviation.
Named concept: tenant baseline drift. The article is really about the distance between what Microsoft 365 ships, what admins assume is configured, and what the organisation has actually reviewed. That drift is what lets identity, messaging, and collaboration controls remain permissive long after deployment. The practitioner takeaway is simple: if you cannot prove the baseline, you do not know the tenant's real security posture.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
What this signals
Tenant baseline drift: Microsoft 365 defaults can create a security posture that looks configured but has never actually been governed. The practical response is to measure the current state against a current benchmark before you assume the tenant is secure.
Identity and messaging controls need to be assessed together because device trust, MFA enrollment, collaboration, and inbound mail filtering can all become alternate entry paths. When one of those paths is permissive, attackers do not need to defeat every control to widen access.
Blocking device code flow and tightening device join rules are not isolated hardening steps. They are the controls that determine whether a single user compromise stays local or becomes a tenant-wide trust problem.
For practitioners
- Benchmark the tenant against a current CIS baseline Compare Entra, Intune, Teams, Defender, and Exchange settings to a current CIS control set and record which defaults remain permissive. Focus on joins, enrollment, collaboration, and mail-path controls first.
- Block OAuth device code flow where it is not required Disable device code sign-in in tenants that do not have a documented business need for it, and review any exception through a named owner and expiry date.
- Restrict device join and MFA enrollment paths Limit device registration to approved users or groups, require managed-device status before MFA registration, and ensure Intune compliance is enforced before access is trusted.
- Remove blanket inbound allow-lists Replace broad allowed sender domains and static IP allow lists with narrower, reviewed exceptions so partner-mail trust does not bypass scanning entirely.
Key takeaways
- Microsoft 365 defaults can leave meaningful identity and messaging trust paths open even when no one has intentionally created a policy gap.
- The article's core evidence is that CIS v6 adds 29 controls across Entra, Intune, Teams, Defender, and Exchange because the default baseline is not enough on its own.
- Practitioners should govern the tenant as one identity surface, with special attention to device registration, token issuance paths, and mail allow-listing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Device code flow abuse and weak MFA enrollment create authentication bypass paths. |
| NHI-06 — Insecure Cloud Deployment Configurations | Default Microsoft 365 settings leave tenant trust paths open until admins change them. | |
| NHI-05 — Overprivileged NHI | Permissive joins and admin inheritance expand the effective privilege of ordinary accounts and devices. | |
| Recommendation — Block insecure authentication paths that let valid tokens be issued without intended user verification. Audit cloud defaults and close permissive tenant settings before they become attack paths. Limit default access inheritance so a single compromised identity cannot escalate through tenant trust. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about who can register devices, enroll MFA, and bypass mail trust controls. |
| Recommendation — Review permissions and entitlements that allow device join, MFA enrollment, and trusted sender exceptions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MFA enrollment and OAuth session controls are authenticator lifecycle issues. |
| Recommendation — Manage authenticators so enrollment, issuance, and revocation paths do not remain broadly open. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | OAuth device code abuse and permissive device joins support token theft and tenant expansion. |
| Recommendation — Map device code and enrollment abuse to credential access and lateral movement detection coverage. | ||
Key terms
- Tenant Baseline Drift: The gap between the security posture an organisation believes it has and the configuration Microsoft 365 actually enforces. In Microsoft 365, drift often appears when defaults, exceptions, and unreviewed settings persist long enough to become the real operating baseline.
- Device Code Flow: A device code flow is an OAuth pattern for clients that cannot host a browser. The application gets a user code and polling credential, while the user completes login in a separate browser session. In CLI contexts, it shifts risk into token handling and session boundary control.
- Managed Device Requirement: A policy condition that allows access or registration only from a device the organisation has enrolled, assessed, and trusted. For Microsoft 365, this matters because unmanaged endpoints can otherwise become a shortcut around identity controls and extend a compromise beyond the original account.
- Inbound Allow-List Bypass: A mail security weakness where trusted sender or domain exceptions cause messages to skip inspection. In practice, it turns a relationship-based trust decision into a delivery path that attackers can abuse once they gain access to a partner account or a trusted sending domain.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org