Hardware Bound

Hardware-bound vault

A copied vault file should not open on someone else's device. BlindLock is built around that rule.

File

The vault sits inside an ordinary-looking PNG file.

Password

Your password is required to open it.

Device

The vault is bound to your authorised device. On other hardware, it stays closed.

What hardware-bound means

BlindLock uses platform security hardware — TPM 2.0 on Windows and Linux, Secure Enclave on Apple devices and StrongBox on Android. A copied carrier is not enough: the master password and authorised device are also required.

Optional fourth factor

If you want, activate a physical security key — a modern FIDO2 key that supports sealing, for example a YubiKey 5, a current Google Titan key, or a SoloKey. The key cryptographically seals your login. If it is lost, recovery requires an encrypted BlindLock backup and the separately stored recovery phrase.

Limits

Hardware binding protects the vault at rest. It does not replace operating-system hygiene and does not stop a keylogger on a computer that is already compromised.

Why device binding changes the picture

A conventional local vault can often be copied and attacked offline with only the vault file and master password. BlindLock adds an independent device factor. Part of the unlocking key is derived inside your device's security chip and never leaves it in the clear. A copy of the carrier file therefore holds nothing but hardware-bound, encrypted content. Without that specific device, a piece of the key is missing, and the vault stays shut. Even if someone copies your PNG carrier from a backup or cloud-synchronised folder, the file alone is not enough: on unauthorised hardware the device factor does not match, and the master password cannot compensate for it. That adds an independent barrier instead of simply placing another password at the door.

The three-factor model

  • File. The carrier file, an unremarkable PNG, holds the encrypted vault. Without it there is nothing to open.
  • Password. Your password unlocks the content. BlindLock never transmits it to our servers.
  • Device. The device's security hardware contributes the missing factor through TPM 2.0, Secure Enclave or StrongBox, depending on the platform.

Optional fourth factor: security key

  • On the desktop you can activate a hardware security key — it cryptographically seals your login.
  • Supported are modern FIDO2 keys with sealing capability (hmac-secret), for example YubiKey 5, current Google Titan keys, and SoloKeys. Keys without this capability are rejected during activation.
  • With the key active, normal unlock requires the key to be connected and confirmed. Recovery instead requires the encrypted BlindLock backup and separately stored recovery phrase.
  • The key is an additional factor, not a replacement for device binding. The two work together.

Who it is for

  • People who keep high-value credentials or recovery material and have to assume that files will eventually end up in the wrong hands.
  • Users who deliberately keep their vault file in backups or across several drives, without any single copy becoming a liability.
  • Anyone who wants a password store with no central vault account, no automatic cloud sync and no provider-side customer-vault database.

Who it is not for

  • Teams that want a vault kept automatically in sync across many rotating devices. One licence activates exactly one device.
  • Anyone who regularly works on borrowed, unconfigured machines and expects instant full access there. Device binding deliberately prevents that.
  • Anyone expecting a tool that secures a system already infected with malware. No vault software can do that.

A concrete scenario

Picture an old backup drive falling into the wrong hands. Among hundreds of holiday photos sits the PNG file that holds your BlindLock vault. The finder does not even recognise it as a vault: it has no telling extension and no fixed BlindLock header or vault marker. Even if they identify it and know your password, their machine is missing the device factor from your security hardware. The content remains encrypted, and the copied file alone cannot be unlocked. On your authorised device, the carrier and password can open the vault as usual, provided that no optional security key has also been required.

What BlindLock does not claim here

Device binding is an extra, honest hurdle, not a magic lock. It protects the vault at rest and makes copied files insufficient on unauthorised hardware. It does not replace a well-maintained operating system, a strong device sign-in or careful storage of your recovery phrase. On a computer already taken over by malware, even the best vault can be compromised at the moment you unlock it. We do not promise absolute invulnerability. We add an independent barrier and remove the classic weak point where one file plus one password opens everywhere.

Frequently asked questions

What happens if my device breaks or is lost?

Restoration on a new device requires an encrypted BlindLock backup and the recovery phrase shown during setup. Keep them securely and separately; neither is sufficient on its own.

Can I open the same vault on two computers?

Not automatically on two desktops. The binding is per device, and one paid lifetime licence activates exactly one Windows, macOS or Linux device. Simultaneous use on a second desktop needs another licence and its own hardware binding; migration uses an encrypted BlindLock backup and the recovery phrase. iOS, iPadOS and Android are always free.

Do I have to use a security key?

No. The three-factor model of file, password and device stands on its own. The security key is an optional fourth factor for anyone who wants an extra physical confirmation.