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.

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. ```

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

Hi Huntress, i noticed that when filtering through RMM tools the total number of assets with an RMM installed does not display but only the most recent. It would be beneficial to query or be able to view all endpoints with a specific RMM tool installed, so if thier is 20 endpoints with a RMM tool installed being able to see all 20 and not those seen only in the last 30 days. Also being able to approve specific assets for licenced RMM tools like Teamviewer would be a useful feature. Therefore any endpoint not with a licence can be rejected, so not just rejected the RMM tool as a whole but having the granular option to reject or approve at endpoint level

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.

Ringfencing for New or Unapproved Scripts, RMM Tools, and Trusted Applications I would like to see Huntress add a ringfencing-style feature, similar to what ThreatLocker offers, especially for scripts, automation tools, RMM agents, and trusted applications. The goal would not be to block every script or break known-good applications. Instead, Huntress could use the application, script, and behavior data it already gathers to allow known and approved activity, while applying restrictions to anything new, unknown, changed, or unapproved. ## Main Idea Known applications that regularly use scripts or automation could be exempted from strict ringfencing if Huntress has already learned that behavior or if an MSP has approved it. For example, approved RMM agents, remote support tools, backup software, security tools, and line-of-business applications should be allowed to continue normal activity when their behavior matches what has already been approved or learned. However, if a new script, changed script, new child process, new internet destination, or unusual behavior appears, Huntress could automatically place that activity into a restricted mode until it is reviewed. ## Why This Matters Many legitimate tools use PowerShell, CMD, batch files, MSI installers, EXEs, or other scripts as part of normal operation. These tools are necessary for MSPs and IT teams, but they are also powerful enough to cause major damage if abused or compromised. A trusted application should not automatically have unlimited access to the system. If it starts doing something new or unusual, Huntress could restrict that behavior, alert the MSP, or require approval. This would help reduce the risk of script abuse, RMM abuse, supply chain attacks, and compromised trusted tools. ## Suggested Ringfencing Triggers Huntress could apply ringfencing when: A new script runs for the first time A known script is modified A trusted application launches an unusual child process PowerShell runs with suspicious arguments A script tries to download files from the internet A script contacts a new external domain or IP A script attempts to access credential stores, browser data, backups, or sensitive files A script attempts to modify or disable security tools An RMM tool runs an unapproved script An application accesses folders or resources it does not normally use ## Suggested Ringfencing Controls When something is new, changed, or unapproved, Huntress could temporarily restrict it by: Blocking internet access unless approved Allowing access only to approved domains or URLs Limiting scripts to approved folders or working directories Blocking access to sensitive system locations Blocking credential store or browser data access Preventing unexpected child processes Preventing trusted tools from launching untrusted applications Blocking security tool tampering Blocking unauthorized startup, scheduled task, service, or registry changes Requiring technician approval before allowing new behavior ## Known Application Exemptions A key part of this feature would be allowing exemptions for known-good activity. Exemptions could be based on: Application name Publisher File hash Script hash Install path Parent process Expected child processes Expected command-line behavior Approved network destinations Huntress reputation or verification MSP approval Organization, group, or device policy This would help avoid unnecessary disruption while still protecting against new or unusual behavior. ## Approval Workflow When Huntress sees new or risky behavior, it could generate an approval request showing: Application or script name Publisher File path and hash Script hash Parent and child process Device and logged-in user Organization/site What the process is trying to access Internet domains or IPs being contacted Huntress reputation or risk level Whether Huntress has seen this before Recommended action Technicians could approve or deny the activity from the Huntress portal, SMS/text message, email, or a mobile app. ## Policy Ideas Possible policy options could include: Monitor only Alert only Ringfence unknown applications Ringfence unknown scripts Ringfence changed scripts Ringfence new child process behavior Allow known-good Huntress-verified activity Exempt approved applications or scripts Require approval for new behavior Require approval for script internet access Require approval for sensitive system access Apply policies at the organization, group, or device level ## Benefit This would allow Huntress to treat known-good activity differently from new or unapproved activity. Approved applications and scripts could continue working normally, while new, risky, or unexpected behavior would be restricted until reviewed.

Application Control: Organization-Wide and Granular Approved Apps I would like to see Huntress add more advanced Application Control functionality that allows approved applications to be managed at multiple levels. ## Requested Approval Scope It would be very useful to approve or deny applications at different scopes, such as: Entire organization Specific site or company Specific group Individual device This would allow MSPs and IT teams to build a controlled approved-apps list across an organization, while still allowing exceptions where needed. ## Why This Matters This would help organizations move closer to a true zero-trust application control model. Similar to tools like ThreatLocker, it would allow companies to lock down endpoints so that only known, approved, or trusted applications can run or be installed. This would be especially valuable for MSPs managing multiple clients, because each organization may have different software requirements. ## Suggested Workflow When an end user tries to install or run a new application that has not already been learned or approved, Huntress could generate an approval request for designated technicians. That request could include details such as: Application name Publisher or vendor File path File hash Device name Logged-in user Organization/site Huntress verification or reputation status Whether Huntress sees the application as clean, suspicious, or risky Risk level Number of devices in that organization where the application is already installed Optional Huntress-wide telemetry showing how commonly the application is seen across managed Huntress environments ## Approval Options Technicians should be able to approve or deny the application from: The Huntress portal SMS/text message Potentially email or mobile app in the future For example, a text message could be sent to specified technicians with the application details and simple approval options: Reply YES to approve Reply NO to deny ## Policy Ideas It would also be helpful if Huntress supported different policy modes, such as: Audit only / learning mode Alert only Block unknown applications Allow Huntress-verified clean applications Require technician approval for unknown applications Organization-wide approved application list Group-specific approved application list Device-specific exceptions ## Benefit This would give MSPs and IT teams a practical way to prevent unauthorized or risky software from running while still allowing legitimate business applications to be approved quickly. It would also reduce the burden of manually reviewing applications across endpoints and would help improve the overall security posture of managed organizations.

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.

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?