Defender is genuinely good at what it does. The gap is not a weakness in Microsoft’s product — it is a structural consequence of where each control sits.
Every managed service provider has had this conversation. You propose adding phishing protection, and the client says: we already pay for Microsoft 365 E5, we have Defender, we are covered.
It is a reasonable objection, and the honest answer is not that Defender is bad. Defender for Office 365 is a capable product, and Defender for Endpoint is one of the better EDR platforms available. The gap is not about quality. It is about position.
Think about the sequence of a credential-phishing attack, and where each of your existing controls gets a chance to intervene.
The email arrives. Defender for Office 365 inspects it, checks the sender, detonates attachments and rewrites links through Safe Links. If the message looks like a known campaign, it never reaches the inbox. This works well — against messages that resemble something already seen.
The user clicks. Safe Links checks the destination at click time against reputation data. If the URL is known bad, the user is stopped. If the domain was registered forty minutes ago and has never been reported, there is nothing to match against.
The page loads. This is the moment that matters, and it is the moment with the least coverage. The page renders in the browser. It looks like a Microsoft 365 sign-in screen. The user types their password.
The credentials are used. Now Entra ID sees an anomalous sign-in, and conditional access may challenge it. Defender for Endpoint may see follow-on activity. Both are working — but both are working after the credentials left.
The pattern is consistent: your existing controls are strongest before the click and after the compromise. The weakest point is the few seconds in between, inside the browser, while the user is looking at the page and deciding whether to trust it.
Reputation-based controls need a page to have a history. Something has to be reported, analysed and listed before it can be blocked. That process is fast now — often hours rather than days — but phishing infrastructure has adapted to it. A large share of credential-harvesting pages are live for a short window and are taken down or rotated before they accumulate enough reports to be listed at all.
This is not a criticism of blocklists. It is arithmetic. A control that works by recognising what has been seen before will always have a blind spot for what has not.
Analysis inside the browser does not need the page to have a history, because it can look at the page itself. When the page renders, its structure, branding, form fields and behaviour are all present and can be assessed on first sight. A page that impersonates a Microsoft sign-in screen looks like a Microsoft sign-in screen — that is the entire point of it — and that resemblance is precisely what makes it detectable.
The practical result for a managed service provider is that the most common incident class in your queue — a user who entered credentials on a convincing page — largely stops arriving. Not because your other controls got worse, but because something is now watching the one moment they cannot see.
Avoid framing this as a Microsoft shortcoming. Clients who have invested in E5 do not want to hear that their investment was wrong, and they are right not to want that — it was not wrong.
The framing that lands is layered defence, which most clients already accept in other contexts. They have a firewall and endpoint protection. They have backups and replication. Nobody argues that one makes the other redundant. Browser-layer protection is the same logic applied to the phishing kill chain: email filtering catches what it can, identity protection catches what it can, and the browser covers the gap in the middle.
If you want to make it concrete, the demonstration is short. Open a phishing page that is live but not yet listed, and show what each control does. Defender permits it, because it has nothing to match. The browser layer flags it, because it can see what the page is.
For an MSP, the commercial argument follows the technical one. Browser-layer protection is not a replacement line item competing with an existing budget — it is an addition that does not require the client to remove anything, re-architect anything, or change their mail flow. That makes it one of the easier security services to add to an existing managed agreement, and one of the easier ones to justify at renewal, because the reporting shows exactly what it prevented.
A short introduction covering multi-tenant management, deployment and how the partner model works.
Book a partner introduction →