Unencrypted communications are data exchanges sent without cryptographic protection, so anyone intercepting the traffic can read or alter the content. In security terms, this creates exposure for credentials, sensitive data, and session information across networks, APIs, applications, and device links, and it weakens IAM, NHI, and zero trust controls.
What Unencrypted Communications Means in Practice
Unencrypted communications remove confidentiality from traffic in transit, so the content can be observed, copied, or modified by any party able to intercept the connection. The security problem is not limited to “reading data”, it also includes tampering and impersonation across network paths that the sender assumes are trusted.
That matters because modern systems often move authentication material, API payloads, configuration data, and user content over many links, not just a single browser session. When those links are not protected, the communication channel becomes a point of exposure rather than a control.
Where the Exposure Comes From
The risk starts wherever data crosses an untrusted or semi-trusted boundary, including internal networks, partner links, wireless segments, application-to-application calls, and device integrations. Even when the payload does not look sensitive on its own, metadata and session state can still reveal enough to support replay, session hijacking, or credential theft.
Unencrypted traffic is especially problematic when the system relies on trust in the channel itself. If the network path can be observed or altered, then any downstream assumption that “the connection is safe” becomes fragile. A link that carries credentials or tokens without cryptographic protection can undermine access controls even if the application logic is otherwise sound.
Why It Weakens Identity and Zero Trust Controls
Unencrypted communications can expose passwords, API keys, bearer tokens, cookies, certificates, and session identifiers. Once that material is visible on the wire, an attacker may be able to reuse it, impersonate a user or service, or move laterally without needing to break the application directly.
This is why transport protection is part of identity assurance, not just data protection. Zero trust models assume the path is not inherently trustworthy, and identity systems depend on the confidentiality and integrity of the exchanges that carry authenticators, assertions, and authorization decisions.
How Organisations Reduce the Problem
Start by inventorying where plaintext traffic still exists, then map those flows to business critical data, authentication paths, and externally reachable services. Vendor documentation, protocol traces, and configuration reviews are usually the fastest way to find downgrade paths, legacy endpoints, or embedded components that still allow cleartext.
For authoritative control guidance, align transport protection with NIST SP 800-53 Rev 5 Security and Privacy Controls and with NIST SP 800-207 Zero Trust Architecture, which both reinforce the need to protect communications and avoid trusting the network by default.
Risk and Threat Considerations
Unencrypted communications create a direct interception and modification risk because any actor on the path can read or alter traffic. That can expose credentials, disclose sensitive data, and enable session theft or silent request manipulation even when the endpoint systems themselves are not compromised.
Failure mechanism: An attacker gains visibility into the traffic path, captures sensitive fields or session material, and then reuses or alters what was observed to impersonate a trusted party or change the message in transit.
Impact: The result can be account takeover, unauthorized access, data disclosure, corrupted transactions, and a breakdown of trust in systems that depend on the integrity of their communications.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST SP 800-57 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 | Protects information in transit from disclosure and tampering. |
| IA-2 — Identification and Authentication (Organizational Users) | Unencrypted channels can expose user credentials and session material during authentication. | |
| IA-9 — Service Identification and Authentication | Machine-to-machine traffic is often where plaintext leaks tokens and service credentials. | |
| Recommendation — Enforce SC-8 to protect transmitted data with cryptographic safeguards. Use IA-2 to require protected authentication exchanges over trusted channels. Apply IA-9 to secure service-to-service authentication and transport. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero trust assumes the network is not inherently trusted and communications must be protected. |
| Recommendation — Design trust decisions so traffic protection does not rely on network location alone. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Encryption in transit is a core safeguard for protecting sensitive information moving between systems. |
| Recommendation — Implement CIS-3 safeguards to protect sensitive data while it is transmitted. | ||
| NIST SP 800-57 | 5.3 — Cryptoperiods and Key Management Planning | Transport encryption depends on sound key lifecycle and rotation practices. |
| Recommendation — Manage cryptographic keys so encrypted channels remain trustworthy over time. | ||
Practitioner Guidance
Why practitioners should care: Treat plaintext traffic as an exposure that can invalidate downstream security assumptions, especially where the channel carries identities, tokens, or sensitive business data. If a protocol, integration, or device still allows cleartext, the issue is not cosmetic, it is a live control gap.
What to watch for: Pay special attention to legacy services, internal APIs, test environments that drift into production use, and device or partner links that were introduced before encryption became mandatory. The most dangerous cases are often the ones that are “known” but never prioritised because they are internal.
Practitioner takeaway: The right fix is not just “encrypt more traffic”, it is to make encrypted transport the default expectation and treat any remaining plaintext exception as a governed risk decision.
Related resources from NHI Mgmt Group
- Why do insecure RBAC, exposed secrets, and unencrypted cluster communications increase risk in Kubernetes environments?
- What breaks when healthcare communications are left unencrypted?
- What breaks when organisations still rely on unencrypted email and internal chat for sensitive communications?
- What breaks when incident communications stay inside a compromised environment?