Security & data residency
GDPR by design. Self-custody first. No fine print.
Paperkey is built around the assumption that your license data is yours. You can export it any time, and the GDPR is how we operate by default. This page lists what is true today, no more.
- Built in Paris
- GDPR-compliant
- No third-party tracker
- Self-custody export
- MIT-licensed SDK
Data residency
Where your data lives.
License records, activations, and customer data sit on encrypted infrastructure operated entirely within the EU. Backups use separate keys. Nothing crosses the EU border.
- Storage and runtime stay inside the EU. There is no failover region outside.
- Backups are encrypted daily with keys held separately from the working data, with point-in-time recovery up to 7 days back.
- Because no data crosses the EU border, no Standard Contractual Clauses are required for international transfer.
- Audit logs share the same EU storage. We keep 90 days of write-path activity, and security-relevant events (auth, billing, key rotation) for the lifetime of the account.
GDPR
A real privacy posture.
The GDPR is how we operate, not a feature we charge for. Every right of a data subject is wired directly into the dashboard and the API.
- Right of access: you can export the full data set tied to your account (licenses, activations, audit log) from the dashboard at any time, in JSON or CSV.
- Right to erasure: account deletion is self-service. It cascades to every record you own (products, licenses, activations, webhooks, agent telemetry, billing references). Nothing is hidden behind a soft-delete flag.
- Right to portability: the same export endpoint, structured and machine-readable.
- Lawful basis: contractual necessity for license data, legitimate interest for security audit logs, explicit opt-in for agent telemetry.
- No tracking pixels and no third-party advertising tags on this site. Analytics are self-hosted with anonymised IPs.
Sub-processors
Every third party that sees your data.
We keep this list short on purpose. Today, the only third party that touches data tied to your account is the billing provider, and only when you have a paid subscription. Any new sub-processor will be announced here at least 30 days before it goes live.
Encryption & secrets
Encrypted defaults you can verify.
Strong defaults: TLS 1.3 externally, AES-256 at rest, and application secrets that are hashed instead of stored.
- In transit: TLS 1.3 everywhere external, HSTS preload-eligible, no HTTP fallback in production.
- At rest: AES-256 storage encryption, with backups encrypted under separate keys.
- API keys and webhook secrets are shown once at creation. After that, only one-way hashes live in the database. We cannot recover them, you rotate them.
- Passwords are hashed with an industry-standard adaptive algorithm. A timing-decoy ensures unknown emails still pay the same cost as real ones, so response time cannot enumerate accounts.
- Session tokens are short-lived, signed server-side, and invalidated on every "sign out everywhere".
Access control
Least privilege, audit by default.
Operational access is narrow, and every administrative action that touches customer data is logged, time-stamped, and reviewable.
- Two-factor authentication (TOTP) is available for every customer account, and required for any account with billing access.
- Production changes ship through an automated CI/CD pipeline. Every change is a pull request, gated by mandatory tests, secret scanning, and dependency audits before it can merge. No code reaches production by hand.
- Strict ownership checks run on every authenticated route, enforced by integration tests on every change. IDOR-class bugs fail at build time, not in production.
- Per-IP and per-license rate limiters protect auth and the public validate/activate endpoints. Auth has a stricter limit than the global cap, and exact thresholds rotate.
- Every state-changing administrative action (auth, billing, key rotation, license issuance, license revocation) is recorded in an append-only audit log.
Incident handling
If something happens, you hear it from us first.
We commit to direct notification of affected customers within 72 hours of confirmed breach detection, in line with the GDPR.
- Detection: continuous error monitoring on every API path, external uptime probes, and per-route latency tracking. Status page at status.paperkey.dev.
- Notification: a 72-hour window for confirmed breaches that affect customer data, by email to the account contact. The CNIL is notified in parallel when the threshold is met.
- Disclosure: a public post-mortem is published on paperkey.dev for any incident causing more than 5 minutes of customer impact. It includes the timeline, root cause, fix, and follow-up actions.
- Reporting a vulnerability: write to security@paperkey.dev. We respond within 2 business days. Coordinated disclosure window is 90 days, extended for severe issues.
Threat model
What this protects against, and what it does not.
A clinical look at what license-server-side validation can and cannot defend against. We tell you the boundary so you can layer the right complement on top.
- What we protect against, server-side: license sharing beyond the activation cap (machine fingerprint diversity is enforced), revoked-license reuse (revocation propagates server-side and the SDK refuses cached negatives), expired-license reuse (validation is authoritative for status), abusive activation churn (per-license rate limits + dashboard alerts on near-cap or multi-region patterns).
- What we surface, not enforce: license sharing on a single fingerprint, anomalous IP geography, suspiciously fast re-activation cycles. The dashboard exposes these signals; you decide whether to revoke, reissue, or contact the customer.
- What stays your responsibility, client-side: signing your binary, verifying integrity of the SDK call site, not hardcoding the public key in a way that lets it be lifted from a memory dump. Server-side validation cannot defend against a binary that has been modified to skip the validate() call.
- What we do not claim to do: prevent reverse engineering, obfuscate your code, defeat memory tampering, or stop a determined attacker who controls the runtime. License validation is an integrity check on the commercial relationship, not a DRM. If your threat model requires anti-tamper, pair Paperkey with a code-signing strategy and a binary protector.
- How sharing detection works in practice: every activation is bound to a hashed machine fingerprint (machine ID + MAC + CPU class), capped per license. Re-activating the same fingerprint is idempotent; activating a new fingerprint consumes a slot or 403s if at the cap. The dashboard flags fingerprint reuse, multi-IP patterns, and near-cap activity over a configurable window.
Honest list
What we do not claim.
A licensing provider that overstates its compliance posture is a liability.
- No SOC 2 Type I or Type II. We are not at the scale where the audit is meaningful, and a fake badge would not help. Type I will be pursued when a paying enterprise customer makes it a condition of signature.
- No ISO 27001. Same reasoning. It is on the roadmap, not on the homepage.
- No PCI scope. We do not process payment cards. Stripe handles that for billing, and your customers buy your software via your own checkout (Stripe, Lemon Squeezy, Paddle, Gumroad, etc.). Paperkey only issues and validates the license.
- No formal SLA yet. One will be published before general availability, alongside a public incident history. The 99.9% target on /reliability is an internal goal, not a contractual commitment.
- No "trusted by 50+ startups" badge until 50+ startups actually ship with us.
A security question?
Email a real person. We answer in business hours, often faster.
Still evaluating?
Read the 5-minute quickstart. Or skip it: the SDK has decent defaults and the dashboard explains itself.