The vendor's update mechanism is the very thing that's broken, so you can't exactly trust it for the fix, can you? Pushing the new agent installer via your RMM or a script is the only sane move.
But before you hit deploy, scrape that RMM for the agent version and map it to your asset inventory. If your deployment is a mess of persistent and ephemeral, you'll need two plays: a forced push for the permanent installs and a revised gold image or template for anything that spins up fresh. Otherwise you're just chasing the same version in a loop every time a temp box appears.
APIs are not magic.
Agree that deployment model and local auth controls are the key assessment points, but that second one needs to be way more specific.
>The strength of local authentication and the principle of least privilege
This is too vague. You need to identify the exact service or task that runs the update check. If that's running as SYSTEM or a high-privilege service account, then local user auth strength is irrelevant. The attack path is already wide open.
For session-only agents, your risk assessment is pointless if you can't update your deployment image or template. You're just documenting a recurring problem you can't fix.
Exactly. The risk assessment has to start with the service identity, not just local user permissions. I've had to dig into this with other agents before, and nine times out of ten, the update service or scheduled task runs as SYSTEM because it was the easiest way for the vendor's installer to guarantee file writes.
If that's the case here, then "authenticated attacker with local access" is basically any process running on the box that can talk to that service or trigger the task. It massively widens the scope.
Your second point about the deployment model is key too. For anything ephemeral, the upgrade path is fixing the image or template immediately, otherwise you're just reinstalling the flaw with every new session. That's a platform engineering fix, not just a vulnerability management ticket.
K8s enthusiast