TLS Enforcement Across Stack

TLS everywhere. The enforcement.

Internal traffic

Most companies enforced TLS at their public boundary years ago and stopped there. Internal traffic continued to flow over plain HTTP because "it is internal, it is fine." That assumption stopped being defensible the day a major breach was traced to attackers reading internal traffic after compromising one server. Modern secure architectures enforce TLS everywhere, including internal traffic.

What internal TLS enforcement looks like:

• Service mesh enforces mTLS.: Istio, Linkerd, Consul Connect, AWS App Mesh. Each mesh runs sidecars that handle TLS for the application transparently. Pod A talks to pod B; the sidecars handle certificate exchange; the application code does not deal with TLS at all. The encryption is automatic.
• Mutual TLS (mTLS) authenticates both sides.: Beyond encrypting traffic, mTLS verifies the identity of both the client and server using certificates. Pod A cannot impersonate pod B because it does not have B's certificate; pod B cannot accept connections from random sources because it requires client certificates. The encryption and authentication layers fuse.
• Encrypts pod-to-pod by default.: Once the mesh is deployed, every service-to-service call is encrypted automatically. The team does not have to remember to enable encryption per service; the default is on. Compromise of one service does not give the attacker the ability to read other services' traffic.
• Workload identity, not network identity.: The certificates are issued to specific workloads (specific pods, specific service accounts). The certificate proves the workload's identity. Compromising the network does not let the attacker impersonate workloads because they do not have the certificates.
• Rotation handled by the mesh.: Certificate lifetimes are short (typically hours to days); rotation is automatic. The mesh handles certificate issuance, distribution, and rotation. The application is unaware; the security benefit is automatic.

Internal mTLS is the modern default. Teams without it are operating on the assumption that internal networks are safe; the assumption is no longer warranted.

External traffic

External TLS enforcement is less novel but still requires discipline. The defaults have improved over the years; staying current means tracking and applying the modern hardening recommendations rather than running on a 2018 configuration.

• TLS 1.2 minimum, TLS 1.3 preferred.: TLS 1.0 and 1.1 are deprecated and disabled. TLS 1.2 is the minimum acceptable version. TLS 1.3 is preferred where supported (which is essentially everywhere in 2026). Older versions are not just slow; they have known cryptographic weaknesses that should not be in production.
• Strong cipher suites only.: The cipher suite list is curated to current best practices: AEAD ciphers, forward secrecy by default, no RC4, no 3DES, no DES, no NULL ciphers. Tools like Mozilla's SSL configuration generator produce current recommendations.
• HSTS headers.: The Strict-Transport-Security header tells the browser "always use HTTPS for this domain"; the browser refuses to load HTTP pages from that domain. Once HSTS is published, the team is committed to HTTPS-only operation; downgrading is not an option without breaking customer browsers.
• Certificate transparency.: Certificates issued for your domain are logged in the public Certificate Transparency log. Monitoring the log catches misissued certificates (someone got a cert for your domain who should not have). The monitoring is automated; the alerts are actionable.
• Standard hardening, not exotic.: The recommendations are well-known. The discipline is applying them consistently across every endpoint. New endpoints get the same treatment as existing ones; deviations require explicit justification.

External TLS hardening is well-documented. The work is mechanical; the discipline is in the consistency of application.

Audit

The third leg is auditing. Periodic verification that TLS is actually being used everywhere, that no regression has introduced plaintext, that no exception has been forgotten about.

• Quarterly: any plaintext traffic?.: Each quarter, the team audits the network for plaintext flows. Service mesh tells you per-pod whether mTLS is on. Network packet captures (sampled briefly) tell you whether plaintext traffic exists where it should not. The audit catches drift.
• Investigate exceptions.: Any plaintext traffic detected gets investigated. Sometimes it is legitimate (a service that genuinely cannot do TLS yet, with a documented exception). Sometimes it is drift (a service that lost its mTLS configuration during a recent change). Each exception is documented or remediated.
• Trends to zero.: The metric "fraction of internal traffic that is encrypted" should trend toward 100% over time. Quarterly snapshots show the progression. A team that has held the metric at 95% for years has plateaued; the remaining 5% needs a deliberate push.
• External-side audit too.: Tools like SSL Labs, testssl.sh, and tlsmate scan public endpoints for TLS configuration weaknesses. Run the scan quarterly; address findings. The external scan complements the internal audit.
• Cross-link to compliance.: Several compliance frameworks (PCI DSS, HIPAA, SOC 2) explicitly require TLS for data in transit. The audit produces evidence; the compliance review references the audit. The two practices reinforce each other.

TLS enforcement everywhere is the defense that is hard to argue against and easy to skip. Nova AI Ops integrates with service mesh telemetry to surface unencrypted internal traffic, audits external endpoints against current TLS configuration recommendations, and tracks the encryption coverage trajectory so the team can see whether the discipline is improving over time.