Operational data sent without effective encryption, even when the application or protocol is not obviously using plain HTTP. It often includes identifiers, configuration values, and security posture details that can help an attacker map assets or infer privileges.
What Cleartext Telemetry Means in Practice
Cleartext telemetry is operational data that travels without effective encryption, even when the application does not look like obvious plain HTTP. The security issue is not only interception, but also the metadata it reveals about assets, configuration, and privilege structure.
This matters because telemetry often sits outside the obvious user-facing path. Engineers may treat it as low sensitivity, yet the payload can still expose hostnames, service names, environment labels, routing details, feature flags, or other context that helps an intruder understand the estate.
Why It Becomes a Security Problem
Unprotected telemetry can leak far more than performance metrics. It may disclose infrastructure layout, health checks, debug values, tenant identifiers, internal endpoints, or security posture signals that reduce the effort needed for reconnaissance and later targeting.
The risk is not limited to hostile insiders or network eavesdroppers. Any intermediary that can observe traffic, including misconfigured proxies, shared networks, or compromised infrastructure, may harvest enough detail to support mapping, privilege inference, or follow-on abuse.
That is why secure transport is only part of the issue. A system can still be effectively cleartext if the data path bypasses protection, if encryption is terminated too early, or if telemetry is copied into logs, brokers, or collectors that are reachable in weaker security zones. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful control catalogue for treating telemetry protection as a confidentiality and monitoring concern, not just a transport issue.
How Organisations Reduce Exposure
The first step is knowing where telemetry flows, where it terminates, and where it is duplicated. Asset inventory, data-flow mapping, and vendor review are essential because cleartext exposure often appears in side channels, agent traffic, or internal service paths rather than in a single visible application.
Organisations should also distinguish between content sensitivity and operational sensitivity. Even if a metric does not contain a password or token, it may still expose architecture clues, naming conventions, or service relationships that are valuable for intrusion planning.
Practically, that means checking collectors, forwarders, sidecars, message brokers, and observability platforms for their transport security posture, then verifying that vendor integrations preserve encryption end to end. Broader governance frameworks such as NIST Cybersecurity Framework 2.0 help organisations place telemetry protection inside identify, protect, detect, respond, and recover workflows rather than treating it as an isolated engineering task.
Detection, Containment, and Hardening Priorities
Cleartext telemetry is best treated as both an exposure and a signal. Security teams should look for exposed collector ports, unexpected plaintext protocols, weak broker settings, and telemetry paths that bypass approved encryption controls. Detection is especially important when telemetry includes identifiers that could aid lateral movement or selective targeting.
Where encryption cannot be introduced immediately, compensate by narrowing access, segmenting telemetry paths, reducing field content, and removing especially revealing values from routine operational outputs. If telemetry includes secrets, session material, or direct privilege indicators, the issue crosses from observability hygiene into identity and access protection.
OWASP API Security Top 10 is relevant when telemetry is exposed through APIs or service endpoints, because broken authentication and broken authorisation can turn ordinary operational feeds into high-value reconnaissance sources.
Risk and Threat Considerations
Cleartext telemetry creates a reconnaissance advantage because it can reveal system names, environment cues, or access-related details that are otherwise hard to infer. Once an attacker can observe that data, they can profile the environment, prioritise targets, and often reduce the noise needed to stay hidden.
Failure mechanism: Telemetry leaves trusted systems in readable form, or is re-exposed after collection through weaker internal hops, shared tooling, or insecure endpoints, allowing passive observation or log-driven harvesting.
Impact: Attackers can map assets, infer privilege structure, identify high-value services, and accelerate follow-on compromise by using the leaked operational context to plan access, persistence, or lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Cleartext telemetry is fundamentally a transmission confidentiality problem. |
| AU-9 — Protection of Audit and Accountability Information | Telemetry often functions as audit-like operational evidence that needs protection from disclosure. | |
| Recommendation — Encrypt telemetry in transit to protect operational data from passive interception. Restrict access to telemetry stores and logs that expose sensitive operational details. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Telemetry may be copied into collectors and stores where its protection must be preserved. |
| Recommendation — Protect telemetry data wherever it is stored or replicated. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Cleartext telemetry often results from insecure service or API transport settings. |
| Recommendation — Harden telemetry endpoints and disable plaintext exposure paths. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Telemetry exposure and detection of plaintext paths fit network monitoring and defensive visibility. |
| Recommendation — Monitor telemetry paths for unauthorized exposure and unexpected plaintext traffic. | ||
Practitioner Guidance
Why practitioners should care: Treat telemetry protection as part of security architecture, not just observability engineering. If operational data helps teams troubleshoot systems, it will also help an attacker understand them if transport or collection is weak.
What to watch for: Repeated plaintext service paths, unencrypted collector links, broad internal exposure of metrics, and telemetry fields that carry identifiers, environment markers, or security posture clues all warrant review.
Practitioner takeaway: The safest telemetry design is one that assumes the data itself is intelligence, then constrains where it travels, who can read it, and what it reveals if intercepted.
Related resources from NHI Mgmt Group
- When should organisations treat runtime telemetry as a primary control?
- Should organisations require security telemetry before adopting SaaS tools?
- Who should own trust telemetry when reporting spans NHI and cryptography controls?
- What should organisations control before exposing identity telemetry to AI assistants?