Passphrase-gated links

For a high-value link you can require a shared secret. You deliver the passphrase out of band, and the recipient enters it on the confirmation page before the link is consumed:

$link = $issuer->issueLink($user, passphrase: 'the-secret-you-shared');

The passphrase is stored only as a hash, through Hash::make(), so it uses whatever driver your application configured. It's verified before the token is spent, so a wrong passphrase never consumes a use of a multi-use link. Wrong and missing passphrases fail through the same generic, rate-limited response as any other bad link, so they leak nothing. A rejected passphrase isn't flashed back into the session either.

When a link carries a passphrase the confirmation page shows a passphrase field automatically. A custom confirmation screen can ask the store directly with TokenStore::requiresPassphrase($token) — see the contract reference.

This is a gate, not a second factor

This is a passphrase gate, not two-factor authentication. It is a lightweight shared-secret check, not a possession factor.

The real second factor remains the Fortify TOTP handoff. A passphrase-gated link for a two-factor user still hands off to the TOTP challenge after the passphrase is accepted: the passphrase is an additional gate in front of that flow, never a replacement for it or a way around it.