Welcome to the EFT Best Practices page. We are currently assembling a collection of best practice topics based on interactions with our customers. Our goal is to share as much helpful information as possible to ensure you get the most out of your EFT platform. Stay tuned for more detailed best practices related to Event Rules, Active-Active High Availability, Upgrading, Auditing/Reporting and more.

Current Topics:



To maintain permissions security while using granular access controls, create a separate remote access account for credentials overrides.

Expanded Permissions

When installing and configuring EFT, it is recommended to give your service account the least permissions or privileges necessary. However, there will be instances when expanded permissions are needed to access resources that are normally restricted, such as when one of EFT’s event rules needs to monitor or write to a network share.

Use the optional credentials override feature to maintain a least-privileges profile for the majority of EFT’s functionality, while still allowing certain EFT subsystems to access secured resources.

Optional Credentials Override Feature

With EFT’s Optional Credentials Override feature, you can specify an alternate set of logon credentials for EFT’s event rules subsystem to use when accessing network shares to which the EFT service account may not have access (due to security constraints). This allows you to work with network file servers (NetApp, Windows, SAMBA, etc) that have restricted ACLs, while still adhering to the principle of least-privileged access for your overall Managed File Transfer (MFT) application.

Alternate credentials, if specified, will cause EFT to impersonate that account, adopting that account’s permissions to access network shares from EFT’s Copy/Move, Folder Monitor, and File and Folder event rule actions.  

In other words, when an alternate set of credentials is specified:

  • EFT will use its current security token (associated with the "Log on as" account specified in the EFT server service settings) for LOCAL folder access, such as for download operations to a local, physical folder.  
  • EFT will use the new security token (associated with the alternate logon credentials) for the remote folder accessed over network connections (e.g. network shares).

How to Configure Optional Override

  • From a supported event rule (such as folder monitor, file download or copy/move, or folder/file operation) locate the Optional Credentials Override field.
  • In that field, type in the Windows account username and password.
  • Unlike normal user account passwords, the credential override password is stored in EFT’s configuration database in encrypted, yet reversible format. This is necessary so that EFT can retrieve and use the password in an unattended fashion.


Tell us what you think


When it comes to troubleshooting, there are several challenges, including the pressure to meet strict security policies and comply with regulations. These efforts are further complicated by a lack of visibility into how end-users are connecting with your systems. If users are connecting with deprecated or outdated ciphers or algorithms, then problems can occur and your data security could be at risk.


Understand how users are connecting with your EFT platform. Disable deprecated or weaker cryptography whenever possible to help maintain strong system security.

Many EFT customers have asked us if it is possible to gain insight into the SFTP and SSL/TLS cryptography details that their inbound connected clients are using when connecting to EFT. The simple answer is, yes. Having this information is useful not only for troubleshooting, but for proactive/preventive measures as well. To gain this level of visibility into your EFT log files, you will need to enable verbose logging when troubleshooting or debugging.

How To Enable EFT Verbose Logging

Log levels in EFT all default to the TRACE or INFO setting, which is standard or typical logging. If you need more details in your logs, change the logging configuration to extended or verbose log level in logging.cfg to DEBUG. This will give you an extended level of detail in your logs to help you pinpoint where the trouble lies.

For example, with the SSL logging level set to DEBUG, you would see whether the connection was accepted, and which protocol version, cipher, and key length were used in the connection:

DEBUG SSL <> - SSL connection accepted; protocol version = TLSv1.2, cipher = ECDHERSA-AES128-GCM-SHA256, key length = 128

Please note: it is recommended that you only use verbose logging during debugging or troubleshooting. It will produce a large amount of data and quickly use up your processing speed and drive space. It is not necessary to reboot after making these modifications.

Advanced Configuration for Verbose Logging:

Use the following example to set up a separate file appender for verbose logs, which should make data capture and analysis a bit more manageable.

Instead of SFTP = TRACE or SSL = TRACE, specify the following settings in the logging.cfg file:

  • log4cplus.appender.SFTPFileAppender=log4cplus::RollingFileAppender
  • log4cplus.appender.SFTPFileAppender.File=${AppDataPath}\EFT-SFTP-${COMPUTERNAME}.log
  • log4cplus.appender.SFTPFileAppender.MaxFileSize=20MB
  • log4cplus.appender.SFTPFileAppender.MaxBackupIndex=5
  • log4cplus.appender.SFTPFileAppender.layout=log4cplus::TTCCLayout
  • log4cplus.appender.SFTPFileAppender.layout.DateFormat=%m-%d-%y %H:%M:%S,%q
  • log4cplus.logger.SFTP=TRACE, SFTPFileAppender
  • log4cplus.additivity.SFTP=false
  • log4cplus.appender.SFTPFileAppender.filters.1=log4cplus::spi::StringMatchFilter
  • log4cplus.appender.SFTPFileAppender.filters.1.StringToMatch=Received SSH_MSG_KEXINIT
  • log4cplus.appender.SFTPFileAppender.filters.1.AcceptOnMatch=true
  • log4cplus.appender.SFTPFileAppender.filters.2=log4cplus::spi::StringMatchFilter
  • log4cplus.appender.SFTPFileAppender.filters.2.StringToMatch=Handling SSH_MSG_USERAUTH_REQUEST for user
  • log4cplus.appender.SFTPFileAppender.filters.2.AcceptOnMatch=true
  • log4cplus.appender.SFTPFileAppender.filters.3=log4cplus::spi::DenyAllFilter

After using verbose logging for few days (or however long is needed), copy the EFT-SFTP-*.log files to a new folder for processing. (You have to copy the log files to a separate folder for analysis because the PowerShell cannot open files that EFT is holding open.)

Run this PowerShell script (specific to this SFTP example) against those log files in that separate folder to generate a CSV file with the results. Be sure to change the path in the script to the location in which you have created a new folder.

Reminder: Your security efforts will be most effective if you use the latest version of EFT. Periodically check the Globalscape support site for the latest version and upgrade accordingly. Learn more.

Tell us what you think

Optimal Configuration and Encryption

Globalscape’s Enhanced File Transfer (EFT) platform offers many security options for your SSL connections and SFTP connections. Choosing the right combination of protocol versions, key ciphers, MACs, and key exchange algorithms can be challenging. We’ve put together some tested* recommendations to help guide you in this process.


Use the recommendations below for SSL/TLS communications, which cover the FTPS and HTTPS protocols. These can be used as a starting point, and you can always add (or remove) options based on your unique needs or the needs of your business partners.

Protocol Suite Ideal Acceptable Avoid
  TLS 1.2 TLS  1.1 TLS 1.0, SSLv3
Encryption Cipher AESGCM(256)
All 128 bit ciphers All others
3DES (unless required)
Message Authentication Code AEAD
SHA1 (susceptible to collisions) MD5
Key Exchange ECDH
All others  
Authentication cipher ECDSA

*The above configurations were confirmed and tested using SSL Labs, which rated them grade “A” in terms of both security and performance.

Other recommendations:

  • Cipher suite 1.2 or above is recommended.
  • Don’t use export ciphers unless that is necessary.
  • When creating an SSL certificate, choose a 2048 bit key or higher.
  • Ensure that your certificate used strong signature algorithms such as SHA256. Do not use SHA1, which is considered insecure.
  • Ideally have your key signed by a reliable Certificate Authority (CA).


Use the following for SSH communications, which covers the SFTP protocol:

Each in priority order      
  Ideal Acceptable Avoid
Allowed ciphers All 256 bit ciphers All 128 bit ciphers All others
Allowed MACs 256 and 512 bit MACs All 128 or 96 bit MACs All others
Allowed KEXs 256 and 512 bit KEXs All 128 bit KEXs All others

With SSH, the receiving server usually dictates which algorithms are accepted. Newer clients such as CuteFTP 9 support strong algorithms, helping to ensure higher data security.

Other recommendations:

  • When creating an SSH key, choose a 2048 bit key or higher.
  • When creating an SSH key, choose OpenSSH format for greatest compatibility.

With these security options in place, you should be at a good starting point for ensuring both high security and broad compatibility. You can always “dial up” or “dial down” the security levels to either increase security or accommodate more business partner communications.

Reminder: Your security efforts will be most effective if you use the latest version of EFT. Periodically check the Globalscape support site for the latest version and upgrade accordingly. Learn more.

Tell us what you think