These are some questions we are frequently asked by our customers.


Below you'll find questions related to encrypting data.

What encryption scheme does Evervault use?

You can learn more about the Evervault Encryption Scheme (EES) here.

Do I need to manage encryption keys?

No. Simply include our SDKs and Relay your data or deploy your functions to an Evervault Function. We handle everything else.

Why is there no decrypt function in the Evervault SDKs?

Traditionally, encryption has only been useful if it was a reversible transformation, i.e. if the encrypted data could be reversed back to its original, unencrypted form. If encryption was not reversible, the encrypted data was considered unreadable and unusable. This is why most encryption libraries have a decrypt() function available.

Evervault Functions and Relay make the need for a decrypt() function redundant.

Functions are secure, serverless functions for processing encrypted data. That is, encrypted data remains readable and usable — without the need for a decrypt() function being available.

You can deploy a Function to return data in its unencrypted form. Function runs are logged so that you can see who accessed plaintext data.

Relay is a proxy for encrypting data before it touches your API, and for decrypting it as you send it to a third-party API or return it to your users. Decryption takes place in E3, so no decrypt() function is necessary in our SDKs.

Why is Evervault better than encryption at rest and in transit?

Encryption in transit (using TLS) protects against man-in-the-middle attacks between the client and your server.

Encryption at rest (at the disk-level, file-system-level, and database-level) protects against someone taking the physical drive from your machine and overriding your file-system, and prevents a non-authenticated admin accessing your database.

However, neither encryption in transit or at rest protect against a malicious agent on your server because data still gets decrypted to be processed.

With Evervault, data never exists on your infrastructure in plaintext — so it can never be lost or leaked.

Why is Evervault better than open-source encryption libraries?

There are two core reasons why Evervault is better than encryption libraries:

1. No plaintext data on your infrastructure

With encryption libraries like Web Crypto and Tink, you still need to decrypt sensitive data to process and get value from it. With Evervault, sensitive data is never decrypted (i.e. never exists in plaintext) on your infrastructure—so you cannot lose or leak it.

2. No need to manage encryption keys

With encryption libraries, you still need to manage encryption keys. Using Evervault means that you do not need to manage encryption keys. We take full responsibility for key management. The way we configure key management means that Evervault cannot decrypt your data—because your app’s API key is necessary for decryption.


Below you'll find questions related to storing encrypted data.

Where do I store data I encrypted with Evervault?

You store the data in your database as normal. There’s no need to change your data structure or format.


Where are my Evervault API keys?

Your API keys can be found in Settings.

Is Evervault compliant?

Evervault are a PCI DSS Level 1 Service Provider and SOC 2 Type II compliant. We can enter into BAAs under HIPAA. Request our reports

Evervault's Setup Guide

As when using any cloud based application there are always areas where both the consumer and service provider will have to manage information security responsibilities. Evervault follows the traditional SaaS model for security responsibilities. Evervault are responsible for the systems used to deliver the proposed services, and the customer is responsible for the data you chose to put through our systems & how you interact with our systems.

Securing your credentials to access our platform is a critical step in protecting your environment. We have made several options available to enhance the security of access to the platform. It is up to you to ensure these are configured. In addition to standard good security hygiene, at a minimum Evervault suggest the following security good practice when using Evervault Securely:

Management Plane Access

  • Implement an approval process for access and monitor account activity
  • Allocate access on a least privilege basis
  • Allocated credentials to individual users, do not share accounts
  • Quickly Amend / Remove User Access when no longer required
  • Frequently Review Access
  • Store and Share Credentials and API keys Securely
  • Rotate API Keys when administrator leaves
  • Select robust hard to guess passwords
  • Enable Multi-factor authentication
  • Disable Accounts immediately if you suspect compromise and alert for further support.
  • Store your API key in a secure secrets manager application
  • Configure logging and alerting to record any access to / unexpected activity involving the API key

Data Plane (

  • Constantly review the fields that you have chosen to encrypt to ensure they are adequate
  • Constantly review the chosen destination end points for your encrypted and decrypted data flows
  • Implement a change and approval process to authorise changes to destinations and fields
  • Adhere to Evervault patch advisories if SDKs are in use