Malware detection on Insights, priced beyond the bundle.

The Red Hat Insights malware detection add on licensing describes the entitlement and use rules for the malware detection service that Red Hat offers as an extension to the included Insights bundle. The service deploys a YARA based signature scanner on the Insights connected host, runs the scanner on a scheduled or on demand basis against the host file system, and reports any signature matches to the hosted Insights service for aggregation, alerting, and reporting. The detection logic is signature based rather than behavioural; the value proposition is the curated Red Hat signature set and the platform integration rather than novel detection technology. The sibling treatment of the broader Insights residency reading sits in the Insights data sharing implications note.1

The entitlement reading is add on rather than bundle. The standard Insights bundle delivered with the RHEL subscription does not include malware detection; the service requires a discrete entitlement purchased on top of the RHEL subscription. The pricing model is per managed host and follows the standard Insights add on pricing pattern. A buyer who has enabled malware detection without provisioning the entitlement is running an outside scope feature; the audit reading is exposure on every host where the scanner is reporting findings. The cross reading on the broader Insights add on family sits in the Red Hat Lightspeed for RHEL licensing note.

The relationship to existing endpoint detection products is the buyer side reading that frequently determines the value. Most regulated estates already run a third party endpoint detection product (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Trend Micro, or similar) that performs malware detection across the entire host fleet, not just the RHEL portion. The Red Hat malware add on therefore sits alongside an existing detection product rather than replacing it; the question for the buyer is whether the platform integration value justifies the duplicate scanner footprint. The cross cluster bridge sits in the Red Hat Advanced Cluster Security pricing note, which carries the equivalent reading for the OpenShift side.

Three factors shape the malware detection add on reading at the buyer side.

The first factor is the scope against existing endpoint security. A buyer with a mature endpoint detection product running across the entire estate has the malware detection coverage already; the Red Hat add on duplicates it on the RHEL subset. The discipline is the explicit reading of the existing product's coverage on RHEL hosts and the comparison against the malware add on capability; the result is either a net new value (the existing product does not cover RHEL well) or a duplicate cost (it does). Coverage already in place is not value the add on creates.2

The second factor is the data flow to the hosted Insights service. Every malware finding travels from the host to the hosted Insights service. The detection event payload includes the host identifier, the signature that matched, and the file path the match occurred at; the file content itself is not uploaded by default. The residency reading depends on whether the regulatory perimeter permits the detection event metadata to leave the perimeter. The pattern overlaps with the residency treatment of the broader Insights services. The sibling treatment sits in the Red Hat Insights policies and drift monitoring note .

The third factor is the audit reading on detection events. A malware detection event on a regulated host is a security incident; the audit posture must record the event, the response, and the resolution. The Red Hat hosted Insights service retains the event record on Red Hat's infrastructure; the buyer's audit posture frequently requires the event record to be retained within the buyer's perimeter as well. The discipline is the event export to a buyer side SIEM or compliance archive at the moment of detection. The cross reading sits in the Satellite versus Red Hat Cloud Console economics note, where the management plane choice frames the broader residency picture.

The audit reading on the malware add on walks four artifacts. The Insights subscription record showing the malware add on entitlement, the host inventory of where the malware scanner is enabled, the detection event log from the hosted Insights service, and the corresponding event record in the buyer's SIEM or compliance archive. The reading is internally consistent when every host where the scanner is enabled is covered by the entitlement, every detection event is exported to the buyer side archive, and every event has a documented response.3

The most common audit reading misstep on the malware add on is the scanner enabled on hosts that are not covered by the entitlement. The Insights agent supports the malware module at the host level; if the entitlement is provisioned at the account level but with a host count cap, hosts beyond the cap can still run the scanner and report findings unless explicit policy blocks them. The remediation is the host inventory walk against the entitlement count at the cycle. The discipline overlaps with the treatment in the Satellite capsule server licensing note.

The second misstep is the detection event recorded in the hosted Insights service but not exported to the buyer side archive. The audit posture on a security incident frequently requires the buyer to demonstrate retention inside the perimeter; an event held only in Red Hat's Insights service does not meet that requirement. The remediation is the SIEM integration or the scheduled export at the cycle. The cross reading sits in the Insights compliance and vulnerability reports note.

The renewal posture on the malware add on has three habits.

The first habit is the coverage gap analysis. The buyer enumerates the existing endpoint detection product's coverage on the RHEL estate; any genuine gap (hosts not covered, file system regions not scanned, signature lists out of date) is named explicitly. The malware add on is provisioned only where the gap is real. The discipline sits inside the broader frame of the 90 day subscription assessment.4

The second habit is the duplication audit. A buyer that has both the malware add on and the existing endpoint detection product running on the same hosts reads the duplication cost at the cycle; the renewal decision is either to consolidate to the existing product (drop the add on) or to formalise the dual scanner posture as a defence in depth strategy with documented rationale. The discipline overlaps with the treatment in the recoverable over entitlement cost note.

The third habit is the export discipline. The detection event export to the buyer side SIEM is verified at the cycle; the retention policy on both sides is reconciled; gaps are remediated inside the cycle. The discipline overlaps with the treatment in renewal negotiation.

The malware add on reading sits inside the broader security stack the buyer runs across the estate.

The first trade off is the platform integration value. Detection findings on the Insights service appear alongside vulnerability findings, compliance findings, and drift findings; the integrated view has operational value for the team that manages Insights. A buyer who consumes Insights heavily reads the platform integration as net new value; a buyer who consumes Insights lightly reads it as marginal. The discipline is the explicit reading of the operational team's actual workflow. The pattern overlaps with the treatment in the Insights data sharing implications note.

The second trade off is the signature set. The Red Hat curated signature set is tuned for RHEL; signatures for malware targeting the RHEL platform are present and current. The third party endpoint detection signature set is typically broader (Windows, macOS, Linux generic) but may be less current on RHEL specific threats. The buyer's threat model determines which signature set carries more weight on the RHEL estate. The bridge sits in the regulated industries Red Hat audits note.

The third trade off is the cost. The malware add on per host fee, totalled across the RHEL estate, sets a discrete number that the renewal cycle can compare against the existing detection product's coverage cost and against the value of the platform integration. The buyer who has run the comparison reads the cycle posture with clarity. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.