Frequently asked questions.

BlindLock keeps passwords, notes and 2FA secrets encrypted and concealed inside a PNG carrier on your device, protected by hardware binding and never transmitted to BlindLock servers.

Cloud managers store encrypted customer vaults centrally. BlindLock stores your password vault inside a PNG carrier on your device using steganography and operates no central customer-vault database. Concealment, encryption and hardware binding remove a major central attack surface.

See the full side-by-side comparison.

Encryption addresses whether an attacker can read the data; steganography addresses whether it is recognisable as a vault. Concealment adds another layer but never replaces encryption or hardware binding.

Passwords, notes and TOTP secrets live fully encrypted inside the PNG carrier. Larger documents and media use separate disguised, encrypted file-vault containers.

BlindLock never transmits vault contents to our servers and operates no central customer-vault database. Activation and each unlock use licence and version checks Vault contents leave your device only through an action you choose.

The cryptographic layer uses standard, peer-reviewed building blocks. Login-stego vault payloads use dual AEAD: AES-256-GCM under XChaCha20-Poly1305 (192-bit nonce), each with an independent key. Larger file-vault containers use authenticated encryption as documented on the Security page. Key derivation runs through Argon2id, a memory-hard function: the PIN passes through 256 MiB of memory and acts as an app entry gate for BlindLock's hardware-sealed app anchor — not the chip's native auth policy and not the vault key. The vault key itself is derived over 512 MiB to 4 GB depending on the device — every single password guess forces a full memory-hard pass. The ~10 seconds a check takes is not the protection; the protection is the memory-hard work per guess.

The stack includes the post-quantum components ML-KEM-1024 (FIPS 203) for key encapsulation and ML-DSA-87 (FIPS 204) for signatures, both at NIST security level 5; where each component is deployed is documented on the Security page. The encryption and post-quantum building blocks (AES-256-GCM, XChaCha20-Poly1305, ML-KEM-1024, ML-DSA-87) come from libcrux, whose core algorithms are checked with formal methods (hax/F*); BlindLock's own vault, steganography and licence code builds on top of them but is not itself part of that formal verification. Hardware binding uses TPM 2.0, Secure Enclave or StrongBox, depending on the platform.

The steganographic layer is added on top — it does not replace any of that. Even if an attacker detected and extracted the payload, they would face a fully encrypted, hardware-bound ciphertext.

Standard public-key cryptography will eventually be breakable by a sufficiently large quantum computer, and attackers are already harvesting encrypted data today to decrypt it later. BlindLock's answer is architectural: there is no central vault database to harvest, and your resting vault file is protected by 256-bit symmetric authenticated encryption — a construction that remains in a work-factor class generally treated as impractical under known quantum attacks on symmetric crypto. The stack also includes the NIST post-quantum components ML-KEM-1024 (FIPS 203) and ML-DSA-87 (FIPS 204), security level 5; where each component is deployed is documented on the Security page.

A copied carrier alone is not enough on a new device. Before an emergency, create an encrypted BlindLock backup and keep its recovery phrase separately; both are required to restore on authorised replacement hardware. Without the required recovery material, BlindLock cannot recover the vault for you.

BlindLock cannot reset a forgotten PIN. If you still have a valid encrypted BlindLock backup and its separately stored recovery phrase, restore on authorised hardware. Without that backup material, the vault cannot be recovered for you.

BlindLock accepts modern FIDO2 security keys that support sealing (the FIDO2 "hmac-secret" extension) — for example YubiKey 5-series keys, current Google Titan keys, or SoloKeys.

The list is open: any key that ships this capability works, regardless of vendor.

Once activated, the key becomes an additional factor in the normal unlock path. If the key is lost, recovery requires the encrypted BlindLock backup and separately stored recovery phrase. Older keys without the required capability are rejected during activation.

No. When your FIDO2 security key (Titan, YubiKey, etc.) has a master PIN set on it, the prompt you see comes from the operating system's native security-key dialog — not from BlindLock. Your PIN goes straight from the keyboard into the key's chip. BlindLock never reads it, never stores it, never caches it, never logs it. It is structurally impossible for us to leak a PIN we do not hold.

This is also why there is no "BlindLock PIN" for the security key: FIDO2 authenticators support exactly one master PIN that you configure on the device itself (typically via the vendor's own tool). That same PIN secures every service using the key — Google, GitHub, BlindLock, anything else — and it never leaves the silicon.

BlindLock defends the vault at rest. It cannot defend a fully compromised operating system running under your active user session — keyloggers, screen capture, memory scraping. We implement hardening to raise that cost (anti-debug, screen-protection, clipboard scrubbing), but a fully compromised host is outside the threat model. For that you need OS hygiene, a hardware security key, and ideally a dedicated machine for high-value secrets.

Supported at launch: Windows 10+ (TPM 2.0), macOS 13.3+ (Apple Silicon or T2), Linux kernel 5.13+ (TPM 2.0), iOS and iPadOS 17+ (Secure Enclave), and Android 12+ (StrongBox). Full requirements are on the platforms page.

Yes. iOS, iPadOS and Android are always free, for everyone. The same local-first security model applies on mobile: Secure Enclave for iPhone and iPad, and StrongBox on supported Android devices. Paid Lifetime and later subscription pricing apply to desktop only — one active Windows, macOS or Linux device at a time per paid licence, and that licence moves with you to a new PC.

BlindLock does not operate automatic vault sync. You choose where to keep encrypted backups, including local media, external storage or a cloud-synchronised folder. Migration to a new authorised device uses an encrypted BlindLock backup and the separately stored recovery phrase; one paid licence covers one active desktop device. iOS and Android remain free.

One paid licence = one active desktop at a time (Windows, macOS or Linux). Replace your PC whenever you like — the licence moves with you through the built-in migration flow; it does not die with the old machine. iOS, iPadOS and Android are always free, for everyone, and do not consume that desktop seat.

BlindLock sells exactly 1,000 Lifetime licences in three phases: 150 at €59, 350 at €79 and 500 at €99. Each is a one-time licence with no expiry date or recurring subscription. Entitlement is verified online at unlock; security-critical releases may require a minimum version, while routine updates remain optional.

After the 1,000 lifetime licences, BlindLock is subscription-only: €4.99 per month or €39.99 per year — always the latest version including major versions, for as long as the subscription is active. Lifetime will not return. See the pricing page.

During the lifetime offer, only Lifetime licences are sold. Afterwards, BlindLock becomes subscription-only, with monthly or annual billing and the latest version while the subscription remains active. A Lifetime licence never creates a recurring invoice.

At checkout you must confirm immediate digital delivery and waive the right of withdrawal. After that confirmation there is no withdrawal. Full details on the Refunds page.

Login-stego vault payloads use AES-256-GCM under XChaCha20-Poly1305 (192-bit nonce) for dual AEAD with independent keys. File-vault containers use authenticated encryption as documented on the Security page. Argon2id for memory-hard key derivation (256 MiB for the PIN that gates BlindLock's hardware-sealed app anchor, 512 MiB to 4 GB depending on the device for the vault key — a check takes around 10 seconds, but the protection is the memory-hard work per guess). ML-KEM-1024 (FIPS 203, formerly CRYSTALS-Kyber) for post-quantum key encapsulation. ML-DSA-87 (FIPS 204, formerly CRYSTALS-Dilithium) for post-quantum signatures, both at NIST security level 5. The encryption and post-quantum building blocks come from libcrux, whose core algorithms are checked with formal methods (hax/F*); the vault, steganography and licence code built on top of them is not part of that verification.

Selected cryptographic building blocks come from open, publicly verifiable libraries (libcrux / HACL* lineage). The steganography engine, vault UI, licence layer and platform integrations built on top are proprietary.

Back up the active PNG carrier. The original, unmodified source image is not needed after the carrier has been created. For migration and emergencies, also create an encrypted BlindLock backup and keep its recovery phrase separately. For every file vault, back up the disguised container, its recovery file and the recovery factor. Storage may be local, external or in a cloud-synchronised folder you choose.

The threat model — one person, one active device and no central vault sync — is optimised for individual high-value secrets. Team capabilities may come later as a separate product.

Responsible disclosure: email security@blindlock.app. We respond within 72 hours. Please do not open public issues on anything that looks like a vulnerability.