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.
Why This Matters for Security Teams
Microsoft 365 default settings are not neutral. They encode inherited trust, broad self-service, and compatibility choices that can become attack paths the moment a tenant is exposed to phishing, token theft, or over-permissive collaboration. Security teams often focus on mailbox rules or endpoint hardening first, but identity defaults are usually the easier route into persistence. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that identity and access controls should be deliberately governed, not left at vendor defaults. NHI Management Group has also documented how inherited identity exposure and weak governance show up repeatedly across real incidents in the Ultimate Guide to NHIs.
For Microsoft 365, the practical problem is that defaults are designed for adoption speed, not for adversarial conditions. Device registration, MFA enrollment, legacy authentication tolerance, and cross-service trust can all create unintended paths for attackers to enroll, persist, and pivot. In practice, many security teams encounter this only after an initial compromise has already used the tenant’s own default trust paths rather than through intentional hardening.
How It Works in Practice
The safest approach is to convert default settings into explicit control decisions. Start with identity enrollment, then move to authentication methods, then review collaboration trust. A good baseline is to require managed devices for MFA enrollment, restrict who can register devices, and disable weaker authentication methods such as legacy protocols that bypass modern controls. Microsoft 365 admin settings should be treated as policy enforcement points, not convenience features. Current guidance suggests pairing those settings with Top 10 NHI Issues style reviews so that account and workload exposure is assessed together, not in isolation.
- Limit device registration to approved users or devices to reduce unmanaged endpoints joining the tenant.
- Require compliant or hybrid-joined devices before MFA enrollment where business process allows it.
- Disable legacy authentication and other weak methods that do not support strong conditional controls.
- Review Exchange and Teams trust exceptions in the same change cycle so collaboration paths do not remain open after identity hardening.
- Validate admin roles, guest access, and consent settings so default privilege does not become standing privilege.
This is consistent with the NIST identity-centric view of risk management and with incident patterns described in the Microsoft Midnight Blizzard breach, where trust assumptions and identity exposure mattered as much as the initial intrusion. A useful rule is to assume every default that reduces friction also increases reachable surface unless it is actively justified, monitored, and time-bounded. These controls tend to break down in highly decentralized Microsoft 365 environments because different business units keep re-enabling defaults to restore convenience without a common governance standard.
Common Variations and Edge Cases
Tighter Microsoft 365 identity controls often increase help desk load and onboarding friction, so organisations need to balance fast user setup against reduced attack surface. That tradeoff is real, especially in mergers, frontline workforces, and hybrid estates where legacy devices or legacy apps still depend on older sign-in patterns. Best practice is evolving, but there is no universal standard for how quickly every tenant should disable every convenience setting; risk appetite and operational dependency matter.
Some environments cannot disable every default at once. For example, staged migrations may require temporary exceptions for Exchange coexistence, Teams guest collaboration, or older authentication flows tied to business-critical systems. Those exceptions should be time-boxed, documented, and reviewed in the same cadence as identity policy changes. The Ultimate Guide to NHIs is especially relevant here because default tenant risk is often compounded by non-human accounts, service principals, and automation tokens that inherit the same tenant trust assumptions as human users.
Security teams should also watch for a false sense of safety from conditional access alone. If device registration is open, weak auth is still allowed, or guest trust is broad, attackers can often find an easier route around policy than through it. The best current practice is to pair hardening with continuous review, because default settings can drift back into place during migrations, admin changes, or vendor-driven feature rollouts.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access decisions should replace broad tenant defaults. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Default tenant trust paths often create excessive standing access for identities. |
| NIST AI RMF | Risk governance applies when defaults create uncontrolled identity exposure. |
Define explicit identity access standards and review Microsoft 365 defaults as governed access controls.
