ZSentry Quick Start
Quick Start»

  • NO MESSAGE SCANNING, DLP (Data Loss/Leak Prevention) is provided after encryption
  • Your data is protected by end-to-end encryption, onsite, online, and at rest
  • The user and not ZSentry or a provider holds the keys
  • No protected data is permanently stored with ZSentry, although encrypted
  • Secure two-factor login
  • HIPAA and regulatory compliance
  • Reach any user device securely with anyway mobility
ZSentry means less work with IT and users. Encrypt and decrypt with one click, including two-factor user authentication. Your ZSentry-secured solutions will feel exactly like what you use today on the desktop and phone, and your recipients' solutions will also benefit from your use of ZSentry and yet feel exactly like what they use today, with no changes.

You will receive your secure email at your usual Inbox, with an email address that you already have and with nothing routed through ZSentry, using your Mail client or Web browser as before. ZSentry does not change any of your services, devices, software, providers, MX or other DNS records. There is no change to any user interface. Does not change how email or other Internet protocol works. Does not receive email and does not host email addresses for users. There is nothing to download or install, no plugins or add-ons, no digital certificate to add. There is no POP or IMAP server use, no stored cookies, no ActiveX controls, no Java, Javascript is not required, setup is optional.

Security Red Flags

"What choices do we have?" Solutions for online security are often plagued by hidden costs, hidden liability, and lack of both security and usability. For example, a solution may be 100% HIPAA-compliant and yet expose your organization to hefty fines in case of a fault or breach, while another solution may present a Safe Harbor with no fines even if there is a breach.

It often makes more sense to evaluate security products from their potential business impact rather than from their product claims or technological side. Here, we take the business impact approach and talk about some of the common warning signs, Red Flags, and how you can use them to guide your choices.

Even though the choice of a security solution involves many aspects, and this list of Red Flags is not complete or a foolproof indicator that something is wrong, what is clear is that a selection process should not overlook some obvious Red Flags as given below.

1. Red Flags

Red Flag #1: Sign a HIPAA Business Associate Agreement. This usually means that the security solution is exposing you to unnecessary technical, business, and legal risks.

ZSentry Premium operates in full HIPAA compliance without requiring users to sign a Business Associate Agreement (BAA), although a BAA can be signed if desired.

Signing a HIPAA BAA is mandatory, however, if the solution scans or utilizes the data in a third-party role (see Red Flag #5). It is also mandatory if the solution does NOT take advantage of the HIPAA "Safe Harbor", which requires encrypted and de-identified data. People may think that signing a BAA is like signing any other contract. However, in addition to legal model and harmonization problems for your organization, absence of the "Safe Harbor" means that if a breach of unsecured protected health information (PHI) is discovered, fines may be levied and notices to each person affected are required. In addition, other contracts with the "Covered Entity" may be at risk and the reputation of all business involved will almost certainly be harmed.

Red Flag #2: Centralized directory for encryption. Someone other than yourself has your business partners' and customer's contact information, with names, email addresses and other data.

In addition to being a single point of failure, this means that your data may become available or be sold to solution providers and other businesses. This also means that in the event data is lost or stolen, it is linkable to a particular person, at risk of violating HIPAA, HITECH, and other regulations.

Red Flag #3: It Just Works. This is fine but beware of hidden liabilities. For example, make sure that your keys are not escrowed in the servers providing the solution, as with IBE (Voltage). Nothing is safe in servers, not only from attackers but also from service providers and employees.

Red Flag #4: Key Management "in the cloud". Beware that nothing is safe "in the cloud".

Customer data storage, including keys, can only be securely maintained in the "cloud" with encrypted, de-identified numbers, where the access keys should be provided and secured by yourself. See also comments to Red Flag #16.

Red Flag #5: Service automatically detects and encrypts messages that contain personally identifiable information. This means that your service provider actively stores and scans all your communications.

Also sometimes mentioned as:
  • "Hosted solution that automatically encrypts email based on your policy definitions", or
  • "Automatically identifying messages that may be in violation of HIPAA, HITECH, or corporate security policies", or
  • "Messages are scanned for viruses to help ensure the integrity of messages sent through this service."
  • "We preserve search, sort and reporting operations by the cloud provider."
This red flag potentially exposes your business to covert surveillance, even if your files are encrypted at the server and you hold the keys. In addition, scanning your data may cause your information to be cached in plaintext, which militates against a "Safe Harbor" claim in case of a breach. This issue also falls within the Red Flag #1.

Red Flag #6: Ensure Business Associates understand HIPAA implications. This means that your business risk and reputation depends on others, who you cannot control. Instead, your security solution should limit the risk posed by others.

Red Flag #7: Keys provided by "Web-of-Trust". This means that there is no entity responsible for revocation of keys, or for assuring that the keys are up-to-date, or valid for the intended purpose. This may work with a group of friends, but not when your risk and reputation depend on it.

Red Flag #8: Require Users to Buy a X.509/PKI or S/MIME Certificate. For a variety of reasons, and not just cost, this has not worked since it was first proposed more than twenty years ago.

Even though conventional PGP and PKI/X.509 solutions are notoriously far too difficult to use, a number of providers use servers to automate some of the tasks that were previously done manually. While this does improve ease-of-use, it may compromise HIPAA/HITECH Safe Harbor conformance, and still has to deal with several limitations of the underlying technologies PGP and X.509/PKI.

For example, the lack of first-contact capability in PGP and X.509/PKI has been countered by server-solutions that set and request passwords, which reduces usability for first contact, creates online targets for username and password lists (see Red Flag #9), and sharply reduces security.

Red Flag #9: Protected with passwords. Passwords are notoriously insecure and their management is a nightmare even for a few dozen users.

Passwords are not considered secure by HIPAA, HITECH, the Federal Financial Institutions Examination Council (FFIEC), and other regulatory regimes. Compliant authentication solutions should use two-factor authentication, present familiar user interfaces (to prevent user errors), prevent dictionary attacks, and not store authentication credentials (such as passwords and usernames) online or, more desirably, anywhere.

Red Flag #10: Use the fax. It is possible for health care providers to use fax, voice mail, or even regular email and avoid a HIPAA violation. However, the cost, burden and liability to do so can be substantial under HIPAA, HITECH, and state privacy rules, including mandatory breach notification. Thus, using a fax makes it difficult to ensure privacy and implies added liability. Read more >>

Red Flag #11: Our employees are trusted. Your business data security should not depend on trusting the service provider's employees ("we promise we won't look"), who you cannot select, verify or control. It is known that more than 70% of all security breaches are due to internal causes. Not even the FBI can prevent having a national security traitor for many years among their own directors.

Red Flag #12: We train your employees. This means that your employees will need to be trusted to follow security procedures, which failure will fall on your business and is at the root of more than 70% of all breaches. See Red Flag #11.

Red Flag #13: Just install a plugin for your Mail client or Web browser. Also mentioned as "downloaded and installed in minutes". This means that you have to download an untrusted new component, that opens your system to new zero-day exploits, will need to be always updated, and may cease to work when you update your application or other plugins.

Red Flag #14: Delivered using a secure SSL/TLS encrypted connection. This delivery process falls short of basic security requirements for email messages (see below). See also Red Flags #1 and #5.

Red Flag #15: If the recipient is not registered, the message is sent to a secure portal. This actually means that the recipient must register anyway, and reduces usability.

Red Flag #16: We can use your information for purposes including... This statement may sound assuring but it is open-ended and does not exclude any purpose or person.

This Red Flag is actually worse than the notorious "opt-out" policy, where sharing your protected information is the default mode, as there is no limit that you can request (by opting-out) regarding the use of your protected information.

Red Flag #17: Beware of conflicts of interest between the distinct roles that may be played by the same service provider, which may increase both your risk and liability. Also called the "fox taking care of the hens" scenario.

For example, if (1) a service provider for secure email is also (2) a provider of anti-virus scanning service, then the service is potentially made aware of protected information and the "Safe Harbor" provision may not apply (see Red Flag #1).

Red Flag #18: Impossible to break. Our servers are in a secure facility. It is not a matter of if, but when.

Regardless of how safe and secure people claim something online is, there always seem to be someone who can eventually crack access to it. Not even US Department of Defense and Pentagon servers are secure.

Security claims should not depend on being "impossible to break" (the Fort Knox approach), but on the impossibility of finding anything of value when that happens. This strong concept of security does not assume any limitation on the attacker, which limitations are often found to be unrealistic but only after an attack succeeds.

The ZSentry technology supports this strong concept of security and operates with the principle that the ultimate and fail-safe defense against data theft is to not have the data in the first place. ZSentry mathematically eliminates references used in conventional security systems — which references can themselves become targets — so that an attack on references is effectively prevented. Consequently, main risk issues such as those caused by key or password file breach are actually eliminated.

2. Regulatory Compliance and Fines

These and other Red Flags are important because online security and encryption are gaining importance, for some very clear reasons:

  • Email phishing, spam, email disclosure, web site spoofing, and impersonation fraud ("identity theft") are major sources of fraud losses today.
  • Protecting consumer privacy is becoming a duty for organizations worldwide.
  • Organizations in regulatory privacy and security compliance regimes (e.g., HIPAA and FFIEC) need to communicate in a way that is compliant.
  • After 02/2009, fines for non-compliance (HITECH Act) have sharply increased up to $1.5 million.

For example, if you are in the health-sector, then you probably must comply with the US HIPAA (Health Insurance Portability and Accountability Act) and HITECH Act (Health Information Technology for Economic and Clinical Health Act of 2009) and other regulations.

However, a solution may be 100% HIPAA-compliant and yet expose your organization to hefty fines in case of a fault or breach, while another solution may present a HITECH Safe Harbor with no fines even if there is a breach. And any security solution must be, first and foremost, usable — otherwise, users will not adopt it, or use it poorly.

3. Security Technologies

For further consideration, and as summarized here, we also analyze the various technologies used in security products, using peer-reviewed metrics and considering usability as well as security.

There are five known security technology players: X.509/PKI, PGP, SSL/TLS, IBE (Voltage), and ZSentry. Even though there are many providers of security solutions, these are the only five known security technologies that can power any security solution of interest, excluding passwords as notoriously insecure.

Of the five players, PKI X.509 was released in 1988 and followed by the S/MIME extension for email encryption, PGP in 1991 (also later followed by an S/MIME extension), and the first practical IBE system was developed in 2000. SSL/TLS was first developed ca. 1996. ZSentry was first used in 2000, was applied to secure email in 2004, and became available to other online protocols starting in 2009. ZSentry also supports PKI/X.509 and PGP, and extends these standards in significant ways.


With PKI and PGP (with or without S/MIME), while their key management solutions are secure, they are notoriously at fault in terms of usability (due to complexity, certificate revocation, public-key signing and other issues reviewed in the references [*]). This, in turn, creates security problems because users are not able to correctly apply expected procedures.

For example, in the work of Alma Whitten and J. D. Tygar [*], the authors report on a user test demonstrating that when the test participants were given even 90 minutes in which to sign and encrypt a message, the majority of them were unable to do so successfully.

How about newer versions? User interfaces get flashier, help files get longer but the usability problems remain. After almost 20 years of development, improving the graphical user interface and the help dialogue in IT security products seems to have reached a point of diminishing returns.

Users find PKI or PGP public-key management hard to understand, hard to use, and counter-intuitive. When you send a postal mail, for example, you do not ask the recipient to first send you an envelope. And you do not ask who they trust. But that is what happens when you send a PKI or PGP message — you need to first ask the recipient for her public-key. Which must be digitally signed by someone that is trusted by someone you both must trust.


With IBE (Voltage, MessageGuard), while it is usable it is not secure (mandatory key-escrow, no key revocation, and other issues).

In IBE, the recipient's private key (which allows received messages to be decrypted) is provided by and is available at a server, the PKG (the Private Key Generator). In the IBE design, both the recipient and the sender must trust the PKG. But, for example, if the PKG provides the recipient's private key to other parties in addition to the recipient, this breaks the sender's message confidentiality. There is nothing that you, the sender, can do about it. You do not even know about it. There is a false sense of security. Oblivious to what is happening you may continue to send what, you think, are secure messages. This can happen without the recipient's cooperation or knowledge, in spite of assurances by the PKG and best efforts by the recipient to safeguard her private-key.

Because IBE has no key revocation, a compromised private-key cannot be terminated when desired. IBE has a built-in revocation delay that is equal to the time remaining for key expiration. This implies a very large or even undefined delay for key revocation.

Further, think about whether you want a hacker, a bug, a virus, or even someone working with the PKG server providing your "secure email" service, to have access to your private-key — the same private-key that can decrypt any email you send. You don't.


Due to its success in online sales transactions and online banking, SSL/TLS has been tried to provide email security functionality — for example, in one of the email-security solutions by Postini. However, SSL/TLS falls short of basic security requirements for email. For example, because SSL/TLS messages are only encrypted in-between servers, third parties can compromise message security and integrity at the security-gaps created at each end-point (i.e., not only at Postini but also at the user's ISP, DSL provider, and any other intervening server or cache system), and at the user's machine. This falls within the Red Flags #1 and #5.

Relying on SSL/TLS as the encryption mechanism for protecting the delivery of email messages also creates a single point of failure for all messages, which vulnerability can be remotely and anonymously exploited.


ZSentry avoids all the Red Flags above, is HIPAA compliant, and provides a HITECH Safe Harbor. ZSentry also overcomes the security and usability limitations of the conventional technologies PKI, PGP, IBE, and SSL/TLS, while supporting PKI/X.509 and PGP, and extending these standards in significant ways. ZSentry further supports SAML and SSO, so that it can be part of a federated-identity ecosystem.

The ZSentry technology operates with the "Sans Target" principle: the ultimate and fail-safe defense against data theft is to not have the data in the first place. ZSentry mathematically eliminates references used in conventional security systems — which references are themselves tar gets — and also sufficiently hardens passwords against dictionary or brute-force attacks. This is leveraged to protect other data, by encryption using the "Sans Target" keys. Consequently, the main risk issues such as those caused by key or password file breach are actually eliminated [1-2], so that the ZSentry solution can offer a HITECH Safe Harbor with no fines even if there is a breach.
>>Read more at HITECH Safe Harbor

Usability is also increased with ZSentry. In two security versus usability comparative analyses [1-2] of email authentication and encryption solutions using the technologies PKI, PGP, IBE, and ZSentry, the latter shows a marked synergy between security and usability. with ZSentry, increased usability increases security.
>>Read more at Why ZSentry?


[1] Gerck, E. (2007). Secure email technologies X.509/PKI, PGP, IBE and Zmail. In Corporate Email Management, Chapter 12, Edited by Krishna SJ, Raju E., pp.171-196, Hyderabad, India, ICFAI University Press. Available online at http://email-security.net/papers/pki-pgp-ibe-zmail.pdf.

[2] Neppe, V. M. (2008). The email security-usability dichotomy: Necessary antinomy or potential synergism?. In Telicom, 21:3, May-June, pp.15-31. Available online at http://email-security.net/papers/usable-secure-email.pdf.

[3] Whitten, A. and Tygar, J. D. (1999). Why Johnny can't encrypt: A usability evaluation of PGP 5.0. In Proceedings of the 8th USENIX Security Symposium. Available online at http://www.gaudior.net/alma/johnny.pdf

[4] Feghhi, J., Feghhi J., and Williams, P. (1998). In Digital Certificates: Applied Internet Security. Addison-Wesley, ISBN 0-20-130980-7.

More on this topic: Comparisons and Technical Review »
Main Technical Notes
Overview   Key Features   ZSentry App   ZSentry Client   API   Smart IT   SAML & SSO
  Security   Usability   HIPAA & HITECH   Experience   Why ZSentry?   Red Flags   SUMMARY

Development and © by NMA

Trademarks and Copyrights as described in our Legal Statement. We protect Your Privacy.