RMM Platform Pricing Models and Feature Coverage

This post documents the pricing models used by major RMM platforms, what each platform's base price includes, what is sold as an add-on, and the published feature coverage of ET Ducky.

Kaseya VSA Pricing in 2026 and What to Expect

Kaseya does not publish VSA pricing; every quote runs through a sales conversation, which is exactly why it is hard to find a straight number. Based on community reporting, Capterra and G2 reviews, and industry analysis as of Q2 2026, here is what buyers actually report paying:

• Kaseya VSA: roughly $3 to $6 per device per month, billed per endpoint, with volume discounts negotiated around 100, 500, and 1,000+ endpoints.
• Implementation: a one-time onboarding or services fee is commonly required, typically $1,000 to $10,000+ depending on fleet size.
• Kaseya 365: a per-technician bundle packaging VSA with EDR/AV, SaaS backup, and other modules at roughly $299 to $399 per technician per month.
• Contract terms: Kaseya ended high-watermark billing in late 2025; advanced modules still sell separately, so the base per-device rate is rarely the all-in cost.

These are estimates, not list prices. The actual quote depends on fleet size, term length, and module mix. Use the cost estimator at the top of this page to model your own fleet, see the full platform breakdown for how Kaseya VSA compares to NinjaOne, ConnectWise RMM, Datto RMM, Atera, Syncro, and ET Ducky, or read the dedicated Kaseya VSA pricing guide for the full per-device, implementation, and Kaseya 365 breakdown.

Pricing models

Per-device pricing is used by NinjaOne, ConnectWise RMM, Datto RMM, and Kaseya VSA. Costs scale linearly with fleet size, with volume discounts at roughly 100, 500, and 1,000+ endpoints. These vendors do not publish their rates publicly; quotes require a sales conversation.

Per-technician pricing is used by Atera and Syncro. Pricing is per seat regardless of endpoint count. SuperOps.ai uses the same model with published pricing around $119 to $199 per technician per month. Kaseya offers Kaseya 365, a per-technician bundle packaging VSA with EDR, backup, and other modules at roughly $299 to $399 per technician per month.

Hybrid model. ET Ducky uses a flat monthly subscription that covers a base query allowance and 20 managed agent seats per subscribed user. Additional agents are $5 per month on shared infrastructure, dropping to $4, $3, and $2 at higher tiers. Data retention is a separate per-agent add-on.

What Each Platform Includes and What Costs Extra

Feature Matrix

The matrix below shows what's included in each platform's standard pricing versus what requires an add-on or a higher subscription level. An add-on means the feature exists but costs extra. A tier means it's included only above a certain plan. For ET Ducky, every feature is available at all paid tiers.

ET Ducky Data Retention Tiers

Data retention controls how long cloud-stored ETW events, health metrics, correlation analyses, and session data are kept before automatic purge. The 14-day default is free for all organizations, and add-on tiers are billed per managed agent per month across the fleet. Annual billing saves 15%.

Data sources

Standard RMM agents poll WMI health counters at 30 to 60 second intervals and forward Event Log entries. WMI returns sampled snapshots at the poll interval. Event Logs record what applications choose to log.

Event Tracing for Windows (ETW) is the kernel's event subscription infrastructure. A Windows server under moderate load emits 10,000 to 100,000 ETW events per second. ET Ducky processes this stream on the agent, correlates related events into summary records, strips PII locally, and reports a 99.6% reduction in bandwidth compared to raw ETW.

An ET Ducky correlation summary for a CPU anomaly contains the contributing kernel-level events. Example output:

"CPU exceeded 90% on SERVER-12 because the .NET garbage collector ran a full Gen 2 collection lasting 4.2 seconds, triggered by WorkerService.exe exceeding its 2 GB heap limit."

The other platforms in this comparison do not subscribe to ETW providers.

ET Ducky feature coverage

Auto-generated KB documentation

The agent recorder captures the ETW event stream while an admin performs a procedure, uses an AI description of the goal to filter background events, and produces a Markdown KB article with numbered steps. Screenshots taken with a global hotkey (default Ctrl+Shift+S) are embedded inline. IT Glue (Kaseya) and IT Boost (ConnectWise) are separate documentation products that require manual authoring.

Security posture in heartbeat

The heartbeat includes 35+ metrics, among them a security snapshot. The snapshot covers Defender real-time protection status and definition age, Windows Firewall state, BitLocker encryption, UAC configuration, and Secure Boot state. The metrics are queryable in the Data Explorer and available to Smart Reports. NinjaOne and Kaseya bill separately for security dashboards. Atera requires a Bitdefender add-on. Syncro does not include native posture reporting.

Behavioral detection

ET Ducky does not include a signature-based AV scanner. The agent includes an always-on behavioral monitor that runs on a separate ETW kernel session from diagnostic collection. The monitor watches for file encryption sweeps, mass renames to ransom extensions, ransom-note file patterns, shadow copy deletion, backup service sabotage, suspicious process ancestry chains, and crypto-miner behavior, with a kill-chain meta-rule that escalates when two or more ransomware components appear within five minutes. When a pattern crosses a High or Critical confidence threshold, the agent applies network isolation by adding Windows Firewall rules that block all traffic except to etducky.com. De-isolation requires dual approval. A dashboard operator initiates the request and the physically logged-in user must confirm via a desktop popup.

Cross-platform agent

The agent ships as an MSI for Windows and as .deb, .rpm, or universal .run for Linux. Enrollment is one command on either OS. The dashboard treats both operating systems uniformly, with the same agent table, metrics, query language, AI live sessions, and behavioral rules. Among the seven platforms compared, ConnectWise and Kaseya offer Linux support; neither runs the same agent and diagnostic stack across operating systems.

The behavioral rule engine runs on both operating systems against the kernel-event stream (ETW on Windows, eBPF on Linux). Ten rules ship today, covering suspicious exec chains, mass file access, mass file rename, ransom-note patterns, shadow copy and backup deletion, a reverse-shell heuristic, privilege escalation from a non-interactive parent, unusual outbound traffic from a system daemon, a crypto-miner heuristic, and a ransomware kill-chain meta-rule that fires when two or more components appear within five minutes. Two further rules, fleet baseline deviation and approved-app hash mismatch (both described below), run as cloud-side fleet analytics rather than on the agent. Detections appear in the dashboard with the triggering events attached as evidence.

The Linux agent runs unprivileged as the etducky user under a hardened systemd unit. Privileged actions follow an operator-driven model. When the AI generates a sudo command, the dashboard prompts the responsible operator for the host password at the moment of the action. Each elevation produces an immutable audit row covering operator identity, source IP, command summary, and exit code.

Fleet behavioral baselines

Beyond the fixed rules, the agent summarizes how each application actually behaves — process activity, file and network patterns — into compact 15-minute rollups that ride the heartbeat on both Windows and Linux. The cloud folds those rollups into a per-app behavioral profile built from your own fleet, then flags the host where an app's behavior is an outlier against that baseline. That is the copy of a line-of-business app that suddenly starts touching files or making connections its siblings never do. The rule ships default-off and runs in shadow mode first, so an organization can review what it would have flagged and tune before detections go live. Signature databases can't do this; the baseline is derived from how the software behaves in your environment, not a vendor's.

Approved-app binary integrity

Organizations can maintain an approved-applications list, and the agent reports a SHA-256 of each installed app's primary binary as part of software inventory — on Windows, and on Linux for rpm and dpkg packages, where the agent hashes the on-disk binary itself rather than trusting the package database (so a tampered file can't present a pristine install-time digest; snap and flatpak are excluded as immutable signed images). The cloud keeps a per-organization ledger of every hash seen per app, version, and architecture. The first time an approved app appears, its hash becomes that organization's trusted reference; if the same app and version later shows up on any host with a different binary hash, ET Ducky raises an approved-app hash mismatch detection — exactly once per divergent hash — and can fire an automation. That's the supply-chain and tampering case. It covers a repackaged installer, a trojaned update, or a swapped binary on one machine in the fleet. References never cross organization boundaries, the rule ships default-off with a shadow mode for tuning, and the full hash ledger is queryable.

Custom reports over the security and inventory data

All of this lands in queryable, org-scoped datasets rather than a closed dashboard. Smart Reports takes a natural-language question — "apps flagged for wrong hashes in the last 30 days," "unacknowledged high-severity detections by server" — plans it against the schema, and renders the result as a chart or table you can pin to a report. The same datasets are browsable in the Data Explorer. They cover behavioral detections, the binary-hash ledger, fleet baseline profiles and observations, anomaly inflections, observed indicators of compromise, org-wide application inventory, and the application install/remove/upgrade event history, alongside the existing health and hardware metrics. Detection-adjacent automations extend past tickets, too. Triggers fire on security detections, app installs and removals, app behavior deviations, approved-app hash mismatches, and catalog version updates.

On-demand event upload

Aggregate health metrics ride the heartbeat. Inflection-bracketed evidence ships alongside a metric anomaly. Behavioral detections ship with their triggering events. The full kernel-event stream is not uploaded by default. When an operator opens a live session or issues an explicit collection command, a reference-counted upload gate opens for the duration of that work. The full kernel-event stream ships while the gate is open and stops when it closes.

Anomaly-triggered diagnostics

The agent runs an inflection detector after every heartbeat. When a metric changes significantly (for example CPU jumping 25 points, available memory dropping 500 MB, disk queue spiking from 1 to 10+, or network throughput up 10x), the agent flushes the buffered ETW event window to the cloud. The events from the anomaly window are submitted for correlation, and the cloud marks the heartbeat row with the detected inflections.

Distribution Servers for governed LAN file distribution

Most RMMs include a way to cut WAN bandwidth by caching deployment payloads on the local network. NinjaOne offers patch caching, where a designated Windows device serves downloaded patches to its neighbors. Datto RMM has a component cache (a nominated device stores downloaded components and serves the site over port 13229). N-able N-central uses a patch/probe cache via its Patch Repository Service, including caching patches and agent files at remote sites. ConnectWise Automate can cache Windows Update files to a per-location network share. These are effective, and they are table stakes — the bandwidth-saving idea is not unique to any one platform.

What they have in common is also their limit. Each caches the RMM's own artifacts (patches, software components, agent installers) as an internal optimization. None is a user-facing file share — you can't map it as a drive, put arbitrary files in it, or grant a specific person read-only access to one folder.

ET Ducky Distribution Servers are a different category. An agent becomes a LAN-local hub that serves a mountable file share over WebDAV/HTTPS for arbitrary organization files, governed from the cloud:

• Per-path, per-principal access control — grant list/read/write/delete to everyone, a role, or one user, on a path or glob; rules are re-evaluated live, so a change reaches existing mounts without re-issuing anything.
• Opaque, revocable mount keys as the credential — salted-hashed at rest, scoped to the grant, and cut off instantly on revoke.
• Data residency by design — the cloud is only the control plane (catalog, access rules, audit). File bytes move directly between the client and the hub on the customer's own infrastructure and never traverse the ET Ducky cloud.
• LAN today, optional WAN reach — off-LAN devices can mount the same share through customer-side reachability (STUN/UPnP/manual port-forward), with certificate distribution handled from the dashboard.

Patch management with kernel-verified rollout

Patch management is now native to ET Ducky for both Windows and Linux from a single policy engine. It drives winget and Windows Update on Windows; apt, dnf, zypper, snap, and flatpak on Linux; plus vendor patch scripts for anything a package manager can't reach. The same policies, maintenance windows, deferral rules, and exclusions drive OS and application updates alike, so you set intent once and the agent executes it.

Third-party apps outside the package managers are handled by the Software Catalog. Type any application name into its search box and winget plus your Linux fleet inventory answer first; for apps neither tracks, an AI web search finds the official vendor download, version, and metadata. AI-resolved entries land in a needs-review state and can't deploy until verified, installers are checked for EV code signing and a SHA-256 manifest match before they execute (fail-closed), and tracked apps fire a catalog_version_update automation trigger when the vendor ships a new release.

Every other platform in the matrix above ships patch management — it is table stakes. The difference is what happens after the installer exits. Most RMMs mark a patch "succeeded" on exit code 0 and discover the breakage when users call in. ET Ducky pairs each install with post-patch verification drawn from the same kernel event stream the agent already runs. It checks whether critical services came back up, whether the patched application is crash-looping, whether CPU/memory/disk baselines deviated, and whether any behavioral rule fired before allowing the patch to spread.

That verification gate drives a staged ring rollout. A new version reaches a canary ring first, soaks for a configured window, and promotes to the next ring only if the health signals are clean. A regression pauses the wave automatically, captures which service failed, and — where the package manager supports it — rolls the patch back; otherwise the job is flagged for manual rollback rather than silently left broken.

Time tracking and billing

ET Ducky now includes the time-to-invoice loop MSPs otherwise buy a PSA for. Time entries come from three sources, a start/stop timer, manual entry, and auto-capture, where finishing a live session, remote desktop session, shell session, or file transfer creates a draft entry attributed to the technician who ran it. The platform already knows how long a tech actually spent connected, so entries write themselves from session telemetry and the tech confirms rather than reconstructs their day. Classification rules in the automation engine flag captured entries billable, non-billable, or logging-only by source, technician, agent, or duration.

Entries roll into weekly timesheets with a submit-and-approve workflow. Approval snapshots each entry's hourly rate, so later rate changes never alter past invoices. A designated billing approver can turn approved billable time into a draft invoice in the organization's own Stripe account (hours × rate per category, idempotent, never auto-finalized or charged), or push it to any PSA through a signed webhook. Rates, roles, and invoices are all per organization, which maps directly onto an MSP running each client as a managed org. Setup steps are in the time tracking and PSA billing documentation.

Out-of-band hardware management

Business-class machines carry a management controller (Intel AMT/vPro, DASH, or IPMI) that runs below the operating system, so a technician can power-cycle a host or open a serial console when it is off or unresponsive. ET Ducky reaches these controllers through a gateway on the local network, either a dedicated device or a regular agent with the gateway role enabled. On a host whose vPro is present but unconfigured, the agent handles host-based Intel AMT provisioning locally, without a certificate or firmware access. Setup and eligibility are covered in the Out-of-Band Management documentation.

Frequently asked questions

Can ET Ducky find and update third-party applications with AI?

Yes. The Software Catalog's search box takes any application name; winget and the organization's Linux fleet inventory answer first, and an AI web search finds the official vendor download for apps neither tracks. AI-resolved entries require review before deployment, and installers pass fail-closed code-signing and hash checks before executing.

Which features are locked behind higher tiers?

None. Every ET Ducky feature is available at every paid tier; Professional, Business, and Enterprise differ only in monthly AI query allowance. Extended data retention is a separate per-agent add-on available at all tiers.

Does ET Ducky support macOS or mobile devices?

No. The agent supports Windows (10/11, Server 2016+) and Linux (.deb, .rpm, and a universal .run installer). macOS, iOS, and Android are not supported.

What is the difference between per-endpoint and per-technician RMM pricing?

Per-endpoint (per-device) pricing charges for every agent you deploy, so cost scales with fleet size; NinjaOne, Datto RMM, ConnectWise RMM, and Kaseya VSA use this model. Per-technician pricing charges a flat fee per seat with unlimited endpoints; Atera and Syncro use this model. Per-endpoint bills grow as you add devices, per-technician bills grow as you add staff.

Is per-endpoint or per-technician pricing cheaper?

It comes down to the ratio of endpoints to technicians. As a rough 2026 benchmark, per-endpoint platforms run $2 to $6 per device per month and per-technician platforms run roughly $129 to $219 per seat per month, so the break-even sits near 50 to 80 endpoints per technician. A two-person team managing 800 endpoints pays around $300 to $440 per month on per-technician plans versus $1,600 to $4,800 on per-endpoint plans; a ten-person helpdesk managing 300 endpoints usually does better per-endpoint. Run your own numbers in the calculator above.

Summary

The calculator above produces per-platform monthly cost estimates for a given endpoint count and technician count. Per-device platforms scale linearly with endpoints. Per-technician platforms are flat per seat regardless of endpoints. ET Ducky's hybrid model combines a per-subscriber fee with per-agent overage and an optional per-agent retention add-on.

Among the platforms compared, ET Ducky is the only one that subscribes to ETW providers and ships the additional ETW-derived capabilities (KB documentation generation, behavioral detection, fleet behavioral baselines, approved-app binary integrity, anomaly-triggered diagnostics, and natural-language reporting over the resulting data).