Skip to main content

Architecture and Security

Security is a moving target as the web changes and stacks evolve. Truly secure systems are hard to build and easy to misconfigure. Privy exists so you can better secure your users' data and focus on what you do best: building your core product. Our software aims to raise the bar for security as pertains to user data and level the playing field so you can compete with incumbents without having to choose between user experience and user safety.

We are working to empower users to regain agency over their digital identities and developers to build better products without putting users at risk. This all starts with secure systems and sensible defaults. Ultimately, you should not have to trust Privy if you do not want to, be it as an end-user or as a developer. Nonetheless, we will continue hosting secure building blocks for the Privy system to make your life simpler and more secure, should you choose to use them.

The below provides an overview of Privy's architecture and threat model as pertains to managed infrastructure. Please reach out ( if you have any questions: we want to hear from you!

How Privy worksโ€‹

The diagram below shows how data flows from a user's device to an encrypted datastore with Privy.

  1. The user inputs their sensitive data in their client device.
  2. Privy's client libraries fetch a wrapper key from a secure keystore. A unique key is used for each data field.
  3. Privy's backend checks to make sure the requester has permission to write to this field.
  4. The data is encrypted on the user's device using the unique key fetched.
  5. The encrypted data is safely stored in a managed datastore. Privy never sees plaintext data.

Privy's client libraries encrypt data client-side using a unique key for each data field. Today, keys can only be decrypted using a hardware security module run on a hardened network. Additionally, you can configure fine-grained access control to this data using Privy's API. The encrypted data is ultimately stored in remote storage managed by Privy. This is backed by transparent audit logs so your users can audit what is happening to their data.

Finally, the client libraries are open source, so that you can be sure about the code that's running.

Using Privy, you can take on user data without storing it on your stack or putting it at risk. We handle the cryptography security so that you don't have to.


Privy brings together 4 main components:

  • Privy KMS โ€” Privy's Key Management System (KMS) handles encryption and key management. It ensures no unencrypted user data ever leaves the client.
  • Permissions โ€” The permissions layer enables you to configure fine-grained access control to user data.
  • Datastore โ€” The datastore guarantees redundancy, fast access and compliant storage of user data.
  • Client libraries โ€” The client libraries encapsulate the full functionality of Privy in simple SDKs and APIs.

Privy KMSโ€‹

All user data is encrypted by the Privy client using a hybrid encryption scheme. Specifically, data is encrypted using symmetric keys generated client-side.

The symmetric keys are then encrypted and stored alongside the data. They are encrypted using public keys generated by remote Hardware Security Modules (HSMs) managed by Privy's Key Management System (KMS). Private keys are never exposed anywhere outside of the HSM.

Privy currently uses:

  • Symmetric authenticated encryption scheme: AES-256-GCM.
  • Public-key Cryptography scheme: RSAES_OAEP_SHA_1, with 2,048 bit keys.

The KMS is easily upgradable, and Privy ensures your data protection is future-proof and leverages the best cryptographic algorithms.

All operations on plaintext data are run client-side by default. Privy never reuses cryptographic material across Privy customers, and automates the generation of new data keys for each and every piece of user data it handles.


Any request to the Privy ecosystem first goes through the permissions oracle to determine whether it should be executed.

You can configure the oracle using the Privy configurations API or the Privy console. This allows you to set appropriate permissions on every data field for each user.


Privy securely stores your encrypted user data, indexed by user ids that you define (for example: a user wallet address), in a managed datastore. You can configure your datastore to receive structured and unstructured data, stored in the appropriate regions to minimize latency. We guarantee data availability and redundancy. All data is stored encrypted, and cannot be accessed without the appropriate data permissions.


To get in touch with the Privy security team, please reach out to

Through all of the below systems, we adhere to principles of transparency (no security through secrecy) and least privilege. Our communication channels are end-to-end encrypted, any Privy data is encrypted at rest and all user data is encrypted client-side using keys secured by the user themselves or in specialized architecture segregated from the rest of the Privy stack. All data access is scoped by roles and we rely on strong user authentication to identify requesters. We are working to surface immutable audit logs to developers and end users to make Privy activity easily auditable.


This page is mostly about Privy managed infrastructure. As Privy decentralizes some of its infrastructure, these details will be provider-specific.

High-level guaranteesโ€‹

Privy makes the following guarantees:

  • Privy never accesses any user data at any time.
  • Only requesters with the appropriate permissions can access and decrypt data they are entitled to see.
  • Only the data admin can set permissions for any data.
  • Any data stored with Privy can be easily exported.

Today Privy manages the following architecture:


All user data is encrypted client-side using AES-256-GCM and keys generated client-side. These keys are encrypted using asymmetric keys managed server-side (or in the future by the user and secured by HSMs).

  • Third Party VPC -- runs HSMs and HSM audit logs.
    • Privy uses a third-party provider (AWS) to run its FIPS 140-2 validated HSMs in order to generate and secure encryption keys for every Privy end-user.
    • All HSM activity is logged by a third-party audit log.
    • Only the KMS can connect to the HSM to run a limited set of cryptographic operations.
    • Only the HSM can write to the audit log.
  • Hardened VPC -- runs the KMS.
    • Privy runs a Key Management Service from within a hardened network.
    • Machines in this environment are locked down and do not accept SSH connections.
    • Code deployed in this environment is not continuously integrated but has been reviewed by multiple Privy team members.
    • Any call to the KMS must be made by an authenticated requester.
  • Privy VPC -- manages permissions and stores user ciphertext.
    • Runs a microservices architecture in a secure cloud environment.
    • SSH access is limited to authorized Privy developers.

If Privy's VPC were to be breached, an attacker would only gain access to the encrypted user data in question. Privy would then trigger reencryption to reencrypt all user data and flush all keys with corresponding compromised ciphertext from the KMS.

Traffic managementโ€‹

All traffic to,, and related subdomains is routed through Cloudflare. All of Privy's servers run within private VPCs on AWS.

TLS Encryptionโ€‹

All traffic is encrypted with a minimum supported TLS version of 1.2 and HSTS.

Backups and durabilityโ€‹

Privy takes full database snapshots on a daily basis and uploads transaction logs for database instances to backup storage every 5 minutes. These snapshots are stored for 7 days, accordingly Privy can safely restore databases to any point in the last week (with 5 minute granularity) as needed.

Encryption at restโ€‹

Privy-managed databases are encrypted at rest, independently from the fact that any user-data is itself encrypted end-to-end.

Audit logsโ€‹

Privy's HSM system currently has immutable audit logs generated via Amazon Cloudwatch. Every wrapper key generation, and data key encryption or decryption event appends an entry to the log. In parallel, Privy logs data accesses from the KMS. Privy plans to open up these logs to all users and developers in the near future. This will enable end-users to verify how their data is used, as well as developers to audit HSM usage on their end.

Developer Authenticationโ€‹

Privy currently supports email/password authentication. All passwords are hashed and salted using bcrypt. No preimages are stored with Privy. Additionally, passwords must have a minimum length of 10 characters, including non alphanumerics. Password resets are done using randomly generated tokens that expire after 6 hours.

End-user Authenticationโ€‹

Privy supports multiple authentication methods for end-users. Today, this means JWT-based authentication or authentication based on a user's own web3 wallet.

Privy piggybacks off of developers' existing auth system using JWTs. The appropriate admin on the developer-end can sign the appropriate JWT to authenticate their user. Privy generates Ed25519 keys based on the API secret.

The API secret is never stored on Privy servers and cannot be recovered once downloaded. Privy client libraries enable JWT generation and signing client-side on the developer stack. A developer can also override this default behavior to use custom signing keys to sign JWTs.

Allowable JWT signature algorithms include:

  • RSA: RS256, RS384, RS512
  • EdDSA: EdDSA (Ed25519 keys)
  • Elliptic curve: ES256, ES384, ES512

End-users can also authenticate directly with Privy using their existing cryptocurrency keys. Privy integrates directly with existing standards like Sign in with Ethereum (SIWE) through which users can sign messages to authenticate themselves directly with Privy. All such authentication is done using client-side signatures generated with user keys that never leave user wallets.

Data accessโ€‹

Select Privy developers can access customer metadata in order to help with any troubleshooting or outstanding issues. This includes data like field names, end-user ids, or access group compositions. Privy's systems are designed such that customer metadata cannot be accessed without explicit customer approval.

Privy cannot access end-user data without signficant modification to its systems and will never do so unless compelled to do so under threat of law.

Code audits, pentesting and bug bountiesโ€‹

Privy's client libraries are open-sourced and have undergone multiple rounds of reviews by security engineers and cryptographers. Privy's internal infrastructure has undergone multiple rounds of audits by third-party testers and developers, as well as a round of pentesting.

Security is a constantly moving target and we will undergo such auditing and testing multiple times a year on a regular basis to surface and address new issues.

We will be setting up a bug bounty program in the near future. Please get in touch with the security team at