What a Clean Microsoft Tenant Should Look Like in 2026

The 2026 reference model is straightforward: identity, access, devices, data, applications, and administrator roles must have visible ownership, documented controls, and reviewable exceptions.

Clean does not mean every setting is set to maximum restriction. That breaks business processes and drives users to unmanaged tools. Clean means the design is known, exceptions expire, risk decisions are recorded, and controls are applied consistently enough that an auditor, incident responder, or new IT leader can understand the tenant without reconstructing years of history.

Common warning signs are easy to spot: too many permanent Global Administrators, Conditional Access policies named like temporary tests, stale guest users, enterprise applications with high permissions and no owner, shared mailboxes that still allow direct sign-in, Teams and SharePoint sites with inconsistent naming, and sensitive data retained indefinitely.

A clean tenant does not depend on tribal memory. It has an operating model that survives staff turnover.

Identity remains the control plane. If an attacker compromises Microsoft Entra ID, Microsoft 365 becomes a data-access platform.

A clean tenant has few permanent privileged accounts and no routine daily work performed with Global Administrator. Use Microsoft Entra Privileged Identity Management for eligible role assignment, time-bound elevation, approval where appropriate, and justification for sensitive roles. Emergency access accounts should be cloud-only, documented, tested, excluded only from controls that could block emergency use, and monitored with high-priority alerts. Two emergency access accounts is common; a larger set usually signals unclear ownership.

Authentication should be predictable. Require phishing-resistant multifactor authentication for administrators and high-risk roles. Where push notifications remain in use, enforce number matching. Disable legacy authentication and avoid basic authentication exceptions. Security defaults can help small or simple tenants, but mature environments should use Conditional Access as the control design layer.

The unhealthy pattern is exception sprawl: an executive excluded from MFA, a legacy device allowed to send mail with weak authentication, a service account granted Exchange Administrator because a vendor requested it. Each exception may have had a reason; together they create an attack path.

The clean standard: every privileged role has an owner, every exception has an expiry date, and every authentication method is inventoried.

A tenant with 35 Conditional Access policies is not automatically mature. It may simply be hard to reason about.

A clean tenant uses a layered policy model. Baseline policies cover all users: require MFA, block legacy authentication, control session persistence, and apply device requirements for sensitive workloads. Admin policies are stricter. Guest and external-user policies are explicit. Sign-in risk and user risk policies are used where Microsoft Entra ID P2 is licensed. Named locations are maintained as signals, not treated as permanent bypass lists.

Reactive tenants look different. One policy blocks a country. Another excludes a department. Another was created for a migration and never removed. Nobody can answer what happens when a contractor signs in from an unmanaged device in another country to access a confidential SharePoint site.

That question matters. Real attacks often start with one compromised user, one unmanaged endpoint, one stale guest account, one malicious OAuth consent, or one mailbox forwarding rule. Conditional Access should force harder paths: phishing-resistant MFA, compliant device, Microsoft Entra hybrid joined device where appropriate, risk-based challenge, session restriction, or block.

Use report-only mode before broad enforcement, maintain documented emergency exclusions, and review policy impact after major changes. Do not let report-only become a permanent holding area for unfinished security work.

The most expensive tenant problems are often data-exposure problems inside collaboration tools.

A clean Microsoft 365 tenant has a defined model for Teams, Microsoft 365 Groups, SharePoint, OneDrive, and external sharing. Decide who can create teams and groups, what naming convention applies, how projects close, how guests are reviewed, which workspaces require sensitivity labels, whether anonymous sharing links are allowed, and how long externally shared content remains available.

Messy tenants are usually either too open or too restrictive. Too open means anonymous links, unmanaged guests, personal-account sharing, and sensitive files exposed beyond the organization. Too restrictive means users move work to personal email, consumer storage, or unsanctioned collaboration tools. Both outcomes increase risk.

The clean pattern is controlled self-service. Let users collaborate, but apply guardrails: sensitivity labels for sites and groups, restricted or time-limited anonymous links, guest access reviews for sensitive teams, ownerless group remediation, and retention policies aligned to business, legal, and regulatory needs.

Review the signals that usually reveal exposure: Teams with one owner, inactive SharePoint sites, OneDrive content for departed users still shared externally, broad “Everyone except external users” permissions on sensitive sites, and guest accounts with no sponsor. These are not housekeeping issues. They are access-control issues.

Enterprise applications are where clean tenants often become dirty again after identity and Conditional Access are improved.

A mid-market or enterprise tenant can contain hundreds or thousands of app registrations and enterprise applications. Some support real business processes. Others came from pilots, abandoned projects, user consent, or vendor integrations that nobody owns. Some hold application permissions that allow mailbox access, file access, directory reads, or tenant-wide actions.

The clean standard is not to ban integrations. It is ownership and permission hygiene. Control user consent. Use admin consent workflow where appropriate. Review high-impact Microsoft Graph and application permissions such as Mail.ReadWrite, Files.Read.All, Sites.FullControl.All, Directory.ReadWrite.All, and persistent access through refresh tokens. Applications need owners, business justification, credential-expiry management, and sign-in monitoring.

A breach does not always start with password theft. A user can consent to a malicious app, the app can receive persistent access, and the attacker can read mail or files through API access that does not look like normal interactive sign-in. If nobody reviews consent and service principal activity, the breach stays quiet.

In a clean tenant, stale applications are removed, secrets and certificates are rotated before expiry, risky permissions are challenged, and app owners are accountable. If an application has no owner, it has no defender.

A clean tenant is secure, economical, and operable.

License waste is usually visible early in a tenant review: users assigned premium licenses because a group-based licensing rule was never refined, frontline workers licensed like knowledge workers, departed employees still consuming seats, or add-ons assigned to users who never activate the workload. Pricing changes over time, but stale premium assignments can create meaningful recurring waste.

Use group-based licensing, defined license personas, and regular reconciliation against HR status, usage, and role requirements. Do not optimize only for the lowest SKU. Optimize for risk and value. If Microsoft 365 E5, Microsoft Entra ID P2, Microsoft Defender, Microsoft Purview, or compliance capabilities are required, assign them deliberately. If users do not need the workloads or controls, remove shelfware.

Operations matter as much as configuration. Verify that Microsoft Purview audit data is available and retained for the period your risk model requires. Route Microsoft Defender, Microsoft Purview, and identity alerts to people who review and act on them. Treat Microsoft Secure Score as a useful signal, not the goal. During an incident, teams should be able to access message trace, audit logs, Microsoft Entra sign-in logs, administrator activity, endpoint signals, and relevant data-loss or sharing events.

The reference tenant has evidence: architecture diagrams, administrator role review exports, Conditional Access documentation, external sharing settings, guest review results, app consent inventory, license assignment logic, retention policies, and incident response contacts. Without evidence, the tenant is only clean in someone’s memory.