Encryption in Transit: Definition and Use in Compliance

What is Encryption in Transit?

Encryption in transit is the practice of encoding data while it moves between two network endpoints so that any intercepted traffic is unreadable to unauthorized parties. It's the most visible security control for internet-facing financial services, and one of the first things examiners ask about.

The dominant protocol is Transport Layer Security (TLS). TLS 1.3, standardized in RFC 8446 in August 2018, is the current benchmark. It dropped several obsolete cipher suites from TLS 1.2 and cut handshake latency by eliminating a full round trip. TLS 1.0 and 1.1 are deprecated and prohibited under PCI DSS v4.0 as of March 2025.

TLS works in two phases. An asymmetric key exchange authenticates the server (and optionally the client) and establishes a shared secret. That shared secret then generates symmetric session keys for the actual data encryption. AES-256-GCM is the cipher most financial environments use for the symmetric phase.

Encryption in transit is distinct from encryption at rest. At-rest encryption protects data stored on disk or in databases. In-transit encryption protects data crossing a network. A system can have strong at-rest encryption with completely exposed network traffic, and vice versa. Both controls are required, and audit teams check them separately.

A concrete example: a bank's mobile app submits account details to a backend API. Without TLS, anyone on the same network can capture that request and read account numbers, balances, and session tokens in plaintext. With TLS 1.3, the content is opaque to any observer between the app and the server, and the server's identity is authenticated against a certificate chain rooted in a trusted Certificate Authority.

Hardware Security Modules (HSMs) often store the private keys used to authenticate TLS certificates for high-value financial connections. This keeps key material off general-purpose servers and limits the blast radius if a server is compromised.

How is Encryption in Transit Used in Practice?

Compliance and security teams apply encryption in transit requirements across several contexts: external-facing APIs, internal service-to-service communication, database connections, file transfers, and email. The gaps are rarely in the obvious places.

External APIs covering onboarding flows, Know Your Customer (KYC) checks, and payment processing have been under PCI DSS and web security scrutiny for years. They're usually well-covered. The problems tend to appear in internal traffic, where engineering teams historically relied on network perimeter controls and skipped TLS between microservices. Zero Trust Architecture treats internal traffic with the same skepticism as external traffic, requiring mutual TLS (mTLS) between services so both sides authenticate.

Database connections are a recurring audit finding. PostgreSQL, MySQL, and MongoDB all support TLS connections, but the feature isn't always enabled by default. A bank that enforces TLS on its customer-facing app but connects to its database over an unencrypted socket has a gap that examiners will cite.

For file transfers carrying Suspicious Activity Report (SAR) submissions, regulatory reports, or bulk customer data exports, SFTP over SSH or FTPS are the accepted standards. Plain FTP is prohibited under PCI DSS and GDPR. Financial Intelligence Unit portals in most jurisdictions enforce HTTPS with strict transport security headers or certificate pinning.

Email is the weakest link in most environments. SMTP uses STARTTLS, but STARTTLS is opportunistic: if one server doesn't support encryption, both sides fall back to plaintext. For sensitive compliance communications, teams should require enforced TLS (via DANE or MTA-STS) or use a secure portal delivery model instead of standard email.

Certificate management is where operations break down. Expired certificates cause outages and trigger security alerts, but the underlying issue is usually a missing inventory and rotation schedule. Teams that can enumerate every certificate in their environment, its expiry date, and the system it protects are ahead of most institutions.

Encryption in Transit in Regulatory Context

Several regulatory frameworks require encryption in transit, each with slightly different scope and specificity.

PCI DSS Requirement 4.2.1 requires strong cryptography for Primary Account Numbers (PANs) transmitted over open, public networks. PCI DSS v4.0, released in March 2022 and effective for all merchants by March 2025, prohibited TLS 1.0 and 1.1 and extended the encryption requirement to all transmission channels, including wireless. Acquirers, payment processors, and merchants all fall within scope.

GDPR Article 32 requires controllers and processors to implement "appropriate technical and organizational measures" to protect personal data, naming encryption explicitly. The European Data Protection Board (EDPB) confirmed that encryption in transit qualifies as an appropriate safeguard for data transferred across networks. A breach involving unencrypted data in transit aggravates breach severity under the Article 33 notification assessment and typically increases regulatory fines.

NIST Special Publication 800-52 Revision 2, published in 2019, recommends TLS 1.3 as the preferred protocol and permits TLS 1.2 with restricted cipher suites. It's the baseline for US federal agencies and is widely referenced by the OCC and FDIC in IT examination guidance.

The FFIEC IT Examination Handbook expects banks to document encryption standards for data in transit and demonstrate that weak protocols have been disabled. Examiners treat this as a measure of information security program maturity, not a checkbox item.

For institutions filing Suspicious Transaction Reports (STRs) or Currency Transaction Reports (CTRs) to FIUs, encryption in transit is also an evidentiary concern: the confidentiality and integrity of transmitted reports affects their chain of custody. The FCA's Operational Resilience framework and the EBA Guidelines on ICT and Security Risk Management both treat encryption as a control supporting data integrity and confidentiality objectives under their information security requirements.

Common Challenges and How to Address Them

Three problems account for most encryption-in-transit failures in financial institutions: incomplete protocol coverage, certificate management failures, and TLS misconfiguration.

Incomplete coverage is the most common. A bank encrypts its customer-facing web application but leaves internal API calls between microservices, reporting pipelines, and monitoring tools running over plain HTTP. Finding these gaps requires a network traffic inventory, which most institutions don't maintain proactively. The fix is a data flow mapping exercise that categorizes each connection by sensitivity and verifies encryption status. This work also feeds into data lineage documentation required for regulatory reporting and audit evidence packages.

Certificate failures cause two distinct problems: outages when certificates expire without warning, and security gaps when certificates use weak key lengths. 1024-bit RSA certificates still appear in some legacy environments. 2048-bit is the current minimum, with 4096-bit or ECDSA preferred for new deployments. The fix is certificate lifecycle management with tooling that inventories every certificate, tracks expiry dates, and triggers alerts at 30 days and 7 days. At 7 days, treat it as an incident.

TLS misconfiguration is subtler. A server might support TLS 1.3 but also advertise TLS 1.0 as a fallback, which an attacker can force through a protocol downgrade attack. Tools like Qualys SSL Labs or testssl.sh scan a server's supported protocols and cipher suites and flag weak configurations. Running these scans quarterly, and before major regulatory exams, is standard practice.

Vendor risk is a fourth challenge. Third parties handling Enhanced Due Diligence (EDD) documentation or customer data under Customer Due Diligence (CDD) workflows may not meet the same encryption standards. Vendor security questionnaires should specifically ask for TLS version support and cipher suite configuration. Verify the answers against the vendor's actual endpoints rather than accepting them at face value.

Related Terms and Concepts

Encryption in transit sits within a broader set of cryptographic and data protection controls that compliance teams work with regularly.

Encryption at rest is the direct complement. Encryption at rest protects data stored on disk, in databases, or in backup media. Regulators require both. The common failure pattern is strong in-transit encryption paired with unencrypted database storage. If storage media is ever accessed directly, the TLS configuration offers no protection.

Tokenization replaces sensitive data values with non-sensitive tokens. In payment processing, tokenization means the actual PAN doesn't travel across the network in cleartext; only the token does. It complements encryption in transit: even if traffic is intercepted and decrypted, tokenized values are useless without access to the token vault.

Pseudonymization, as defined under GDPR, replaces direct identifiers with pseudonyms. Pseudonymization differs from encryption but reduces the sensitivity of transmitted data, which shrinks the impact of any interception.

Hardware Security Modules (HSM) store and manage the cryptographic keys used in TLS certificate authentication. For high-value connections, keeping TLS private keys in an HSM rather than on a general-purpose server prevents key extraction even if the server itself is breached.

The audit trail for encrypted connections typically includes certificate serial numbers, protocol versions, and cipher suites negotiated per session. In a regulatory inquiry, demonstrating what was encrypted, with what protocol, and when, is part of maintaining a defensible chain of custody.

Data lineage tooling increasingly tracks encryption status as part of pipeline metadata. This gives compliance teams visibility into whether each data flow meets encryption standards before data reaches analytics or reporting systems.

For institutions subject to data residency requirements, encryption key management jurisdiction is a related consideration. Keys managed within the required jurisdiction add an additional control layer for cross-border API calls, even when the data itself is encrypted in transit.