Encryption in Transit — TLS 1.3 and Certificate Management
The protocols, configurations, and certificate lifecycle management practices required to protect data moving across networks in regulated environments.
Encryption in transit protects data moving between systems — clients and servers, microservices, databases and applications, and cross-region data replication — from interception and tampering. Regulated industries mandate encryption in transit under PCI DSS Requirement 4 (strong cryptography for PAN in transit), HIPAA Technical Safeguard §164.312(e)(2)(ii) (encryption of PHI in transit), and NIST SP 800-52 (TLS implementation guidance for federal systems). TLS 1.3, standardized in RFC 8446, is the current required minimum for new implementations: it eliminated vulnerable cipher suites, reduced the handshake from two round trips to one (improving latency), mandated forward secrecy for all connections, and removed support for deprecated algorithms (RC4, MD5, SHA-1). TLS 1.0 and 1.1 are prohibited by PCI DSS and deprecated by NIST.
Engineering TLS 1.3 compliance across a complex system requires inventorying all communication paths and verifying TLS version and cipher suite configuration at each endpoint. Web servers (nginx, Apache, IIS), API gateways, load balancers, database drivers, and internal service communication channels each have independent TLS configurations that must be assessed. TLS configuration scanners (testssl.sh, Qualys SSL Labs for external endpoints) automate this assessment and identify deprecated protocol support, weak cipher suites, and certificate issues. Certificate management is the operational foundation of encryption in transit: expired certificates cause service outages and compliance violations simultaneously. Certificate lifecycle automation using ACME protocol (Let's Encrypt), HashiCorp Vault PKI, or AWS Certificate Manager eliminates manual certificate renewal and is now considered a baseline requirement for regulated environments.
Internal service-to-service encryption in cloud and Kubernetes environments is an area where many organizations have gaps. While perimeter traffic (from internet to load balancer) is typically encrypted, internal east-west traffic (microservice to microservice, application to database) is sometimes left unencrypted on the assumption that internal networks are trusted. This assumption is incompatible with Zero Trust Architecture principles and fails PCI DSS Requirement 4's mandate to encrypt PAN wherever it is in transit, including internal networks. Service mesh (Istio/Linkerd) mutual TLS is the recommended solution for Kubernetes east-west encryption; for database connections, TLS client certificates provide mutual authentication. Certificate rotation for internal PKI must be automated with sufficient lead time before expiry, and rotation testing must be part of the regular operational runbook.
We conduct TLS configuration assessments across all communication paths — external, internal, and database — enforcing TLS 1.3 minimum standards, prohibiting deprecated cipher suites, and implementing certificate lifecycle automation that prevents expiry-driven outages. Our implementations include internal east-west mTLS through service mesh and database TLS certificate management for regulated data-in-transit compliance.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.