Managed ESPM

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.

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?

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.

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.

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

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.

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