We have been (tryng to) improving the way we handle third party patching with Ninja RMM.

Recently, as a pilot we turned on daily 3PP, and scans and update logs show this is working. Furthermore and most importantly, restart app after update, is ticked in the policy.

Recently, we have been noticing that Chrome, Edge, and Teams, regularly show 'update available' (or vendor specific variations of that), on our computers.

Logs show a scan and update is occurring, so we opened a ticket.

After a few weeks and needing to escalate repeatedly, we were told the system is working as intended. That Microsoft and Chrome have their own update methods, and there is nothing further we can do.

My issues:

1. Having that checkbox ticked, without it actually doing this, is misleading.
2. Until the browser or app is restarted, the code running on the computer is vulnerable code, therefore the update didn't mitigate the risk, that being the entire purpose of patching in the first place.
3. Relying on end users to restart their browsers, is not what we want and part of the reason for running an RMM.

Ninja appears to have washed their hands of this despite it leaving pretty much all partners clients in a potentially vulnerable state unknowingly.

Yes, we can work around it, we can enforce a restart every day, run processes that kill these apps to force them to update, but why should we have to do this? Ninja has a 3PP tool and it should work the way other vendors 3PP do, or at least clearly communicate this.

Full disclosure: I’m a vendor! I also want to make sure you don’t get exploited.

I’m Jeremy, the founder of Automation Theory — and we sell WAFs for MSP tools (primarily the ConnectWise stack, but also other popular on-prem MSP tools). I worked in an MSP for 6 years, was an RMM admin, managed 10,000 endpoints, and then became a niche consultant/vendor.

We’re at the pilot stage with our WAF for N-central.

We use a transparent, in-line reverse proxy with WAF to:

- Remove you from Shodan

- Harden HTTP headers and TLS

- Apply custom access controls

- Block exploits with a real WAF

We’ve been doing this for 6 years for the ConnectWise apps, and I’d like to make sure your MSP isn’t naked on the internet (we can find ~800 on-prem N-central instances at the moment).

Shodan results for N-central on-prem August 4, 2026

The free Cloudflare WAF isn’t what you think it is

This sub popularized using Cloudflare to protect RMMs. It’s better than nothing, but the free version isn’t a real WAF (I kept our security analyst busy for months tuning our offering for N-central — so unless you’ve done that, I’d suggest your security posture might be different). We benchmarked it, and it was sad:

Cloudflare's free WAF benchmark results from Wallarm's GoTestWAF -- 4/2200 isn't a passing score (or what I want to protect me from a zero-day).

I wrote a blog about this (link: https://automationtheory.com/4-reasons-cloudflare-isnt-good-for-msp-tools/), but the free WAF is only looking for a handful of things that are “high severity” threats — and no MSP tool zero-day appears on that list.

What makes our WAF different

In a nutshell, we understand the application architecture, we deep inspect every payload for threats, and we have granular exclusions.

Have you ever seen the /bosh/bosh URL path before in N-central? BOSH is basically the foundation of instant message protocols ( https://en.wikipedia.org/wiki/BOSH_(protocol) ) — so your remote agents are sending instant messages to your N-central server in a roundabout way (it’s kind of enduring). However, catching SQL injection, cross-site scripting, and other exploits in IMs is interesting to say the least!

With the Cloudflare WAF (in most configs), entire paths are opened. For example, /dms2/services2/ServerMMS2 is used for agent signup, and it is open in most configs (because upon registration, the agent creates a payload that is super garbled (application-layer encryption), and breaks the parsing of traditional XML payloads). Instead of opening that whole URL path to the world, we configure our WAF to ignore the payload under a certain set of conditions — so if there was ever a vulnerability in the agent communications, it would still offer effective protection.

It's a bird, it's a plane....it's an N-central agent registration request the WAF can't parse!

In the same vein, we can create granular exclusions for other parts of the app (like the command prompt) so it doesn’t eat the PowerShell you’re trying to push out to your clients, while simultaneously protecting it against XSS and other threats.

We help lots of MSPs sleep better at night — you can find details about our WAF here: https://automationtheory.com/automation-theory/reverse-proxy-and-waf/

Welcome to r/thirdpartypatching! We’re a community dedicated to third-party patching (3PP) in the managed IT (MSP) industry.

The goal of this community is to provide a place for dedicated discussion for third-party patching, separate from the noise of other communities with broader focuses. Common topics of conversation include:

• Tools used for third-party patching
• Headlines about commonly patched applications (browsers, PDF viewers, productivity tools, etc.)
• Relevant industry trends, how-to guides, etc.

If you have questions about RMMs, business practices, etc., then you’re probably looking for r/msp. Likewise, if you’re an individual home user trying to patch your computer, r/techsupport is where you should be.

Be civil, and enjoy the conversation!

-- The Mod Team

Seeking the hive mind's actual experience with third party application patching on Windows (server and/or client) in 2025.

And before everyone throws at me the usual suspects - Patch My PC, winget, chocolatey, Action1, etc - I already know about them. I want to know how you're dealing with all the applications that aren't in their catalogues, because these are the ones that are a pain in the ass to deal with.

Is one of the package managers above better than the others at creating & managing custom catalogue items?

Have you come up with some cool process for internally developed applications?

What are you using to monitor for update compliance (eg: winget has no central reporting/monitoring built-in, are you monitoring reactively via something like Tenable or proactively via SCCM or Intune deployment data)?