A sign-in email often contains a capability: a link or code that changes account state. Threat modeling that flow starts by following the capability rather than treating the message as ordinary text.
Draw the path
List the application, sending provider, receiving mailbox, browser displaying the message and destination opened by the link. Add operational logs, support screenshots and forwarded copies. Each additional copy may extend the life or audience of the secret.
Ask a question at each boundary
- Application to sender: Is the message associated with the intended action and recipient?
- Receiver to reader: What proves that this browser or account may view the inbox?
- HTML to browser: Can remote content, scripts or navigation create an unexpected request?
- Link to application: Is the token limited to its intended purpose, account and lifetime?
- Operations to support: Are tokens removed from routine logs and screenshots?
Prioritize practical failure cases
For your own application, test a reused token, a token opened after expiry, an address changed midway through verification and a message viewed from an unauthorized session. Use synthetic accounts, not customer inboxes.
Choose the mailbox accordingly
An inbox that is convenient for a public download may be unsuitable for account recovery. Review the actual access and retention model. A random-looking address is not, by itself, evidence of exclusive access. Keep long-lived or sensitive identities on a mailbox you can control and recover.