TCP is the transport carrying the application traffic, while TLS is the encryption layer that can secure that traffic in transit. In a gateway stream configuration, tcp sends bytes onward as plain traffic, while tls tells the gateway to encrypt outbound connections and, when configured, terminate incoming TLS before forwarding to the upstream.
TCP and TLS, the two layers doing different jobs
TCP is the transport layer that moves byte streams reliably between endpoints. TLS sits above it and adds encryption, integrity, and peer authentication for that stream. In a gateway stream configuration, the distinction matters because the gateway can forward raw TCP bytes, or it can apply TLS policy to protect the connection while still using TCP as the delivery mechanism.
That separation is why the same upstream service can be reached over plain TCP or protected TLS without changing the basic transport model. TCP determines how data gets from one side to the other; TLS determines whether that data is encrypted and whether the gateway should validate or terminate the secure session before proxying onward.
What changes in a gateway stream configuration
In a stream configuration, tcp typically means pass-through handling: the gateway forwards the byte stream without interpreting application content or initiating encryption on its own. That is useful when the upstream already expects plaintext, when TLS is terminated elsewhere, or when the gateway is only acting as a transport relay.
By contrast, tls tells the gateway to treat the stream as a secure connection. Depending on the configuration, it may negotiate TLS to the upstream, present its own certificate, or terminate incoming TLS and forward decrypted traffic internally. The practical difference is not just “encrypted versus unencrypted”, but where trust is established and where certificate validation and session termination occur.
That choice affects observability and control. A TCP pass-through preserves end-to-end secrecy for whatever sits inside the byte stream, but the gateway cannot inspect or decrypt that traffic. A TLS-aware gateway can enforce certificate policy and centralize encryption handling, but it also becomes part of the trust boundary and must be configured carefully to avoid accidental downgrade or exposure.
Choosing between them for the upstream path
The right setting depends on what the upstream expects and where you want encryption to end. If the backend service already terminates TLS, a TCP stream may be sufficient because the gateway should not interfere with the secure session. If the gateway is meant to protect traffic in transit to the upstream, TLS handling belongs in the stream configuration.
That decision also changes failure behavior. With TCP pass-through, the most common issue is simple connectivity, because the gateway is not participating in the secure handshake. With TLS handling, certificate trust, hostname validation, SNI routing, and handshake compatibility become part of the operational path, so misconfiguration can break traffic even when the underlying TCP path is healthy.
Risk and Threat Considerations
Using TCP where TLS was intended can expose credentials, session data, and other sensitive payloads to interception anywhere the traffic crosses an untrusted network or intermediate hop. Using TLS where the backend or client expectations are wrong can also create availability issues if handshake settings, certificates, or termination points do not line up.
Failure mechanism: The gateway either forwards bytes without encryption or terminates and re-establishes TLS with incorrect trust assumptions, weak certificate handling, or inconsistent upstream expectations. That can produce plaintext exposure, downgrade risk, or broken service routing.
Impact: The result can be confidentiality loss, failed connections, or a false sense of protection if TLS is enabled on only one leg of the path. In stream-based gateways, the security boundary is defined by where TLS starts and stops, so configuration mistakes directly affect what is actually protected.
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 CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | TLS in transit directly protects stream confidentiality and integrity. |
| SC-23 — Session Authenticity | TLS termination and handshake trust determine whether the peer is authenticated correctly. | |
| Recommendation — Enforce SC-8 on stream paths that carry sensitive traffic and validate encryption coverage end to end. Use SC-23 to validate peer authentication and prevent insecure session establishment. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | TLS handling is a cryptographic control decision for protecting data in transit. |
| Recommendation — Apply A.8.24 to define where encryption is required and who manages termination. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-transit is protected | The question is about whether gateway traffic is protected on the wire or forwarded as plain TCP. |
| Recommendation — Implement PR.DS-02 for streams that must remain protected in transit. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Stream handling determines whether sensitive data is protected during transport. |
| Recommendation — Use CIS-3 to ensure traffic that needs confidentiality is encrypted across the path. | ||
Practitioner Guidance
What to verify: Confirm which side of the gateway is supposed to own TLS termination, then verify the certificate chain, hostname or SNI expectations, and whether the upstream accepts plaintext or requires TLS. If the backend is sensitive, test the full path rather than assuming that “TLS enabled” means end-to-end encryption.
Decision rule: Use tcp when the gateway should remain transport-only and must not touch the secure session; use tls when the gateway is intentionally part of the trust and encryption boundary. If you cannot state where the TLS session terminates, the configuration is not yet precise enough to trust.
Practitioner takeaway: The real choice is not protocol labeling, it is where encryption is established, terminated, and trusted. In a gateway stream, that boundary should be explicit, tested, and aligned with the upstream service’s expectations.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
