Deploying a backup agent to a hundred endpoints is one of the few routine MSP tasks that reliably generates security alerts on every one of them at the same time. It is worth understanding why, because the reflex fix — an exclusion, applied after the alerts start — is the worst available option and the one most people reach for.
The reason is not that backup vendors write sloppy installers. It is that a backup agent installer and an intrusion loader need to do almost exactly the same things.
The behavioural overlap, technique by technique
A typical agent installer performs some combination of the following. Each maps to a MITRE ATT&CK technique that EDR products are specifically tuned to detect.
**Elevating to administrator.** Legitimate, and not itself an ATT&CK technique — service registration and writes to Program Files require it. Worth listing anyway, because elevation is the event that arms the UAC-bypass heuristics (T1548.002) which then evaluate everything the installer does next.
**Fetching a payload from a remote host** (T1105). The installer downloads the agent binaries rather than carrying them.
**Running PowerShell with an execution-policy bypass** (T1059.001). Common when the installer is a script and is not signed.
**Using BITS to transfer the payload** (T1197). BITS is resilient and resumable, which is exactly why intrusion tooling likes it too.
**Creating a Windows service** (T1543.003). The agent has to persist and run as SYSTEM.
**Adding antivirus exclusions** (T1562.001). Many installers do this pre-emptively so real-time scanning does not fight the backup.
Any one of these in isolation is unremarkable. All of them in sequence, within about ninety seconds, on a machine that did not ask for it, is a very good description of a commodity loader. A behavioural engine that did not flag that chain would be a bad behavioural engine.
The single worst pattern, and it is avoidable
Many vendors, ourselves included until recently, offer a one-line installer of the form: fetch a script from a URL and pipe it straight into Invoke-Expression.
It is convenient, and it is the most recognisable malicious PowerShell pattern in existence. It is also worse than it looks, because piping to Invoke-Expression means the script never touches disk — which means Mark-of-the-Web never applies, SmartScreen never evaluates it, and the file provenance machinery Windows built for exactly this purpose is bypassed. Vendors sometimes advertise that as a feature. Your client’s security team will not read it that way.
For a single test machine it is fine. For a fleet rollout, deploy the script as a file through your RMM instead. The RMM is already a trusted, allowlisted execution context on those endpoints, and you drop the most-flagged pattern in the chain for free.
Signing helps. It does not fix this.
It is tempting to assume a code-signed agent solves the problem. It does not, and it is worth being precise about why.
A signature answers "is this binary what the publisher shipped, unmodified". It says nothing about behaviour. An EDR flagging BITS-download-then-service-create is not asking who signed the file; it is asking what the process did. A perfectly signed binary performing that sequence still trips the rule.
We can give a concrete example from our own product. The vendor installer we originally used is signed under an Extended Validation certificate — the strictest grade issued, requiring the CA to verify the publisher’s legal existence and registered address. Microsoft Defender ASR silently terminated it mid-install on certain Windows 10 Home configurations regardless — observed in mid-2026, while Windows 10 was still in the field. The decision was behavioural, not signature-based. We solved it by not running the vendor installer at all: the agent binaries are now deployed pre-extracted, so nothing on the endpoint executes the installer stub ASR was objecting to. Signing would not have prevented it, and any vendor who tells you signing alone solves EDR friction has not tested it.
What signing does buy you is different and still valuable — see the companion article on publisher allowlisting.
What to ask your backup vendor for
Before a rollout, ask for the following. A vendor who cannot produce it has not thought about your environment.
A behavioural walkthrough of the installer, step by step, with a reason for each step.
The expected detections, mapped to ATT&CK, with a recommended disposition for each so your SOC can triage rather than escalate.
SHA-256 hashes for every shipped file, and a verification script you can run yourself against your own trusted root store.
Exclusion configuration for the EDR you actually run — noting that Microsoft Defender exclusions have no effect whatsoever on CrowdStrike or SentinelOne, which are configured entirely separately. This is the step most often missed.
Steady-state behaviour, not just install-time. The agent runs for years after the install alert is forgotten.
A rollout sequence that does not generate an incident
Verify first. Hash the payload, check the signatures against your own trust store, and read the installer script — if it is a script, it is plain text and you are entitled to read it.
Pre-stage exclusions centrally through Intune or Group Policy, for every EDR in the estate, before anything is deployed. An installer that applies its own AV exclusions is doing something your security team would flag if any other software did it.
Pilot on three to five endpoints that represent your estate, including at least one server and one workstation, and watch the console.
Compare what actually fired against the vendor’s expected-detections list. Anything not on that list is worth a phone call before you proceed.
Only then go fleet-wide. A hundred simultaneous installs produce a hundred simultaneous alerts if the exclusions were not staged, and the first thing your client’s security lead will ask is why nobody warned them.