Email OTP can remove password storage and recovery friction, but it transfers trust to the user’s mailbox and creates a short, guessable credential. The surrounding controls determine whether the flow is safe.
Model the flow as state
A request creates a challenge with an expiry and purpose. Verification consumes that challenge once. Registration, login, email change and deletion should not silently share the same challenge semantics.
Generate securely and store defensively
Use a cryptographically secure random source. Avoid retaining a reusable plaintext OTP; store a keyed or salted verifier and compare safely. Expire it quickly and make successful use terminal.
Rate limits need several dimensions
Limit both sends and verification attempts. Consider email, IP, challenge and broader risk signals. A resend must not provide a simple way to reset the attempt counter. Responses should avoid revealing whether an account exists.
Separate verification from session policy
After verification, issue a scoped, expiring session token. Validate signing configuration at startup, support revocation for sensitive workflows and keep administrator identity separate from consumer OTP access.
Log outcomes, not secrets
Telemetry can record challenge requested, provider accepted, verification succeeded or rate limit triggered. It should not record the OTP, authorization token or full email address. Delivery and application success are different events and should be measured separately.