Managed ESPM

OK. This looks like it has the bones to bold on a PAM. Since you guys are working on a phone app and you have ESPM in the works. Can we have this be full blown PAM? That would awesome!!!

Many security and compliance frameworks require organizations to enable and enforce some form of Application Control and to maintain a list of organization-approved applications that can be installed and run. In the many conversations we've had with our partners and prospects, we've found that managing Application Control and maintaining a list of approved applications is a significant burden even for larger teams and nearly impossible for small teams. The journey of starting in audit mode and building a list of approved applications and eventually getting to enforced mode is one that many folks never finish. Our intention is to build a fully managed Application Control capability into the Huntress portal that will allow the Huntress SOC to manage and maintain lists of legitimate applications and will enable our partners to add those applications to approved lists, while maintaining a short feedback loop for end users so they don't get stuck waiting days for security approval. This feature request will act as an umbrella for this functionality. If you are interested in helping us build this out by joining a Private Beta group, please upvote this feature request and we will email members of this group as we open up more spots in the beta.

I’d like to see Huntress ESPM expand into Windows endpoint hardening checks and remediation/enforcement. The idea is to help MSPs baseline and harden devices against common attack paths by validating security best practices such as: Secure Boot status TPM 2.0 status SMBv1 enabled/disabled status Local Security Authority protection / LSASS protected process Virtualization-based Security HVCI / Memory Integrity / Core Isolation Credential Guard Firmware protection Memory access protection / Kernel DMA protection Microsoft Vulnerable Driver Blocklist UAC best-practice configuration Individually, these settings are not a huge deal but together they create meaningful endpoint defense. They also give MSPs a much clearer way to identify endpoints that are technically “protected” by EDR but still poorly hardened at the Windows security configuration layer.

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.

Wouldn't it make more sense to approve tooling based on hash vs "approved installation paths"? For example, a common method for TA is using a trojanized installer from a valid (compromised) source, and installing to a standard location on endpoint. If I approve the install location, then doesn't that open up a potential method for TA to drop into an "approved" location to bypass this tool?

A huge amount of real‑world risk comes from basic endpoint misconfigurations e.g. weakened local security controls: UAC disabled Windows Firewall disabled Insecure RDP settings SMBv1 or other legacy/insecure protocols enabled Bitlocker not enabled Guest accounts enabled Extend Managed ESPM with a managed “endpoint misconfiguration / secure configuration” posture view, focused on a Huntress‑curated set of critical OS and security settings (including examples like UAC, firewall, RDP, AV/EDR, encryption, local admin), with strong reporting so it doubles as both hardening and compliance evidence for customers globally. Many security frameworks and standards (e.g. Cyber Essentials in the UK, NIS2, CIS benchmarks, ISO/27001, insurance questionnaires, etc.) all require secure configuration and proof that basic endpoint controls are enforced. This would further protect and it would give partners/customers concrete evidence for these assessments: which endpoints were out of line, when they were detected, and when they were fixed.

It would be extremely valuable if ESPM could assess endpoint update health based on the operating system build/version. For example, by analyzing the current OS build and comparing it against supported or expected patch levels, ESPM could provide a simple and actionable status such as: Up to date Outdated Severely outdated / unsupported For instance, ESPM could evaluate endpoints based on their OS build and patch level, such as: Windows 10 22H2 (Build 19045.4529) → ✅ Up to date Windows 10 22H2 (Build 19045.3803) → ⚠️ Outdated Windows 10 21H2 (Build 19044.x) → ⚠️ Outdated Windows 10 20H2 (Build 19042.x) → 🚨 Severely outdated / unsupported Windows 11 23H2 (Build 22631.x) → ✅ Up to date Windows 11 22H2 (Build 22621.x) → ⚠️ Outdated Windows 11 older builds → 🚨 Severely outdated / unsupported This would allow MSPs to quickly identify endpoints that are significantly behind on updates or running obsolete versions of Windows, without relying on external tools or additional licensing. Even a lightweight implementation of this would deliver immediate value, helping to highlight basic security hygiene issues and drive remediation actions.

Configure memory dump and recovery options o Enhance security logging in Windows event viewer o Configure web browser developer tools access o Configure Windows registry backup o Disable guest account o CVE-2013-2900 WinVerifyTrust Signature Validation o CVE-2023-36563 MS WordPad Vulnerability o CVE-2023-36884: Windows Search Remote Code Execution Vulnerability Local administrators account i.e. account name administrator, is disabled to prevent account hijacking o Password policies for local accounts are set, including minimum password length, Maximum password age, and meeting complexity requirements. o Password protected screen savers are set for after a specific time frame. o User access control is enforced for prompting whenever something attempts to install or make changes. o Universal plug-and-play (“UPnP”) is disabled to protect against other devices on the network communicating through UPnP. o Autoplay is disabled on removable media drives and/or may be disabled on all drives at Client request. This prevents malicious programs launching from removable media. o Local LAN Manager hash storage is disabled. o All incoming NTLM traffic is audited. o NetBios is disabled. o IPv6 is disabled. o Internet Group Management Protocol (IGMP) is disabled. o Other than the remote desktop services provided by SSC, all other remote desktop services (e.g. Microsoft’s Remote Desktop Protocol (RDP)) are disabled to increase Client’s security and prevent unauthorized remote access to your system.