Jay ButlerJay Butler, Manager of Client Implementations

Documents that users scan directly to email may not be secure because the multifunction printers (MFP) used to send them transmit email in clear text by default.  Clear text email could be intercepted by unintended parties resulting in the potential exposure of private information.  Regulatory compliance and good conscience dictate that sensitive, private information must be protected, so applicable email messages require encryption.

The problem is that many MFPs do not support email encryption, and for those that do, there is no guarantee the scans will be sent encrypted.  First, the MFP must be specifically configured to use TLS encryption for emailing scanned documents.  Secondly, the receiving email system must also be configured to accept TLS encryption.  If the MFP is configured to use TLS, but the receiving system does not accept TLS, the scanned document will likely be delivered anyway without encryption.  Configuring TLS on an MFP only ensures the scans will be offered over an encrypted channel.  In technical terms, this offer and accept sequence is referred to as opportunistic TLS, and it means TLS is not a fully reliable encryption method.   Additionally, it is not possible to be sure your MFPs are even configured to attempt using TLS without logging into each to validate.

For guaranteed encryption, scanned documents should be sent via Outlook in conjunction with an encryption service like ZixCorp full message encryption.  MFPs should be reconfigured to use ‘scan to folder’ instead of direct ‘scan to email’.  This way, users can attach the scanned documents to email messages they send via Outlook rather than emailing them directly from the MFP.  If Outlook is connected to an Exchange server, all messages sent to local employees will be secured by default.  For messages sent to external recipients with scanned attachments, the users should be trained to force encryption on all of those outgoing messages.

Scanned documents usually cannot be automatically encrypted because the attachment is a picture rather than a text-based document such as Word or Excel.  Encryption services are typically able to detect word patterns in the subject and body of messages in order to automatically encrypt them.  Attachments that contain readable text such as Word and Excel documents can also be scanned in the same manner; however, scanned attachments are actually a picture rather than machine readable text.  Encryption is typically forced by adding specific keywords to the subject line of new email messages.  For example, SafeSysMail and Escan use the keywords “secure delivery” (no quotes necessary) placed anywhere in the subject line of outgoing messages.

‘Scan to folder’ also provides financial institutions (FI) more precise control over the transmission of private information.  Access to the folder can and should be limited to only well-trained users that require the ability to email scanned documents.  ‘Scan to email’ may not offer the same level of control because any user typically has the permission to scan documents and email them from configured MFPs.  Even if the MFP is somehow restricted, the effectiveness is suspect due to the decentralized nature of configuring each MFP individually, and it may be possible for users to circumvent it via device modifications.  With ‘scan to folder’, the security is centralized via administrator control of shared folders on servers that users cannot modify.

The centralized nature and simplicity of ‘scan to folder’ also make it inherently more reliable than ‘scan to email.’  ‘Scan to email’ has complex interdependencies that extend beyond the MFP to include specialized mail server configurations, and Internet access to remote email servers for FI’s that outsource.  The Internet access required for scanning to outsourced email servers is also another example of the security risk associated with ‘scan to email.’  If any of these dependencies experience degradation, ‘scan to email’ failures may occur and go undetected for extended periods of time.  Senders may not realize their documents are failing to be delivered.  ‘Scan to folder’ depends only on the standard shared folder, and because the scanned document is sent as an attachment to an Outlook message, any delivery failures will be promptly reported directly to the sender.

In summary, here are 5 reasons ‘‘scan to folder’’ is better than ‘‘scan to email’’:

  1. Documents scanned to email cannot  guarantee encrypted delivery
  2. Documents scanned to a folder then attached to an Outlook email message can always be secured using an email encryption service
  3. Users’ ability to email scanned documents can be better controlled with ‘scan to folder’
  4. ‘Scan to folder’ is more reliable that ‘scan to email’
  5. ‘Scan to email’ requires MFPs to have outbound Internet access over an unsecured port (SMTP)

Not all MFPs support ‘scan to folder,’ but for those that do, it should be used in place of ‘scan to email.’  The next best option is to use TLS and accept the risk or better yet avoid ‘scan to email’ altogether.  If TLS is used, verify the receiving system accepts TLS and avoid emailing scanned documents to external recipients.  Email only to internal recipients and be sure to validate the configuration of every MFP in your environment.

Write a Comment