M365 Lighthouse for MSPs: What to Check Before the Baselines Go Live
A realistic look at what the platform gets right, where it creates friction, and one thing that will quietly break a client environment if you skip it.
If you manage multiple Microsoft 365 tenants and haven’t looked at Lighthouse seriously yet, the pitch lands well when you do. One console, security posture across all clients, risky user and sign-in alerts without logging into a separate admin center per tenant. That part is accurate.
But the setup guides and feature demos tend to move fast through the part that creates the most real-world friction: what the included security baselines actually do when applied to a client environment that hasn’t been audited first.
That’s the part worth spending time on before anything goes live.
The Legacy Authentication Problem
Lighthouse’s deployment baselines include a Conditional Access policy that blocks legacy authentication. The name sounds routine. The impact is not.
Legacy authentication covers older protocols and auth flows that predate OAuth 2.0, specifically POP3, IMAP, SMTP AUTH, and older Exchange Web Services calls. None of them support MFA. That is the security problem: a client can have MFA fully configured in Entra ID, and a credential spray via IMAP bypasses it entirely, because the connection never goes through a flow where MFA can be triggered. Microsoft’s own position is that most compromising sign-in attempts come from legacy authentication, and that legacy protocols like IMAP, SMTP, and POP3 cannot support MFA, meaning bad actors can bypass enforcement through them. The policy is correct directionally. Medium
The issue is execution order.
Apply the baseline to a tenant without first auditing what is using legacy auth in that environment, and something breaks. Common culprits: printers or multifunction devices configured to use SMTP AUTH for scan-to-email, older line-of-business applications that authenticate to Exchange with Basic Auth, third-party integrations that were never updated to OAuth, and shared service accounts used by automation or scheduled tasks that nobody has touched in years. The authentication attempt fails silently, the device or application stops working, and the ticket comes in with no obvious link to anything that changed.
The Block Legacy Authentication policy appears in Entra ID as a Conditional Access policy, and administrators can set its state (report-only, on, or off) and manage which identities are excluded from it. That report-only mode is the right starting point. Before enforcing anything, pull the Entra sign-in logs and filter the Client App column for “Legacy Authentication Clients.” Every result is a dependency that needs a decision: update it to OAuth, create a targeted exclusion in the policy, or involve the vendor. Run report-only for at least a week per tenant. Watch the logs. Then enforce. Microsoft Learn
The baseline is right. The audit is what makes the rollout not a fire drill at 7 AM.
Other Drawbacks Worth Knowing
Legacy auth is the one with the most immediate blast radius, but the other friction points are worth understanding before you commit to the platform.
GDAP onboarding is slower than it looks. Each client tenant has to actively approve the Granular Delegated Administrative Privileges relationship before Lighthouse surfaces full visibility for that tenant. The setup involves sending relationship requests through Partner Center and walking clients through approving them. For technically engaged clients, that is manageable. For a non-technical office manager who does not recognize what the approval email is asking for, expect it to sit ignored or get flagged as phishing. Build the approval step into a broader onboarding conversation rather than a cold email. Microsoft Learn
Licensing gates the useful features. Full Lighthouse functionality requires Entra ID Premium P1. That comes with Microsoft 365 Business Premium, can be added as a standalone add-on to lower-tier plans, and Entra ID Premium P1 is also required for user account data to appear in reports within Lighthouse. Clients running Business Basic without the add-on get a limited view, mostly tenant visibility and service health. Device management and the threat management pages also require Intune enrollment and Defender Antivirus on endpoints. If a chunk of your client base is on minimal licensing, budget the conversation before you build out the workflow. Dev4Side
Nothing auto-tickets. Lighthouse surfaces findings and leaves them there. A risky user alert across ten tenants sits in the portal until someone looks. If your PSA does not have a native Lighthouse integration (most do not), bridging that gap is a manual workflow or custom alerting build you own.
It is not an RMM. Patch management, agent-level scripting, remote task execution, and automation live in your RMM. Lighthouse operates on the Microsoft 365 and Entra ID layers. The two tools do not overlap much in practice, but the distinction matters when scoping what Lighthouse is actually adding.
Where It Earns Its Place
The multi-tenant security posture view is genuinely useful. MFA coverage gaps, risky user alerts, and device compliance status across all managed tenants in a single dashboard is something you cannot replicate by logging into each admin center individually.
GDAP is now a prerequisite for Lighthouse and a cornerstone of secure multi-tenant management. For all its onboarding friction, GDAP is the right model. The older DAP model gave MSPs broad, persistent global admin access to client tenants with no scope limits, which was a significant security liability. A compromised MSP account had full access to every client. GDAP scopes permissions to specific Entra roles. If your MSP is still on DAP across most of your client roster, the Lighthouse migration accelerates the fix. CIAOPS
Cross-tenant service health is a smaller feature that adds up in practice. All Microsoft 365 service incidents across all managed tenants in one place, no tab-switching. Individually minor, practically useful.
Lighthouse is free to qualified CSP partners; only the MSP needs to be enrolled in the CSP program, not the clients they manage. You are not adding a vendor line item to evaluate it. Microsoft Learn
For MSPs covering specialized verticals, like dental or orthodontic practices running Microsoft 365 for both clinical coordination and admin operations, having security posture and risky user detection aggregated from a single console fills a gap that is harder to justify closing practice by practice. Catching a compromised account or an MFA gap before it becomes an incident matters more in environments with minimal on-site IT.
The Short Version
Lighthouse is worth adding to the stack. The posture visibility is real, the GDAP migration is overdue for most MSPs anyway, and the cost is zero.
Map your legacy authentication dependencies before the baseline goes live. Use the Entra sign-in logs, filter for legacy auth clients per tenant, run the Block Legacy Authentication policy in report-only mode first, and watch what shows up. That step is the difference between a clean rollout and a client down first thing in the morning.
If this was useful, the subscribe button is right below. New posts go out when there’s something worth writing about.
The shorter version of posts like this goes out on LinkedIn first.
Reference links:
Block legacy authentication with Conditional Access (Microsoft Learn)
Microsoft 365 Lighthouse requirements (Microsoft Learn)
Set up GDAP in Microsoft 365 Lighthouse (Microsoft Learn)