Managed ESPM

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 valuable enhancement to Huntress Managed ESPM would be the ability to deploy and update approved software through a Huntress-managed repository. By limiting endpoints to software packages that have been validated, digitally signed, and distributed through a trusted source, organizations could reduce exposure to malicious or compromised third-party updates and strengthen protection against software supply-chain attacks. Endpoints could be configured to permit installations and updates only from the Huntress-managed repository, with exceptions controlled through policy. Additional safeguards—such as package integrity verification, application allowlisting, staged deployments, audit logging, rollback capabilities, and administrative approval workflows—would provide greater control while reducing operational risk. This capability would align well with Managed ESPM’s stated focus on endpoint configurations, applications, vulnerabilities, and attack-surface reduction. It would not eliminate supply-chain risk entirely, but it would establish a more controlled and verifiable software-update process.

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

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.

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?

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.

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.

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.

I would like Huntress to add a ringfencing-style feature similar to ThreatLocker. The goal would be to allow trusted tools, programs, and scripts to run, but still limit what they can access or do. ## Why RMM agents, PowerShell, CMD, batch files, installers, remote support tools, and automation platforms are extremely powerful. They can install software, change settings, run commands, and reach the internet. Even when legitimate, they create major risk if abused, misconfigured, or compromised. Ringfencing would help Huntress limit a trusted tool to only the actions it actually needs instead of giving it full system access. ## Huntress Known-Good Profiles A major benefit would be if Huntress could use historical data across all Huntress-protected environments to help build known-good profiles for common programs, scripts, and tools. For example, Huntress could identify commonly used legitimate applications and their normal behavior, such as: Expected child processes Normal file paths Normal script behavior Common install/update behavior Approved publishers Expected internet destinations Typical command-line activity Whether the tool is commonly seen across other Huntress-protected devices Huntress could then offer recommended ringfencing templates or known-good policies for trusted software and scripts. MSPs could enable these Huntress-recommended profiles and still customize them per organization, group, or device. This would make deployment much easier because every MSP would not have to build ringfencing rules from scratch. ## Suggested Controls Huntress could support policies that: Block scripts from accessing the internet unless allowed Allow internet access only to approved domains/URLs Limit scripts to approved folders or working directories Prevent access to sensitive folders, credential stores, browser data, backups, and security tools Prevent scripts from disabling or modifying endpoint protection Block unexpected child processes Block downloaded files from being executed automatically Prevent trusted tools from launching untrusted apps Detect when an approved script starts behaving differently Use Huntress historical telemetry to recommend known-good applications, scripts, and behavior Require approval when a trusted tool performs a new or risky action ## Example A technician runs an approved PowerShell script. Huntress could still check: Is it downloading files? Is it launching another process? Is it touching credentials or browser data? Is it changing security settings? Is this behavior normal for this script? Does this match Huntress-known-good behavior seen across other environments? If the script does something outside its approved behavior, Huntress could alert, block, or pause for approval. ## Benefit This would help protect against script abuse, PowerShell abuse, RMM misuse, malicious child processes, security tool tampering, credential theft attempts, unauthorized downloads, lateral movement, and supply chain-style attacks. The main value is that approved tools would no longer have unlimited access by default. Huntress could also make this easier to manage by using its own historical data to recommend safe, known-good programs, scripts, and behaviors. ```