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.
R
Ruben Castello
Chris Bisnett Hi ,
Thanks again for the detailed response.
Thinking a bit more about this, I believe the opportunity for ESPM may go beyond traditional vulnerability management based only on CVEs and vulnerable software versions.
From an MSP perspective, one of the biggest gaps we see in SMB environments is not only unpatched software, but insecure configurations and weak security posture across endpoints.
For example, things like:
- SMBv1 enabled
- UAC disabled or poorly configured
- Windows Firewall disabled
- Excessive local administrator rights
- Lack of LAPS or weak local admin password management
- BitLocker disabled
- Defender disabled or tampered with
- Weak PowerShell security settings
- Office macros allowed from untrusted sources
- Legacy protocols enabled, such as NTLMv1 or old TLS versions
- Insufficient audit policy configuration
- Missing or weak Windows Update controls
In many SMB environments, these issues are more common than sophisticated vulnerabilities, and they are often easier for MSPs to explain and remediate.
So maybe the opportunity is not only to build “vulnerability management”, but a lightweight endpoint hardening and misconfiguration detection layer.
Something inspired by CIS Benchmarks, Microsoft Security Baselines, MITRE ATT&CK techniques, and Huntress’ own real-world incident experience.
The value would be very practical:
- Show which endpoints have risky configurations
- Prioritize the issues that are most commonly abused by attackers
- Explain the business/security impact in simple language
- Track improvement over time by organization
Huntress has strong visibility into what attackers actually abuse in SMB environments. Turning that knowledge into simple, actionable posture checks could help improve security without requiring a heavy enterprise vulnerability management stack.
“Which insecure configurations are putting this customer at risk, and what should we fix first?”
I think this could be a very strong direction for ESPM.
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.