> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getpara.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Audits & Compliance
> Para's audit history, compliance posture, and regulatory classification for security and compliance teams
export const Link = ({href, label, newTab = false}) => {
const [isHovered, setIsHovered] = useState(false);
return setIsHovered(true)} onMouseLeave={() => setIsHovered(false)}>
{label}
;
};
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](mailto: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](/v2/concepts/permissions) 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](https://developer.getpara.com) |
| **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
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.
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.
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.
Yes. Para is SOC 2 Type II compliant.
Yes. Contact the Para team at **[security@getpara.com](mailto:security@getpara.com)** to request audit reports and details.
Full overview of Para's security architecture
MPC implementation, DKG, hardware secure enclaves