Threat models & security FAQ

Threat models are an essential part of building secure systems. Establishing a threat model means understanding the robustness of a system against a given attacker and context. At Privy, we work to communicate these threat models clearly so developers and users can protect themselves and their assets effectively. We break down some threat models below. Please reach out to us at [e-mail] if you have any questions.

As a reminder, Privy works to secure user assets and data in three main ways:

• Proactive security: Privy systems are engineered and built with security in mind. This means resource isolation and cryptographic architecture layered with a defense-in-depth approach, designed to protect your wallets. This also means doing cryptographic and infrastructure audits on a quarterly basis, as well as running a Vulnerability Disclosure Program and active Bug Bounty Program.
• Active monitoring: Privy systems are instrumented for active monitoring. This means automated alerts triggered by unexpected or abnormal activity and an on-call engineering team on standby 24/7. As our customers deploy apps, we work to monitor activity across the threat landscape online and collaborate with service providers to take down malicious threats.
• Defensive measures: Privy is built with failsafes to enable developers and their users to cut off access to key material in the event of an emergency. We work on pre-approved procedures for such instances with our enterprise customers and are always at the ready to protect user assets in the case of attack.

If you’re a researcher interested in participating in our Bug Bounty or you believe you’ve detected a malicious threat relevant to Privy’s work, please reach out to [e-mail].

Security philosophy

Security is continuous work, not a one-time achievement. We recognize that wallets are not one size fits all, and we build highly configurable, flexible wallet infrastructure so you can configure the system appropriate for your use-case. Moreover, security needs evolve as asset value grows.

We give developers flexibility to build appropriate experiences while guiding them toward security best practices. We support the full spectrum from email-based embedded wallets to hardware-secured cold storage, recognizing the inherent tradeoffs in any cryptosystem.

Understanding threat models

The below summarizes some key questions but is not exhaustive. Please reach out for a deeper discussion on threat modeling or other attack strategies.

Cross-application security

Q: Can unauthorized applications access the Privy iframe?

No, as long as your administrators configure your app with the proper allowed origins in the Privy dashboard. Privy has a permissive default to bootstrap the rapid development of apps, but when taking an app to production and the allowed origins are set, the served iframe enforces that all frame ancestors must be within those allowed origins. This is enforced by both frame ancestor CSP checks and in-code origin validation.

Q: Can unauthorized applications send messages to the Privy iframe?

No, as long as your administrators configure your app with the proper allowed origins in the Privy dashboard. The Privy iframe only accepts messages from its parent frame, which is usually under the control of the application developer. The iframe message handler checks the origin of messages received and confirms they are from an approved parent origin. Additionally, the Privy iframe requires a valid access token to authenticate messages received from its parent frame.

Q: Can a Privy customer’s application interfere with another customer’s iframe?

No. Browser security controls and DOM boundaries isolate one customer’s iframe from another customer’s application context. Iframes are separated by the browser’s same-origin policy and process isolation mechanisms, so they do not share DOM or memory across origins.

User security

Q: Can an unauthorized user access another user’s wallet?

No. A valid access token is required to access a wallet. Specifically, the user’s access token is required to retrieve the auth share needed to reconstruct the wallet. Access tokens are only granted to authenticated users and as per the application’s configuration. Here’s an example recipe of how to configure a React-based application to use cookies.

Q: How are users protected if their browser is compromised?

A compromised browser cannot reconstruct a private key unilaterally. For TEE-based embedded wallets, no complete share exists on the device: one share is only accessible inside our Amazon Nitro Enclave-based TEE, and the other is held encrypted by Privy’s authentication service, each useless without the other.

Additional layers of protection include:

• MFA for wallet operations: developers can require users to re-authenticate before any signing operation, raising the bar for session hijack attacks
• Access token revocation: compromised sessions can be invalidated immediately, preventing further signing requests from completing
• Key never persisted in full: the private key is only transiently available inside the TEE during signing and is never written to disk or local storage in any form
• If a compromise is detected, developers should revoke the user’s access token and, for high-value wallets, prompt the user to re-authenticate and rotate their recovery configuration.

Browser security

Q: Can bookmarklets and browser extensions inject malicious Javascript into the iframe?

In certain cases, yes. There is a CSP nonce on the embedded wallet iframe and the embedded wallet key export page. This means browsers are able to verify the iframe code via a server-set nonce, and additionally reject unauthorized code. We block extensions with CSPs that violate the unsafe eval directive.

However, it’s important to understand that bookmarklets and extensions have elevated permissions and may have access to things such as browser requests and responses. According to the W3C CSP standard, browser implementations should allow user-agent features to override policies. Browsers enable bookmarklets and extensions to bypass CSP settings and inject Javascript code onto pages. We recommend educating users to not install untrusted bookmarkets and browser extensions. Furthermore, we recommend enabling wallet MFA which requires the user to MFA to approve transactions.

Q: What happens if browser security is compromised?

We maintain multiple layers of protection:

• Emergency kill switches for immediate response
• Access token revocation capabilities
• Geographic access restrictions
• Rapid incident response procedures
• Regular security updates

Infrastructure security

Q: Can a compromised Privy team member access user keys?

No. Keys exist only as encrypted shares distributed across security boundaries. Wallet actions are only accessible within secure execution environments.

Q: Can a compromised engineer deploy unauthorized code?

No. Privy maintains a robust deployment security system with multiple independent controls. Code deployed to secure execution environments undergo extensive review and security controls, including strict multi-party approvals.

All code changes require review from multiple designated owners, must pass automated security testing, and go through staged deployments with additional approvals. The Privy CI/CD pipeline ensures build artifacts are deployed directly from protected source code, with branch protection rules and signing requirements. This process is regularly audited and monitored to prevent unauthorized modifications.

Custody and control

Q: Does Privy hold my users’ private keys?

No. Privy never stores a complete private key. When a wallet is created, the private key is generated inside a trusted execution environment (TEE), immediately split into two shares via Shamir’s Secret Sharing, and discarded. One share (the enclave share) is sealed to Amazon Nitro Enclave hardware and cannot be decrypted outside it. The other (the auth share) is encrypted at rest and released only when the user authenticates. Neither share alone is sufficient to reconstruct the key, and Privy cannot do so unilaterally.

Q: Who controls the private keys in a Privy embedded wallet?

The user does. Privy’s embedded wallets use a 2-of-2 key-share architecture where both shares are required to produce a signature. The enclave share is inaccessible outside the TEE hardware, and the auth share is gated behind the user’s authenticated session. In this default configuration, a signature can only be produced when the user provides valid authentication, which triggers time-bound key reconstruction inside the TEE. The key is wiped immediately after signing. Note: developers can optionally configure session signers or agent signers that allow a server to sign within policy constraints without per-transaction user approval — in those configurations, signing authority is shared between the user and the developer’s backend according to the policies set.

Q: Is Privy a custodial or non-custodial wallet solution?

Privy supports both models depending on wallet type and configuration. Embedded wallets are non-custodial (self-custodial) by default — user custody is cryptographically enforced by the 2-of-2 key-share architecture, and neither Privy nor any single infrastructure provider can sign a transaction unilaterally. However, Privy also offers server wallets (developer-controlled, no end-user in the signing loop) and agent-controlled wallets where the developer’s backend operates autonomously within policy constraints. The custody model is a developer choice, not a platform-wide absolute.

Q: Can Privy access or move funds from my users’ wallets?

Not unilaterally. For TEE-executed embedded wallets, Privy stores an app share and a TEE share encrypted to the enclave’s public key; the encrypted TEE share can be decrypted only by the authorized TEE.

When necessary, key material is reconstructed transiently inside the TEE to sign a transaction. The TEE enforces the wallet’s configured authorization and policy controls, so Privy cannot retrieve a usable private key or sign arbitrary transactions.

If a developer configures session signers, agent signers, or other delegated permissions, those signers can execute transactions within their granted scope without per-transaction user approval. This is delegated authority configured for the wallet, not a general ability for Privy to move funds at will.

Centralization

Q: Does Privy create a single point of failure for key management?

No. The 2-of-2 Shamir share architecture means compromising any single component — Privy’s storage, the TEE provider, or the user’s authentication — is insufficient to reconstruct a private key. An attacker would need to simultaneously compromise both the Amazon Nitro Enclave hardware and Privy’s auth share storage while also possessing valid authentication credentials. For wallets configured with session signers or agent signers, the developer’s backend holds additional signing authority scoped by policies — but this authority is explicitly granted by the developer and constrained by Privy’s policy engine, not a bypass of the key-share model.

Q: How does Privy prevent unauthorized access to private keys, including by Privy itself?

By design, no single Privy system or employee can reconstruct a private key. For TEE-backed wallets, key material is split across separate trust boundaries: Privy stores the app/auth share and an encrypted TEE share, but the plaintext TEE share can only be decrypted inside an attested AWS Nitro Enclave. Full private keys are reconstructed only temporarily inside the enclave after authentication and policy checks pass.

Privy uses both code-level and hardware-level controls for this path. Enclave code changes go through multi-party review, automated security testing, signed build controls, and staged rollout. Nitro attestation then verifies the enclave’s measured boot state before secrets are available, ensuring key material is only handled by approved code running in the expected hardware-isolated environment.

Q: What is Privy’s trust model — does it require trusting Privy as an intermediary?

Privy’s trust model is “trust but verify with cryptographic guarantees.” You trust that the TEE is running attested code (verifiable via Amazon Nitro attestation) and that Shamir’s Secret Sharing is correctly implemented. You do not need to trust that Privy employees will choose not to access keys — the architecture makes it impossible for them to do so, regardless of intent.

Portability and lock-in

Q: Can users export their private keys from Privy?

Yes. Users can export their full private key via the client SDK key export flow or the REST API (POST /wallets//export). The exported key is a standard elliptic-curve private key (secp256k1 for EVM chains, ed25519 for Solana) that works with any wallet provider, hardware wallet, or self-hosted solution.

Q: Can I migrate my users’ wallets away from Privy?

Yes. Because Privy wallets use standard key formats, exported keys are portable to any provider. For server wallets, developers can export keys programmatically via the API. The wallet addresses remain the same after export since they are derived from the same underlying keypair.

Q: What data and key material can developers port if they leave Privy?

Developers can export: private keys (full elliptic-curve keys in standard format), wallet addresses, and user identity mappings. Transaction history lives onchain and is inherently portable. Authentication data (linked emails, social accounts) can be mapped to a new provider during migration using Privy’s user export capabilities.

Q: Am I locked into Privy’s infrastructure once I integrate?

No. Privy uses standard key cryptography (secp256k1, ed25519), standard chain protocols, and standard authentication patterns. There is no proprietary key format, no custom chain requirement, and no contractual lock-in on key material. The key export API exists specifically to ensure developers and users can leave at any time with full control of their assets.

For security questions not covered here or to report a security concern, contact us at [e-mail]. If you’re a security researcher interested in our Bug Bounty Program, please reach out to the same address.