Skip to main content
Para’s security model is built on a simple principle: no single party (not Para, not the integrating application, not even the user’s device alone) ever holds a complete private key. This eliminates the most common attack vectors in wallet infrastructure and provides a foundation that compliance and security teams can trust.

Security at a Glance

PropertyWhat it means
Non-custodialPara never has access to users’ full private keys
No single point of failureKeys are split across the user’s device and Para’s hardware security modules. Compromising one reveals nothing useful
Phishing-resistantPasskey-based authentication means there are no passwords to steal, no seed phrases to phish
Censorship-resistantUsers can export their key share and sign transactions independently if Para is ever unavailable

Why This Matters

For product teams: Non-custodial wallets unlock capabilities that custodial models can’t offer:
BenefitWhy it matters
Day-1 asset accessUsers hold their own keys from the moment of wallet creation, with no waiting for custodial onboarding or KYC approval before they can receive and use assets
Global expansionNon-custodial infrastructure avoids per-jurisdiction money transmitter licensing, enabling faster launches in new markets without wallet-layer regulatory blockers
No key management burdenPara handles MPC, HSMs, and signing ceremonies so our partners can confidently deliver new product features
Seamless UXBiometric login, no seed phrases, instant wallet creation: users get a familiar experience while your app gets enterprise-grade security underneath
User trust and retentionUsers own their assets outright. There’s no platform risk: even if your app goes offline, users retain full control of their wallets
For compliance and risk teams: Para’s non-custodial architecture means the integrating application can move faster, minimizing licensing obligations that come with custodial wallet models. Every transaction is checked against an approved permissions policy before signing, creating an auditable enforcement layer. For security teams: Threat models are significantly reduced. Integrating applications don’t store private keys, so a breach of their infrastructure doesn’t expose user assets. Para’s MPC signing ensures that even a compromise of Para’s systems alone cannot produce valid signatures.

How Keys Are Protected

Para uses a 2-of-2 Multi-Party Computation (MPC) system where the private key is split into two shares (one on the user’s device, one in Para’s cloud HSMs). To sign a transaction, both shares participate in a cryptographic ceremony that produces a valid signature without ever reconstructing the full private key. Neither Para nor the integrating application ever sees the full key. This is true during key generation, signing, and recovery.

Key Management

Deep dive into MPC implementation, distributed key generation, hardware secure enclaves, passkeys, and how MPC compares to multi-sig.

Authentication

Para supports multiple authentication methods to fit different user bases and product requirements.

Email and Social Logins

MethodDetails
EmailPasswordless login via email verification
PhoneSMS-based verification
GoogleOAuth social login
AppleOAuth social login
Twitter/XOAuth social login
DiscordOAuth social login
FacebookOAuth social login

Additional Account Protection Options

MethodDetails
PasskeyBuilt on the WebAuthn standard. Phishing-resistant, origin-bound, biometric verification via Face ID, fingerprint, or device PIN
PINNumeric PIN set by the user
PasswordTraditional password-based login
These options can be layered on top of authentication to provide additional security when authorizing transactions.

Session Management

Para uses sessions as a security measure when signing transactions. The default session length is 90 minutes. Sessions can be refreshed, and developers can configure session length in the Security section of the Developer Portal.

Encryption and Secure Communication

All communication between the user’s device, Para’s servers, and connected applications is encrypted:
  • TLS for all network communications
  • End-to-end encryption for sensitive data in transit
  • Encryption at rest for all stored user data

Censorship Resistance

Para’s architecture ensures users maintain control over their assets even if Para’s services are unavailable:
  • Users can export their Para Share at any time via
  • With both shares, users can sign transactions independently without Para’s servers
  • The provides a censorship-resistant fallback for full self-sovereignty
This design ensures that Para cannot censor transactions and that users are never locked out of their own assets.

Backup and Recovery

Device loss, theft, and hardware failure are inevitable. Para’s recovery system ensures users can always regain access to their wallet without the need for application-level recovery flow build-outs. All recovery flows are handled through the Para Portal, a managed web experience that walks users through verification and key restoration.
MechanismHow it works
Recovery secretA unique secret generated during wallet setup, stored by the user. Not related to the MPC key shares. Used solely to restore wallet access. Para never has access to it
Para Backup KitA copy of the Para Share given to the user at setup, providing censorship resistance and protection against downtime
Backup devicesUsers can register secondary devices (laptop, smartwatch) during setup. If the primary device is lost, they log in from a backup and add new devices
Key rotationAfter any recovery event, Para prompts a full key rotation, generating entirely new key shares and invalidating the old ones
Multi-factor verificationRecovery requires the recovery secret plus optional 2FA (TOTP), protecting against impersonation

Security Measures

MeasureHow it protects users
Multi-factor verificationRecovery requires the recovery secret plus optional 2FA (TOTP). No single factor alone can restore wallet access, protecting against social engineering and impersonation
Key rotationAfter every recovery event, Para prompts a full key rotation, generating entirely new key shares and invalidating the old ones. Even if old keys were compromised, they become useless
Backup devicesUsers can register multiple backup devices (laptop, smartwatch, tablet) during setup. If the primary device is lost, they log in from a backup device without needing to go through the full recovery flow
48-hour recovery delayRecovery attempts initiated via the Para Portal include a waiting period, giving users time to detect and cancel unauthorized recovery attempts
Para Portal managed flowAll recovery is handled through the Para Portal, removing the need to build or manage recovery UI. This reduces implementation surface area and ensures consistent security across all integrating apps

Best Practices for Users

Secure Storage

Store the recovery secret in a secure, offline location. Never share this secret with anyone, including Para.

Enable 2FA

Activate two-factor authentication for an additional layer of security during the recovery process.

Multiple Backup Devices

Add multiple backup devices when possible to increase recovery options.

Regular Verification

Periodically verify the ability to access the account from backup devices to ensure they remain functional.

Audits and Compliance

Para is SOC 2 Type II compliant and regularly undergoes system-wide audits and penetration tests covering MPC implementation, infrastructure, API security, and recovery flows.

Audits & Compliance

Custody classification, regulatory posture, audit history, data handling, encryption details, and risk model, for CISOs and compliance teams.

Security FAQs

Para uses sessions as a security measure when signing transactions. By default, session length is 90 minutes. Developers can implement session refresh logic in their applications to maintain longer sessions if required.
As long as the Cloud Share sent during onboarding is not deleted by the user, they can always refresh keys, export, or sign transactions independently. This design ensures that Para cannot censor transactions. See our blog post on censorship resistance for more details.
Para supports sign-in via Google, Apple, Twitter/X, Discord, and Facebook. This allows developers to offer a range of authentication options to their users, increasing adoption and ease of use.
Para implements a robust recovery mechanism involving a recovery secret generated during wallet setup, optional backup devices, two-factor authentication, and a key rotation process after recovery. The recovery process is managed through the Para Portal, reducing the implementation burden on individual developers.
Yes. While most users don’t need to export their private keys given Para wallets are universal and usable across apps and chains, users are able to do so in Para Connect.

Permissions

How Para enforces fine-grained access control

Universal Wallets

One wallet across your entire ecosystem