I am a Zivver admin
Configure and manage Zivver
Email Security Policies
Introduction
Zivver offers different verification methods to senders and their organizations to ensure that information is sent with the right level of protection. These methods range from asking the recipient to enter an SMS code before reading the message, to allowing direct access without additional verification. This way, the receiving organization can securely exchange information with minimal impact on daily work processes.
Organizations can configure their own Email Security Policy in Zivver. Such a policy can consist of a mix of verification methods. End users can then select the most appropriate method for their message. Some verification methods are applied automatically, while others can be chosen manually.
Which methods apply to a specific message depends on the type of information being exchanged, as well as on the sender and/or recipients. For example, it is not always possible or necessary to apply the highest level of security.
This document explains the different verification methods. With these options, an organization can configure its own Email Security Policy in Zivver.
Verification Methods
When a Zivver message is sent, the following verification methods may be applied. These are divided into three categories: Basic, Special, and Transport Security Compliance.
Basic verification methods
- Zivver
- SMS code
- Access code
- Verification email
Special verification methods
- NTA 7516
- Inbound direct delivery (IDD)
Transport Security Compliance
- TLS
- PKIX
- PANE
- DANE
Basic Verification Methods
The following verification methods are part of the basic set that Zivver offers to organizations out of the box.
- Zivver
- SMS code
- Access code
- Verification email
Each method is explained below. In the chapter Setting up an Email Security Policy you will learn how to enable or disable a specific verification method for your organization.
Zivver
When the recipient has a Zivver account, the message can be read after logging in. This verification method is applied automatically whenever the recipient has a Zivver account, whether it is a free account or part of an organization. Every Zivver account is protected with two-factor authentication (2FA), so the recipient can only read the message after logging in and presenting 2FA. The sensitive information itself is never delivered to the recipient’s inbox; instead, a notification message is delivered.
Because this method is applied automatically, it cannot be changed by the end user.
SMS code
When a message is protected with an SMS code, the recipient can read it only after entering the code received on their mobile phone. This provides two-factor authentication (2FA). Again, the sensitive information is not delivered to the inbox; only a notification message is delivered.
This method can be used when the recipient’s mobile number is known before sending the message. There are several ways in which a mobile number can be used:
- If the recipient’s mobile number is available in the Outlook Address Book, it is automatically selected. This option is only available when using Microsoft Outlook for desktop together with the Zivver Office Plugin.
- The sender manually enters a mobile number for the recipient.
- If the recipient previously received and opened a Zivver message from the sender that was protected with an SMS code, the same number is stored in the sender’s personal Zivver Contact Book and automatically selected.
- If the recipient’s mobile number is stored in the organization’s Shared Contact Book in Zivver, that number is automatically selected.
Zivver clients may also prompt the sender to enter the recipient’s mobile number to apply SMS code verification.
Access code
When a message is protected with an access code, the recipient can only read it after entering the code. The sensitive information is not delivered to the recipient’s inbox; only a notification message is delivered.
This method can be used when the sender and recipient can exchange the access code outside of email (e.g., face to face or over the phone). The access code is not a password with complex requirements but a simple code agreed upon between sender and recipient.
If it is not possible to share the access code directly, the sender can provide a hint instead. For example, the access code could be the recipient’s patient number, which can be found on their hospital card. The hint is displayed on the login screen where the recipient must enter the access code.
Ways to apply access codes include:
- The sender enters a new access code for the recipient.
- If the recipient previously received a message from the sender protected with an access code, the same code is stored in the sender’s personal Zivver Contact Book and automatically selected.
- If the recipient’s access code is stored in the organization’s Shared Contact Book in Zivver, it is automatically selected.
Verification email
When a message is protected with a verification email, the recipient must enter a verification code to read the message. On request, this code is sent to their email address. The sensitive information is not delivered to the inbox; only a notification message is delivered.
The verification email is not intended to provide two-factor authentication (2FA). Instead, it verifies the recipient’s email address, making it more difficult for someone else to read the message if the notification is forwarded.
In the Zivver Office Plugin, there is a setting to automatically apply the verification email method when the sender has not selected any other method. Refer to the Zivver Office Plugin Registry Keys manual for more information.
Special Verification Methods
- NTA 7516
- Inbound direct delivery (IDD)
In the sections below, each method is explained.
NTA 7516
The message is delivered in accordance with the NTA 7516, the Dutch norm to exchange healthcare and legal information. This method is only available when both the Sender and the Recipient meet the NTA 7516 requirements.
Inbound Direct Delivery (IDD)
When a message is received with Inbound Direct Delivery (IDD), the message is directly readable by the Recipient. This means that there’s no Zivver client needed to decrypt the message. Examples of a Zivver client are the Zivver Office Plugin and the Zivver WebApp.
With IDD, organizations can securely receive messages in a Document Management System (DMS) or a Customer Relationship Management (CRM) application, for which no Zivver client is available.
Note that all other verification methods discussed in this manual are about delivering information with the right level of security to a Recipient. IDD is used to receive information with the right level of security.
IDD is only available for organizations with a Zivver license. To securely deliver sensitive information, the receiving mail server of the organization must meet one of the following requirements:
- TLS v1.2 and higher + a valid certificate, or
- DNSSEC + a valid certificate, or
- DANE
In addition to the requirements for the mail server, the receiving domain must be claimed within the Zivver organization.
IDD can be combined with the use of a Zivver client. For example, receiving an IDD message in Microsoft Outlook for desktop with the Zivver Office Plugin installed. In that case, the End User will still see the Zivver conversation when viewing a securely received message. However, in the inbox they no longer receive a notification message, but directly the decrypted message.
Transport Security Compliance
Transport Security Compliance provides an alternative to the basic verification methods to ensure that sensitive information is protected at the appropriate security level. Although the basic verification methods may offer a higher level of security, this is not always required for every message.
When a basic verification method is applied, a notification message is delivered to the recipient. With Transport Security Compliance, this does not happen: the sensitive information is delivered unencrypted. This allows a guest recipient to read the message immediately in their mail client.
The following verification methods are part of the set of minimal security levels offered by Transport Security Compliance:
- TLS: TLS v1.2 and higher
- PKIX: TLS v1.2 and higher + a valid certificate
- PANE: PKIX + DNSSEC
- DANE: DNSSEC + TLSA
If the receiving mail server supports the requested minimal security level, the message will be securely delivered unencrypted. If the receiving mail server does not support the requested minimal security level, the basic verification methods can be used instead.
Verification methods compared
The table below provides an overview of the different verification methods compared with each other.
Category | Type | Applied | When to use | Recipient receives |
---|---|---|---|---|
Basic | Zivver | Automatically, can’t be changed | The recipient has a Zivver account. | Notification message |
SMS code | Automatically or manually | The mobile number of the recipient is known before sending. | Notification message | |
Access code | Automatically or manually | The sender and recipient can exchange an access code without emailing it. | Notification message | |
Verification email | Automatically or manually | When it’s not possible or necessary to protect the message with a higher security level. | Notification message | |
Special | NTA 7516 | Automatically, can’t be changed | When both the sender and the recipient are NTA 7516 compliant. | Directly readable |
Inbound Direct Delivery | Automatically, can’t be changed | When the recipient has enabled Inbound Direct Delivery in Zivver. | Directly readable | |
Transport Security Compliance | TLS / PKIX / PANE / DANE | Automatically | When the recipient’s mail server supports the requested minimal security level. | Directly readable |
Setting up an Email Security Policy
Organizations can determine in their Email Security Policy which verification methods are available for employees to protect information at the appropriate security level. The basic verification methods are automatically enabled and can be viewed and modified by a Zivver admin on the Verification Methods settings page.
The Special Verification Methods and Transport Security Compliance are handled differently:
NTA 7516 Refer to the NTA 7516 Compliance Manual for more information on meeting the NTA 7516 requirements. Once these requirements are met, this verification method is automatically available to Senders when the Recipient is also NTA 7516 compliant.
Inbound Direct Delivery (IDD) IDD settings are a premium feature. Send an email to Sales to make these settings available for your organization. Once enabled and when the technical requirements are met, IDD can be configured here.
Transport Security Compliance Send an email to Support to make one of the Transport Security Compliance verification methods available for your organization.
Mail Submission
With Mail Submission, organizations can automatically send messages securely from any application that can use a custom SMTP connection. In a Zivver client, the End User can see which verification methods are available for the Recipient. This is not possible when a message is securely sent via Mail Submission.
Therefore, Mail Submission automatically applies a verification method in the following order:
- Zivver
- NTA 7516
- SMS code
- Access code
- Inbound direct delivery (IDD)
- Transport Security Compliance
- Verification email
If verification email is disabled in the Email Security Policy of the organization, it can still be applied to messages sent via Mail Submission. This is done to prevent the message from failing to send when none of the other verification methods apply.
Refer to the Mail Submission manuals for more detailed information. Mail Submission is an additional functionality in Zivver. Contact Support if you have any questions about whether Mail Submission is included in your contract with Zivver.