Most M365 tenants have problems their owners don’t know about.
Not theoretical problems. Real ones — admin accounts with no MFA, audit logging that’s been off for years, legacy authentication sitting open like an unlocked door, licences burning budget for users who left the company in 2022.
We run through the same sequence every time we get access to a new client tenant. It takes 30 to 45 minutes. It has never come back clean.
This is that sequence — what to check, where to find it, and what it means.
Before anything else: document your baseline
Open a notes doc before you touch anything. Record the tenant ID (Entra admin centre → Overview), the date and time, your admin UPN, and the primary domain.
This is your evidence that what you found predated your involvement. You will need it eventually.
Check 1: Security Defaults vs Conditional Access
Where: Microsoft Entra admin centre → Properties → Manage Security Defaults
This tells you the authentication posture of the entire tenant in one screen.
Security Defaults are Microsoft’s free baseline — enforces MFA for all users, blocks legacy auth, no configuration needed. Fine for small tenants. Conditional Access is the enterprise replacement — more granular, requires Entra ID P1 or above (included in Business Premium, E3, E5).
You cannot run both. One or the other.
What you’re looking for:
- Security Defaults on, no CA policies → acceptable for small tenants, but flag for migration if they have P1/P2 licensing they’re not using
- Security Defaults off, no CA policies → document this immediately, this is the worst case
- Security Defaults off, CA policies present → expected, move on
A tenant with Security Defaults off and no Conditional Access has no authentication enforcement. Anyone with a valid password can sign in from anywhere. This is more common than it should be.
Check 2: MFA coverage
Where: Entra admin centre → Conditional Access → Policies + Sign-in logs
Even with Security Defaults on, check actual MFA coverage. You want answers to three questions:
- Does every external sign-in require MFA?
- Do admin roles have a stricter, separate MFA policy?
- What MFA methods are registered — Authenticator app, SMS, phone call?
SMS-based MFA is better than nothing. It is not good enough for any tenant with real security requirements. SIM-swapping is not a theoretical attack. If users are on SMS, put Authenticator app migration on the remediation list.
The gap between licensed users and MFA-registered users is almost always larger than the client expects. Pull that number. It is one of your first deliverables.
Check 3: Break-glass accounts
Where: Entra admin centre → Roles and administrators → Global Administrator
Every production tenant needs at least two break-glass accounts. These are emergency Global Admin accounts that exist outside all Conditional Access policies and MFA enforcement — they are how you get back in if your authentication infrastructure breaks.
They should not be tied to a real person. They should not live in a password manager that requires M365 to log in to. The password should be stored offline, in a physically secure location, and the accounts should have sign-in alerts configured.
What you typically find:
- No break-glass accounts at all → create them before you leave the tenant
- Break-glass accounts requiring Authenticator MFA → defeats the purpose entirely
- A former employee’s account being used as break-glass → replace it
Check the sign-in logs for these accounts. Any recent sign-in that isn’t documented maintenance is worth investigating.
Check 4: Legacy authentication
Where: Entra admin centre → Monitoring → Sign-in logs → filter by Client app
Legacy auth protocols — SMTP AUTH, POP3, IMAP, older Exchange ActiveSync — cannot do MFA. They bypass it entirely. If you have MFA policies targeting modern auth flows but legacy auth is still allowed, those policies have a hole in them.
In the sign-in logs, filter by Client App. Look for “Other clients”, “Exchange ActiveSync”, “IMAP4”, “POP3”, “SMTP”. If there are recent successful sign-ins using these, legacy auth is active.
The rule:
- No legacy auth sign-ins in the last 30 days → safe to block via Conditional Access
- Active legacy auth sign-ins → identify what’s using it before you block anything
It is almost always a printer, a monitoring tool, an old script, or someone on Outlook 2007. Find it, plan the migration, then block.
Blocking legacy auth is one of the highest-impact single changes you can make in any tenant. Password spray attacks overwhelmingly target legacy auth because it has no MFA to defeat. Get this on the remediation plan.
Check 5: Audit logging
Where: Microsoft Purview compliance portal → Audit → Start recording user and admin activity
This one catches people out. Audit logging is not on by default in tenants created before 2019. Any tenant that predates that, or where someone has turned it off, has no record of what has happened.
No admin actions. No file accesses. No email sends. If something happened in that tenant before today, you cannot investigate it.
Turn it on immediately if it is off. One click. It does not retroactively capture events, but from this point forward your audit trail exists.
Check the retention period while you’re here. E3 gives you 90 days. E5 gives you 1 year. If the client has compliance requirements — FCA, ISO 27001, Cyber Essentials Plus — they may need Purview Audit Premium for longer retention. Flag it.
Check 6: Global Admin hygiene
Where: Entra admin centre → Roles and administrators → Global Administrator
In a well-managed tenant, Global Admin is assigned to two to four dedicated admin accounts, not personal user accounts. Those accounts are used only for admin tasks, protected by phishing-resistant MFA, and assigned to named individuals with documented justification.
What you will actually find:
- The IT manager’s day-to-day user account has Global Admin
- A consultant who left two years ago still has Global Admin
- A vendor has permanent standing Global Admin with no expiry
- A dozen accounts have it because someone clicked the wrong role during setup
Work through the list. Note everything that looks wrong. Do not remove anything on day one without client approval — but document every concern with timestamps.
Also check whether Privileged Identity Management is configured. PIM converts standing admin roles into just-in-time access — admins request elevation, it gets approved, it expires automatically. It requires Entra P2 (included in E5 and EMS E5). If the client has P2 and PIM is not configured, that is a significant security improvement to propose.
Check 7: Licence audit
Where: M365 admin centre → Billing → Licences
Licence waste is one of the most consistent findings in any new tenant. You are looking for three things:
Unassigned licences — purchased but not assigned to anyone. Common after redundancy rounds where nobody reviewed the licence count afterwards.
Licences on disabled or deleted accounts — the account is off, the licence is still burning. At scale this adds up to real money.
Duplicate SKUs — a tenant that started on Business Premium, added E3 for some users, then added E5 for others often has overlapping licences covering the same workloads. Not a day-one change, but a conversation to have.
You are not changing anything in this check. You are building a picture that becomes part of your readout.
Check 8: External sharing and guest access
Where: SharePoint admin centre → Policies → Sharing + Entra admin centre → External Identities
Check what external sharing is configured to allow:
- “Anyone” → anonymous, unauthenticated sharing is possible from any SharePoint site in the tenant. This is almost never intentional.
- “New and existing guests” → guests can be invited; links require sign-in
- “Existing guests only” or “Only people in your organisation” → progressively more locked down
Also check Teams guest access, B2B invite settings, and whether there are domain restrictions on who can be invited externally.
Discovering that years of SharePoint files have been shareable via anonymous link is the kind of finding clients appreciate before a third party discovers it. This check rarely requires immediate action but almost always surfaces something surprising.
Check 9: Exchange Online basics
Where: Defender portal → Email authentication + Exchange admin centre → Mail flow
Three things, in order:
DKIM and DMARC. Check DKIM is enabled in the Defender portal under Email authentication. Check DMARC in DNS directly — a missing or p=none DMARC record means the domain is trivially spoofable for phishing. A p=reject or p=quarantine policy with SPF and DKIM aligned is what you’re aiming for.
Mail flow rules. Scroll through transport rules in the Exchange admin centre. Look for anything that bypasses spam filtering, whitelists entire domains, or forwards mail to an external address. These are common signs of misconfiguration or a previous compromise.
Inbound connectors. If there is a third-party email gateway (Mimecast, Proofpoint, Defender for Office P2 with enhanced filtering), verify the connector is configured correctly. A misconfigured inbound connector can allow attackers to bypass Exchange Online Protection entirely by injecting mail directly.
Check 10: Intune baseline
Where: intune.microsoft.com → Devices → Overview + Compliance
If Intune is in scope, four questions:
- How many devices are enrolled, and across which platforms?
- Do compliance policies exist, and are they in enforcement mode or report-only?
- Is Conditional Access linked to compliance state — does a non-compliant device actually get blocked?
- Are there active compliance failures nobody has looked at?
Many tenants have Intune deployed but not enforced. Compliance policies exist, Conditional Access does not reference them, and the result is that Intune is consuming licence spend while providing no actual security gate. This is a full engagement to fix properly. On day one you just need to know which scenario you’re in.
The checklist
| # | Check | Location | Time |
|---|
| 1 | Security Defaults vs Conditional Access | Entra → Properties | 2 min |
| 2 | MFA coverage and method distribution | Entra → CA policies + Sign-in logs | 5 min |
| 3 | Break-glass account existence and health | Entra → Roles | 3 min |
| 4 | Legacy authentication activity | Entra → Sign-in logs | 3 min |
| 5 | Audit logging on and retention period | Purview compliance portal | 2 min |
| 6 | Global Admin count and hygiene | Entra → Roles | 5 min |
| 7 | Licence assignments and waste | M365 admin centre → Billing | 5 min |
| 8 | External sharing and guest access | SharePoint admin + Entra B2B | 3 min |
| 9 | DKIM, DMARC, mail flow rules, connectors | Defender portal + EAC | 3 min |
| 10 | Intune enrolment and compliance enforcement | Intune admin centre | 3 min |
Total: ~34 minutes.
How to structure your findings
By the time you have run through these, you have a documented baseline most clients have never seen in one place. Structure your readout around three buckets:
Fix now: Active risk — no MFA enforcement, audit logging off, legacy auth open with no monitoring, no break-glass accounts.
Fix this quarter: Real gaps but not immediate emergencies — old admin accounts, licence waste, overly permissive external sharing, missing DMARC enforcement.
Improve over time: Maturity work — PIM, phishing-resistant MFA rollout, full Intune compliance enforcement, Purview data classification.
This gives the client a clear sense of priority and gives you a defensible engagement roadmap.
One more thing
The temptation on day one is to start fixing what you find. Don’t.
Changing Conditional Access policies, blocking legacy auth, or removing admin roles without a change control process can break production for users before you have established any trust. Document on day one. Propose changes with client sign-off. Fix in a controlled sequence.
The consultant who documents everything first and then fixes it properly is the one who gets called for the next engagement.
Related reading