# What is trust on first use (TOFU)?

> Trust on first use means accepting a key the first time you see it and checking it on every later contact. Why SSH works this way, and how to close the gap.

URL: https://crunu.com/learn/trust-on-first-use
Language: en
Updated: 2026-10-30

Trust on first use (TOFU) is a way of establishing trust in which a client accepts and remembers a public key the first time it connects to a peer, without proof that the key is genuine, and then refuses to continue on any later connection where the peer presents a different key.

## How it works

RFC 7435 defines it: TOFU "calls for accepting and storing a public key or credential associated with an asserted identity, without authenticating that assertion", after which communication authenticated with the cached key "is secure against an MiTM attack, if such an attack did not succeed during the vulnerable initial communication" ([RFC 7435](https://www.rfc-editor.org/rfc/rfc7435)). The same RFC notes that SSH, "in its commonly deployed form", uses TOFU, and that the phrase "leap of faith" is sometimes used for it.

You have seen it as the SSH prompt that shows a server's key fingerprint on first connection and asks whether to continue. Say yes, and the key goes into `known_hosts`. If the server's key later changes, SSH warns and refuses to connect.

## The gap and how to close it

TOFU moves all the risk into one moment. If someone sits between you and the peer on the first contact, you pin their key instead, and every later check protects the impostor. The fix is to compare the key through a channel the impostor doesn't control: read the [fingerprint](https://crunu.com/learn/public-key-fingerprint) over a call, check it against a value published elsewhere, or have a trusted party sign it.

The RFC names the second weakness too: TOFU protocols "require more care from the end user when systems update their cryptographic keys", and "TOFU can make it difficult to distinguish routine key management from a malicious attack."

## Common mistakes

- **Typing "yes" without comparing.** The first prompt is the only moment TOFU protects nothing.
- **Clearing a warning by deleting the old key.** A changed key deserves an explanation before it is accepted.
- **No plan for legitimate rotation.** Without one, people learn to ignore warnings.

## Where Crunu uses it, and where it doesn't

Crunu avoids blind first use where a server could swap keys:

- **New members.** After someone accepts an invitation, they read their key fingerprint, four groups of four characters, to an admin over a call or message. The admin ticks **Fingerprint matches: verified with this person** before the person gets any environment. That comparison is what stops a server from inserting its own key.
- **Machines.** `crunu enroll` prints the machine's fingerprint, and the admin approves after comparing it.
- **The organization's root of trust.** Your **organization key pin** is a record of the organization's signing key that you signed yourself and keep on your devices. A new device uses it to know which organization key to trust, instead of taking the server's word.

*Figure: Example: Jonas Lindqvist has just accepted an invitation to Kiteline, and his screen shows his key fingerprint, HTO5-H2HP-IIG5-UO5H. On a call, not through the server, Priya Natarajan compares it with the four groups on her screen, ticks “Fingerprint matches: verified with this person (Jonas Lindqvist)” and moves to “Confirm and grant access.” The server only delivered the invitation and the keys, and the matching MAC shows it couldn’t swap them.*

Pinning has the limit TOFU always has: protection starts from the first trusted state. Clients also remember the newest state they have seen and reject older ones, which is [rollback protection](https://crunu.com/learn/rollback-protection), but a device that has never seen the newer state can't detect a rollback. The full picture of who can decrypt, and how the server is kept out, is in [who can decrypt your secrets?](https://crunu.com/guides/who-can-decrypt-your-secrets).

## Sources

- [RFC 7435: Opportunistic Security](https://www.rfc-editor.org/rfc/rfc7435), checked October 30, 2026.