A typical explicit FTPS session might consist of the following sequence of commands:
| > USER (user-name) | Log in |
| > PASS (password) | |
| > LIST | Get a directory listing |
| > AUTH TLS | Switch to TLS on control-channel |
| > RETR (file-name) | Download a file (without security) |
| > PBSZ 0 | Switch to TLS on the data-channel |
| > PROT P | |
| > STOR (file-name) | Upload a file (with security) |
| > QUIT | End session |
In this example, the first three commands (USER, PASS, and LIST) are standard FTP and therefore insecure. The AUTH command causes the rest of the commands to be sent to the server securely, in other words, an attacker cannot see which commands are issued. The GET command, being after AUTH, is protected, but the actual file that is transferred is not protected since it precedes the PBSZ and PROT commands. PBSZ and PROT tell the server to use TLS on all future data-channels, thus the file transferred in the PUT command is secure.
There are two rules regarding the issuing of explicit FTPS commands that must be followed:
Apart from these, a FTPS server has policies regarding access permissions to its resources. These policies will also determine the order in which commands must be issued. There are too many possible policies to list here, but a few examples of such policies are given below along with their consequences in terms of the issuing of commands.
| Policy | Consequences |
| No unprotected commands | AUTH must be issued before any other commands. |
| Certain users are not permitted to log in without security. | The USER command is rejected for particular users unless preceded by a successful AUTH command. |
| No unprotected data may be transferred | A 'PROT P' command (preceded by a PBSZ command) must be issued before any files are transferred. |
| Allow TLS authentication instead of USER/PASS authentication | A client certificate must be supplied and USER/PASS commands are not required. |
Next: The Essentials of FTP Security