Most authenticator apps force a flat security model.
Every token lives behind the same unlock flow.
Every account gets treated as if it has the same value.
And if you want stronger protection, the answer is often to make everything more cumbersome.
We thought that was the wrong tradeoff.
We’re a small team building LocalAuth, an open-source iPhone authenticator, and I’m the primary developer behind it. The project started as a small internal experiment, but it kept growing because we wanted to explore a different question:
What if a TOTP authenticator used multiple trust boundaries instead of one?
That led us to a 3-channel model:
- Face ID / Secure Enclave for everyday accounts
- a dedicated YubiKey channel for higher-value accounts
- a generic FIDO hmac-secret channel for compatible security keys
From there, other design choices followed naturally:
- local-first storage by default
- nearby encrypted transfer for migration
- no mandatory account layer for core use
- an optional self-hostable Travel Vault for temporary off-device backup / restore
- end-to-end encryption for Travel Vault, with encryption happening locally before upload
This post isn’t really about “shipping a new app.”
It’s about a design choice we rarely see in authenticator tools: not every account deserves the same protection model.
If you’ve worked on security tools, hardware-key flows, or local-first apps, I’d love to hear whether this approach feels practical or overengineered.
Top comments (0)