Audits & Compliance

This page is for CISOs, compliance officers, and security engineers evaluating Para’s security posture. It covers custody classification, regulatory implications, audit history, data handling, and the controls that underpin Para’s trust model.

Custody Classification

Para uses a 2-of-2 Multi-Party Computation (MPC) architecture where the private key is split between the user’s device and Para’s cloud hardware security modules (HSMs). The full key is never held by any single party (not Para, not the integrating application, not the user’s device alone).

Property	Details
Custody model	Self-custodial / non-custodial. The integrating application does not take custody of user funds
Key assembly	The full private key is never assembled at any point: not during generation, signing, or recovery
Regulatory posture	Non-custodial architecture simplifies regulatory requirements, enabling faster launches in new markets without the licensing overhead associated with custodial wallet models
Para’s role	Infrastructure provider. Para holds one key share in HSMs but cannot produce valid signatures without the user’s share

Regulatory Posture

Area	Status
SOC 2 Type II	Compliant
Penetration testing	Para regularly undergoes system-wide penetration tests
GDPR / data privacy	Para does not collect or store any personally identifying information unless used as a login method (e.g., email address or phone number)
Insurance	Self-Serve / BYO

To request compliance documentation or audit reports, contact the Para team at security@getpara.com.

Security Audits

Para is SOC 2 Type II compliant and regularly undergoes system-wide audits and penetration tests covering its cryptographic implementations, infrastructure, and API surface.

Audit Scope

Audits cover the following areas:

Area	What is reviewed
MPC implementation	DKLS19 algorithm correctness, distributed key generation, signing ceremony integrity
Cryptographic primitives	Key derivation, elliptic curve operations (secp256k1 / secp256r1), random number generation
Infrastructure	Cloud HSM configuration, network segmentation, access controls, secrets management
API security	Authentication flows, session management, rate limiting, input validation
Recovery flows	Recovery secret generation, key rotation process, multi-factor verification, 48-hour delay enforcement

Data Handling

Data type	How it’s handled
User Share (MPC key)	Stored on the user’s device only. Never transmitted unencrypted. Never accessible to Para or the integrating application
Para Share (MPC key)	Stored in Para’s cloud HSMs. Cannot produce a valid signature alone
Recovery secret	Generated client-side and shared with the user. Para does not have access to it
User identity (email)	Used for wallet association and recovery. Stored encrypted at rest
Session data	Short-lived (90-minute default). Used for signing authorization
Transaction data	Evaluated against permissions policy server-side. Not stored after signing

Encryption

Layer	Implementation
In transit	TLS for all network communications. End-to-end encryption for sensitive data between client and Para servers
At rest	All stored user data and key material is encrypted at rest
Key material	Para Share stored in cloud HSMs with hardware-level isolation. User Share protected by device secure enclave and passkey

Access Control and Permissions Enforcement

Para enforces a policy-based permissions system that provides an auditable control layer between applications and user wallets:

Every transaction is evaluated against an approved policy server-side before it reaches the MPC signing ceremony
Policies are immutable; changes require publishing a new version
DENY rules take precedence over ALLOW rules. Default posture is deny-all
Users explicitly consent to permission scopes during onboarding. No silent escalation
Each application gets its own policy per API key. Cross-app access is scoped independently

This creates a clear audit trail: what was requested, what policy was in effect, and whether the action was allowed or denied.

Non-Custodial Risk Model

For compliance teams evaluating what risks Para’s architecture eliminates vs. what remains in the integrating team’s scope:

Risk	Para handles	App handles
Private key storage	Keys are split via MPC. Para holds one share in HSMs, users hold the other on-device	N/A (neither party holds the full key)
Key compromise (single point)	Eliminated. Compromising one share reveals nothing useful	Ensure applications don’t introduce vulnerabilities that expose the user’s session
Phishing	Passkey-based auth is origin-bound and cannot be replayed on fake sites	Educate users on general phishing awareness
Unauthorized transactions	Server-side permissions enforcement blocks out-of-policy actions	Define appropriate permission policies for your use case
Device loss	Recovery via recovery secret, backup devices, and Para Portal	Encourage users to set up 2FA and backup devices
Censorship / platform risk	Users can export their Para Share and sign independently	N/A (users retain self-sovereignty)
Insider threat (Para)	Para cannot produce valid signatures with only its share	Monitor your own internal access to API keys and Developer Portal
Regulatory classification	Non-custodial architecture avoids wallet-layer MSB/MTL obligations	Consult your own legal team for your specific jurisdiction and use case

Compliance FAQs

Can Para access user funds?

No. Para holds one share of a 2-of-2 MPC key pair. A valid signature requires both shares; Para’s share alone cannot produce a signature or move funds. Para has no access to the user’s recovery secret.

What happens if Para is compromised?

An attacker who compromises Para’s infrastructure gains access to Para Shares stored in HSMs. However, these shares alone cannot produce valid signatures. The attacker would also need the user’s share (stored on-device, protected by passkey/biometrics) to sign any transaction.

What happens if Para goes offline?

Users who have exported their Para Share (via Para Connect or the Para Backup Kit) can sign transactions independently without Para’s servers. Users who have not exported can wait for service restoration; their funds remain safe and inaccessible to any party.

Does Para have SOC 2 certification?

Yes. Para is SOC 2 Type II compliant.

Can we get a copy of the most recent audit report?

Yes. Contact the Para team at security@getpara.com to request audit reports and details.

Security & Trust Model

Full overview of Para’s security architecture

Key Management

MPC implementation, DKG, hardware secure enclaves

Getting Started

Migrations

General Guides

How Para Works

Troubleshooting

Resources

Audits & Compliance

Custody Classification

Regulatory Posture

Security Audits

Audit Scope

Data Handling

Encryption

Access Control and Permissions Enforcement

Non-Custodial Risk Model

Compliance FAQs

Security & Trust Model

Key Management

​Custody Classification

​Regulatory Posture

​Security Audits

​Audit Scope

​Data Handling

​Encryption

​Access Control and Permissions Enforcement

​Non-Custodial Risk Model

​Compliance FAQs

Security & Trust Model

Key Management

Custody Classification

Regulatory Posture

Security Audits

Audit Scope

Data Handling

Encryption

Access Control and Permissions Enforcement

Non-Custodial Risk Model

Compliance FAQs