A receiver is the intake component in the collector pipeline. It captures telemetry from sources such as applications, endpoints, or agents, then hands that data to the rest of the pipeline for processing and export. Correct receiver selection determines what data enters the observability flow in the first place.
Expanded Definition
A receiver is the intake boundary of a collector pipeline. It defines how telemetry is accepted, normalised at the entry point, and forwarded for later processing, so its scope is narrower than the full collector and broader than a single source integration.
That boundary matters because receiver choice determines the kinds of signals the pipeline can accept, the transport expectations it must satisfy, and the failure modes that appear before any downstream enrichment or export. In practice, a receiver may be protocol-specific, source-specific, or both. A common boundary misunderstanding is to treat the receiver as a passive inbox, when it actually sets the first constraints on trust, format, and operational reliability.
Guidance-vs-consensus note: there is broad agreement that receivers should be selected for compatibility and control, but the exact split between source-specific receivers and shared, multi-protocol intake components varies by platform and deployment model.
Examples and Use Cases
Receivers show up wherever telemetry enters an observability or security data pipeline:
- An application emits logs or metrics to a receiver that understands its transport and payload format.
- An endpoint agent sends events to a collector receiver before those events are parsed and routed onward.
- A network source streams data into a receiver that accepts the protocol and hands it to enrichment stages.
- An organisation uses separate receivers for different source classes to keep intake rules clear and reduce ambiguous parsing.
In NHI-heavy environments, the same pattern can apply to machine-generated telemetry from services, automation platforms, or agents. That makes intake design part of trust design, because a receiver that accepts too much or too little can distort what the rest of the pipeline sees. For an NHI governance lens, OWASP Non-Human Identity Top 10 is useful context when telemetry is tied to machine identities and their activity patterns.
Security Implications
Misconfigured receivers can create blind spots, ingestion failures, or unintended data exposure. If the receiver does not accept the expected source, telemetry may never enter the pipeline, which means downstream detections, audits, or investigations lose coverage before they begin. If it accepts overly broad input, malformed or hostile data can contaminate parsing, trigger operational instability, or create confusion about which events are trustworthy.
Because the receiver is the first controlled entry point, its weaknesses often appear as missing data, duplicate intake paths, inconsistent schemas, or unexpected source drift. Those symptoms are especially important in environments that depend on telemetry for incident response or compliance evidence.
Practitioner observation: intake problems are often mistaken for downstream processing issues, but the real failure is sometimes earlier, at the receiver boundary where source assumptions were never validated.
Domain and Governance Relevance
In collector architecture, the receiver is where governance starts to become operational. It is the point where an organisation decides which data sources are legitimate, how source identity is inferred or trusted, and what intake rules define acceptable telemetry. That makes it relevant to data quality, evidence integrity, and pipeline accountability even when the receiver itself is not a security control in the narrow sense.
For non-human identity environments, receiver design becomes more consequential because machine activity often arrives at scale and can be difficult to distinguish from noisy automation. If receivers are too permissive, teams may inherit unreliable telemetry about service accounts, agents, or workloads. If they are too restrictive, they may lose the activity trail needed to understand machine behaviour across systems. The governance question is not just “can we receive data?” but “which source classes are allowed to enter the trust boundary, and under what assumptions?”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Receiver intake depends on knowing which machine sources are permitted. |
| Recommendation — Inventory telemetry sources and assign ownership before allowing them to feed the pipeline. | ||
| NIST CSF 2.0 | PR.AC-3 — Remote Access | Receivers must control which remote sources can submit telemetry. |
| DE.CM-8 — Vulnerability Scans | Receiver failures surface as missing or malformed telemetry that needs monitoring. | |
| Recommendation — Restrict receiver access so only approved sources can submit data. Monitor intake paths for malformed, missing, or unexpected telemetry patterns. | ||
| CIS Controls v8 | 8.2 — Audit Log Management | Receivers determine whether log and event data enters collection reliably. |
| Recommendation — Protect log intake points so audit data is captured consistently and completely. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
