Managed ESPM

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.

As part of ESPM, it would be great to be able to lock down USB ports on devices. It's a feature that many MSP's have asked me about

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!!!

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.

When a machine is isolated by Huntress, approved RMM tools should still be able to connect when explicitly allowed by policy. However, access should not be granted based only on the RMM tool being approved. To add another layer of protection, Huntress should verify both the technician’s identity and the trust status of the device initiating the remote session before allowing access to an isolated endpoint. Proposed Behavior -- Remote access to an isolated machine should only be allowed when all of the following conditions are met: Approved RMM Tool -- The remote access application must be listed as an approved RMM tool under RMM Guard or Application Control policy. Trusted Technician Device -- The device initiating the remote session must: Have the Huntress agent installed Be actively enrolled and checking in Be associated with the same Huntress account, organization, tenant, or site Meet any required health or compliance checks Authorized Technician: The user initiating the session must Be a valid Huntress user or authorized agent within the account Have access based on assigned role, organization, tenant, or site permissions Session Logging and Auditing: Huntress should log all remote access attempts to isolated machines, including: Technician identity Source device Target isolated device RMM tool used Source IP address Session start and end time Approval or denial status Huntress should also learn normal remote access behavior over time. If an access attempt appears unusual, such as coming from a new device, different IP address, unexpected location, or abnormal time of day, Huntress should require additional approval before allowing the connection. For example, Huntress could send an approval request by text message to predefined contacts either a general list or by assigning techs to specific huntress endpoints so a text only goes out to the user attached to the endpoint. The recipient could approve or deny the session by replying: YES to allow the connection NO to block the connection This would help prevent unauthorized RMM access to isolated machines while still allowing approved technicians to respond quickly when remote remediation is needed. This would also be great in general for non isolated machines.

Please implement a workflow for Managed ESPM that allows end-users to request approval when they encounter an execution block while in "Enforce" mode. Users should be prompted to provide a justification for their request, which should then trigger a ticket in our PSA to review and approve.

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?

Currently ESPM is not dropping tickets. It would be good to have notification at least when a new RMM is found that needs a decision made.

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.