Data Security Protocols: How Secure Data Exchange Works

Data moving between systems is exposed to several risks along the way: someone can intercept it, read it, alter it or impersonate one of the parties in the exchange. Security protocols define how systems protect against those risks, combining mechanisms such as encryption, authentication, key establishment and integrity protection.

The exact protection depends on the protocol and where it operates. Some secure an application connection or network path, while others keep protection attached to a message or file after transmission.

Looking at protocols by the scope of what they protect gives teams a clearer view of how protected communication fits into the data architecture — which starts with knowing what each protocol is responsible for and where that responsibility ends.

A data security protocol is a specified procedure that systems follow to protect information while communicating or exchanging data. A protocol may define how two systems authenticate one another, how cryptographic keys are established, which encryption methods are used and how each side verifies that transmitted information hasn’t been modified.

Different protocols protect different parts of an exchange. TLS secures application traffic while a connection is active, for example, while IPsec protects traffic at the network layer, and protocols such as PGP or S/MIME keep protection attached to a message or file after transmission.

No protocol covers the entire data lifecycle. A protocol’s protection applies to a particular interaction or object, so understanding where that boundary sits is essential to understanding how protocols work with access controls and other security mechanisms.

Before protected application traffic starts moving, the communicating systems need to establish the terms of the session. Depending on the protocol, that process can include agreeing on supported cryptographic parameters, authenticating one or both endpoints, and deriving or exchanging the key material used for the connection.

During session establishment and the exchange that follows, secure protocols coordinate several cryptographic functions. Encryption, authentication and integrity each address a different part of that protection.

An encrypted connection prevents someone who’s observing network traffic from reading the contents of the transmission. The data travels through a protected channel between the two endpoints. Authentication verifies that the party at the other end is actually the one the client intended to reach.

A client that encrypts traffic without reliably establishing the server’s identity could establish a protected session with an impostor. On the other hand, knowing the identity of a server doesn’t keep unencrypted traffic confidential as it travels across the network. Secure protocols coordinate these protections within the same exchange.

Confidentiality is only one concern when data crosses a network, however. A recipient also needs confidence that the protected information it receives hasn’t been modified along the way.

Modern secure communication protocols use cryptographic integrity protection to detect unauthorized changes to data in transit. Depending on the protocol and cryptographic construction, those protections may be integrated with encryption rather than performed as a separate step.

Together, confidentiality, authentication and integrity give communicating systems a basis for trusting the protected exchange.

For application traffic, TLS is one of the most widely used secure communication protocols. When an application connects to a web service over HTTPS, HTTP defines the application-level request and response, while TLS supplies the protected channel underneath the exchange. In other words, HTTPS describes HTTP carried over TLS.

TLS now sits underneath most everyday web traffic. In 2025 research based on browsing data from more than 140 million Firefox users, Mozilla researchers found that 92.1% of top-level connections globally occurred over secure, encrypted connections.

Before application data starts flowing, the TLS handshake establishes the session. Once that process completes, the endpoints use the derived session keys to protect the application traffic moving between them.

TLS 1.3 is the current IETF standard, while TLS 1.2 remains widely used and can still provide strong protection when it’s configured with appropriate cipher suites. TLS 1.3 simplifies the protocol and removes several older cryptographic options, so it’s generally preferred where supported. But TLS 1.3 also changes how enterprises inspect encrypted traffic and can disrupt the passive-decryption techniques organizations previously used for monitoring TLS 1.2 traffic.

Consider an analyst opening a BI application that queries a remote data platform. TLS protects the request and response as they travel between the client and service.

But once the query result reaches the application, the TLS session no longer governs what happens to that data. If the application caches the result, exports it to a file or writes it to another system, controls such as storage encryption, permissions and retention policies must be used.

Similarly, the presence of TLS says nothing about whether the analyst was entitled to see the result. Authentication establishes who is connecting, while authorization applies the roles, grants and policies that determine what that identity is allowed to access.

This is one reason encrypted network traffic and secure data access shouldn’t be treated as interchangeable concepts. TLS simply protects the exchange taking place over the session.

See how Snowflake Trust Center helps teams identify security risks, assess account configurations and strengthen controls around authentication, network policies and sensitive data:

IPsec protects IP traffic between hosts or networks, which is why it commonly appears in virtual private network (VPN) and site-to-site designs. Because it operates at the network layer, it can protect traffic from multiple applications moving across the same path.

A request traveling through an IPsec-protected network path may also use TLS for the application connection. The two protocols protect different parts of the same flow.

For example, an organization might use IPsec to protect traffic between an on-premises environment and a cloud network while individual applications continue to use TLS for their own sessions. IPsec protects the network path between those environments; the application protocol still governs the protected session above it.

Once the traffic reaches the destination system, IPsec has done its job. Identity, authorization and data-level controls determine what the user or workload is allowed to do with the resources on the other side.

SSH establishes an encrypted, authenticated session between a client and a remote host. Administrators commonly use it to log in to servers, run commands and manage systems without exposing the contents of the session over the network. SFTP uses that SSH session to transfer files.

As with other protocols, protection applies to the part of the path the protocol covers — a file moved over SFTP is protected while it travels through the SSH session. Once the file is written to the destination system, however, the transfer protocol is no longer responsible for it. Storage encryption, permissions, retention rules and other controls govern how that copy is protected afterward.

Sometimes protection needs to persist after the transport connection closes. Consider a confidential email. TLS can protect the connection used to move the message between mail systems, but that protection belongs only to the connection. Once the message has been delivered and stored, the TLS session is gone. Message-level approaches such as PGP and Secure/Multipurpose Internet Mail Extensions (S/MIME) address that problem by applying cryptographic protection to the content itself.

OpenPGP protects the content

OpenPGP, the standardized message format derived from Pretty Good Privacy (PGP), supports encryption and digital signatures for files and messages. Because encryption is applied to the content, a protected OpenPGP file stays encrypted after the network connection used to move it has ended.

This property is useful when a file travels through several systems or remains stored before the intended recipient opens it. The protection moves with the object.

S/MIME protects email beyond the transport session

S/MIME uses public-key cryptography and digital certificates to support encrypted and digitally signed email. An email protected with S/MIME might travel through TLS-protected connections between mail infrastructure. In that scenario, TLS secures the transport sessions while S/MIME keeps protection attached to the email itself.

A single data flow often crosses several protected contexts before it reaches its destination. For example, an application request might use TLS while traveling across a network path protected with IPsec, then trigger a remote operation over SSH or move a file through SFTP.

Those protocols aren’t competing for the same job. They operate at different layers in the architecture. IPsec protects traffic at the network layer, TLS protects the application session and SSH protects a remote session. When more than one appears along the same path, each applies protection within the part of the communication it governs.

The same principle applies to message-level protection. An S/MIME-encrypted email might travel over a TLS-protected mail connection, for example. TLS protects the transport between systems, while S/MIME keeps cryptographic protection attached to the message after that transport session ends.

Looking at protocols this way helps teams trace protection across the full path rather than reviewing each protocol in isolation. A useful architecture review should answer questions such as:

• Which protocols are active at each stage of the data flow?
• Where does each protected session begin and terminate?
• Which protections overlap, and are those overlaps intentional?
• Does the data leave one protected context and enter another?
• Does any protection persist with the data after transmission?

Snowflake protects client connections with TLS, including support for TLS 1.3 and strong TLS 1.2 cipher suites. That protection applies to traffic moving between supported clients and Snowflake services, including queries, results and other data exchanged during the session.

For organizations that want tighter control over the network path, private connectivity options such as AWS PrivateLink can keep traffic between supported environments off the public internet. Network policies serve a different purpose: they restrict which network locations are allowed to connect to Snowflake rather than configuring the TLS session itself.

Those controls sit alongside Snowflake’s protection for stored data. Snowflake encrypts data at rest automatically, while key-management options such as Tri-Secret Secure give organizations additional control over encryption keys. Keeping these functions separate is useful architecturally: TLS protects the active connection, private connectivity affects the path that connection takes and storage encryption protects the data after it has been written.

Protocols are only one part of secure data movement. To protect data throughout its lifecycle, teams must understand how the data actually travels: which systems exchange it, which network paths it crosses, whether protection remains attached to the content and what happens after the transmission ends.

When those details are mapped clearly, data security becomes easier to evaluate. Teams can see where protections overlap, where each control is responsible and where changes are needed when a new application or workflow is introduced.