ESPM Vulnerability Management: Dependency on Microsoft Licensing
under review
R
Ruben Castello
Hi team,
First of all, I really appreciate the direction Huntress is taking with ESPM. The concept of Endpoint Security Posture Management fits perfectly with the needs we see daily as an MSP.
However, after reviewing the Early Access requirements, I have a concern regarding the dependency on Microsoft Defender for Endpoint (Plan 2) or similar to enable vulnerability visibility.
From a technical perspective, I understand the decision. Leveraging Microsoft’s vulnerability engine provides deep visibility and avoids reinventing a complex system.
That said, from a commercial and operational standpoint, this creates a significant challenge for MSPs and our clients.
Most of our customers are running Microsoft 365 Business Standard, which does not include Defender for Endpoint P2 or similar. This means that in order to access vulnerability management, they would need to:
- Upgrade to higher-tier Microsoft licenses (E5 or equivalent), or add standalone Defender for Endpoint P2 licenses or Bussines Premium( I dont know if it's included, Microsoft licensing can be difficult to navigate)
- In addition to already paying for Huntress (EDR + SIEM + ESPM)
This results in multiple overlapping subscriptions, which is something many clients are actively trying to avoid. It increases complexity, cost, and friction in sales conversations.
Am I understanding this correctly, or am I missing something?
One of Huntress’ biggest strengths has always been simplicity and delivering strong security outcomes without requiring a complex or expensive stack. This dependency risks diluting that value proposition.
From our perspective, it would be extremely valuable if Huntress could consider developing a native, lightweight vulnerability scanning capability within ESPM, even if more basic, or offering a hybrid approach:
- Built-in vulnerability visibility for standard use cases
- Optional advanced integration with Microsoft Defender for deeper insights
This would allow MSPs to deliver vulnerability management to a much broader client base without forcing additional licensing layers.
We are very excited about ESPM and see strong potential, but reducing dependency on external licensing would significantly improve adoption and overall value.
Thanks for considering this feedback.
Chris Bisnett
marked this post as
under review
Chris Bisnett
I totally understand your perspective where it feels like you need to buy yet another license. The reason we chose to integrate with Microsoft Defender for Endpoint Vulnerability Management was because we have a lot of customers that have Business Premium and are not leveraging it. Pulling in the data to show it alongside the other telemetry we already collect and break it out by Huntress Organization was pretty simple. There are a number of things we think we'll be able to do with this new data and we'll get into that in the coming months.
It's NOT a requirement to have Defender for Endpoint licenses to leverage ESPM. The vulnerability management functionality is just an addon.
Building our own vulnerability management product will be a lot of work and takes a ton of maintenance. It's also very difficult to determine which versions exactly are vulnerable and which version is running on the endpoint. We may build this in the future, but we have other things we think can provide more value in the short-term.
Thanks for the feedback. If you have ideas for how a vulnerability management product could be built differently that would make it better I would love to hear it. We never want to build just another product like all the others. We want to solve some problem that others aren't.
C
Chris Ba
I have the same appreciation for Huntress and the forward-leaning / forward-thinking way to continue securing the endpoitns while not adding more bloat to your agent.
Ruben, I had the same realization when I had ESPM turned on for us. I had not realized it was using a licensed Microsoft Defender for Endpoint license. Between that and requiring Windows Event Logs to be sent to the SIEM are both showstoppers (for now) across our customers.
Chris Bisnett
Chris Ba: SIEM is only required while ESPM is in Early Access. We built it that way because we need events from the Windows Event Log and we were already getting these from SIEM. This allowed us to move fast.
We will be adding functionality to the Agent to capture these specific events and send them up to the cloud in the next few weeks. This will allow us to uncouple ESPM from SIEM and will remove this requirement.
C
Chris Ba
Chris, great to hear! Thank you. I was wondering if that could have been the reason, but glad to hear it is a temporary requirement.