Security overview
Last updated: 15 May 2026. We revise this page when architecture or user-facing security posture changes.
This page describes how SafeKey is designed. It is technical documentation for users and admins, not a legal warranty. Use it together with our Privacy Policy, Terms, coordinated disclosure policy, and support commitments.
Scope
SafeKey includes the web dashboard (Next.js application), the SafeKey API used for accounts and encrypted sync, the Android client when distributed, and optional packaged tools such as standalone .sfk containers. The same manufacturer security commitments apply across those components when they are offered together as the SafeKey product.
Vault encryption (synced items)
Vault JSON is encrypted on your devices before upload. The implementation uses PBKDF2-SHA512 key derivation from your vault PIN and AES-256-GCM for confidentiality and integrity of the vault payload. Our servers and operators receive and store ciphertext blobs and routine sync metadata only; they are not designed to decrypt your items, passwords, attachments, or seed material.
Authentication and account data
Account sign-in uses industry-standard transport (HTTPS) and server-side controls for passwords, JWT sessions, optional TOTP, and device registration for sync. Billing identifiers and payment flows are handled through Stripe; AlfaNest does not store full card numbers. Operational logs are minimised and must not contain vault plaintext by design.
Standalone container tools (web)
The SafeKey container panel in the web app runs Argon2id, hybrid post-quantum + classical key agreement, and AES-GCM entirely in your browser for supported workflows. The legacy server helper for those operations is disabled; cryptographic material is not submitted to SafeKey servers for v2 container operations. Always verify you are on the genuine SafeKey site before entering passphrases.
What we do not do
We do not recover lost PINs or lost local-only secrets. We cannot read your vault without your credentials. We do not promise uninterrupted availability and do not use this page to claim CRA conformity, CE marking, or penetration-test certification unless separately published with evidence.
Operational security
We apply dependency updates, access control, and hosting-hardening practices appropriate to risk. Third-party processors (for example Stripe, email delivery, hosting providers) sit under their own terms and, where applicable, data processing agreements.
Reporting issues
Use the coordinated vulnerability disclosure page and the contact and Canonical URL given in our security.txt file (published at /app/.well-known/security.txt on this site). Do not perform intrusive testing against production without written agreement except as permitted in the disclosure policy.
Android and other clients
Mobile clients follow the same ciphertext-only sync model when sync is used. Local storage and platform keychain behaviour are described in Play Data safety materials and in-app documentation as those builds are released. Keep devices patched and install only official distribution channels.