How are SecureDoc client-to-server communications protected?

Client to Server communications (between a SecureDoc Client and one or more SDConnex servers) are encrypted, in both directions.

Server-to-Client Communications:

The SDConnex server and to some extent the SES Console can "bump" or "nudge" a given client using a UDP packet. If the client is not on the network, the communication fails silently.

This is effectively little more than a UDP packet sent on a specific port (to which the client device is listening), that lets the client machine know that the SES server wants the client machine to connect or "call home". This is often done where there's updated information on the SES server that the client machine should know about, retrieve and act upon.
There's little to no "content" in this UDP packet, so in the worst-case scenario that such packets are faked by another process, the client might make an unnecessary connection to SDConnex.

Client-to-Server Communications:

The client application will connect to (one of) the SDConnex Server(s), authenticate and either transmit information or request information. This connection is important, and carries a transaction payload that must be protected and retried end-to-end if necessary, so it uses TCP instead of UDP.

Upon validating the request, SDConnex will either pass on the information for storage in SES (such as device log information), or pass the request to SES to be acted upon.