Limit guessing and protect the whole protocol

HOTP alone provides neither confidential transport nor a complete authentication system.

• Protocol P MUST support two-factor authentication: something known, such as a PIN or password, and possession of the token. P SHOULD use a secure channel to protect privacy and avoid replay; HOTP is not a substitute for encryption (§§7–7.1). The picture is a boundary illustration, not a full login protocol.
• A throttling or lockout scheme is RECOMMENDED. T defines a maximum number of possible OTP validation attempts; keep it low while preserving usability. After the maximum authorized attempts, the server SHOULD lock out and inform the user. Delay or lockout schemes MUST apply across login sessions (§§7.2–7.3).
• Chosen example policy: T=3 total failures for this token. Failures in sessions A, B, A share one attempt budget. The third exhausted attempt is stopped before OTP acceptance; opening session C does not reset the budget. Three is an example, not an RFC-required constant; recovery and other factor checks are outside this model.
• The approximate guessing relationship is Sec ≈ s×v/10^Digit, with v verification attempts and s window size (§6). For Digit 6, s 3, v 3 the estimate is0.000009; with s 10 and v 3 it is0.000030. This is a model approximation under the RFC analysis, not an exact whole-system compromise probability or safety certification.
• Secrets require secure generation, storage and limited exposure. The secret store MUST be in a secure area; storage encryption and proven randomness products are RECOMMENDED (§7.5). A copied secret can generate future codes. The guide does not implement secure key storage, phishing resistance, rate-limited network authentication or account recovery. RFC 6238 is a later companion using time as a moving factor, not a formal update or obsoletion of RFC 4226.