Definition
OTP (One-Time Password) is a verification code that can only be used once and usually has a validity period (e.g., 5 minutes), used for identity verification, login confirmation, payment confirmation, and other scenarios. OTP is sent via SMS Gateway using A2P SMS, or via email or an Authenticator app, and used in conjunction with 2FA two-factor authentication, significantly enhancing account and transaction security.
Use Cases
Typical applications of OTP in ICMP: Login verification——2FA Two-factor authentication, where the user must enter the OTP after entering the password; Sensitive operations——API Key creation, permission changes, large payments, etc., require OTP confirmation; Password reset——send OTP after verifying the user's identity to complete the reset; Device binding——OTP verification when a new device logs in for the first time. When OTP is sent via SMS Gateway, it is considered A2P messaging, and compliance and delivery rates must be ensured.
Technical Implementation
Common implementations of OTP: TOTP (Time-based OTP)——generated based on time and a key, such as Google Authenticator; HOTP (HMAC-based OTP)——based on a counter; SMS OTP——send a random code via SMS Gateway. SMS OTP depends on the network and the messaging channel, may be delayed or intercepted; TOTP does not require a network but requires the user to bind an Authenticator in advance. Platforms can support multiple methods simultaneously to meet different customer preferences.
Practice in ICMP
SimtoLink ICMP supports OTP verification: IAM login, sensitive operations can configure 2FA; send SMS OTP via SMS Gateway; support TOTP Authenticator binding; Audit Trail records OTP verification events to meet PCI DSS, GDPR and other compliance requirements.
Channel and Expiry of a Short-Lived Code
A one-time password is a check value that can succeed only once and that expires quickly. A time-based code is computed from a shared secret and the current time window. The platform does not have to send that code. An SMS or email code is generated by the platform, carried to the user, and typed back. In either case, the value or the time window should be invalidated after a successful check. What it proves is that the person who holds this channel or this secret completed one confirmation. It does not prove the long-term identity of a device, a SIM, or a company.
Before use, choose the scenario and the parameters. Sign-in, password reset, list export, and payment confirmation have different risk, and they should not share one lifetime or one rule for resending. An SMS code depends on the number still being under the person’s control, and a cross-border number also needs a channel that can deliver. A time-based code depends on the user having bound the secret in advance. When clock skew is large, state how many windows are allowed. The check should happen as part of authorization or of establishing the session, not as a comparison on the page after which the browser is trusted. A service program that calls a management API should not run for a long time on an SMS code a person forwarded. That turns one confirmation into a permanent credential. Record both success and failure as API access records that do not contain the code in clear text, so it is possible to trace which operation was confirmed.
Treating a Verification Code as Device Identity
A common error is to replace SIM or device authentication with an SMS code. An IoT module has no person to type six digits. Designing a one-time password as a condition for the device to join the network cannot be carried out on site, and it tempts implementers to write the code into firmware. Another error is a code that can be reused, or a failure count with no ceiling. An attacker can keep trying during the lifetime, or use one intercepted SMS in several places.
Writing the full code into a log, a ticket, or a support chat hands the second factor to everyone who can read the log. If resend is too frequent, the user receives several codes and does not know which one is still valid. The sound practice is that a new code invalidates the old one immediately, the check accepts only the latest code, and what is recorded is “passed or rejected,” not the code itself. A one-time password covers only this human confirmation. SIM subscription and device attach still use their own identity mechanisms.
Within the lifetime, one account keeps only the latest code that was sent. When the new code takes effect, the old one is invalidated at once. After consecutive failures reach the agreed count, pause the check and require a different channel or a cooldown, rather than unlimited retries. Support can trigger a resend. Support cannot view the code. A time-based code should also record when the bound device was disabled. After the user changes phones, the old binding should no longer pass the check.
A time-based code needs an agreed allowance for clock skew. Too wide a window lets the same code be reused for a long time. Too narrow a window fails when the phone clock is slightly off. Remember values already used inside the window, so they cannot be replayed in the time that remains. An SMS code does not depend on the phone clock, but it does depend on the number still being in the person’s hands. When the number changes, confirm first with the existing factor or another method already bound, then change the destination. Do not share one failure counter that never resets between the two kinds of code, or yesterday’s mistyped attempts will lock the user out today.
Limit the send rate by account and by destination number together. Limiting only the account lets an attacker change accounts and flood one number with codes. Limiting only the number lets one person keep trying their own account from other numbers. When the limit fires, the screen should say only to retry later. It should not say whether the account or the number was limited, so the response is not a clue to whether an account exists. The log records the limit action. It does not record the code.
A one-time password cannot recover a long-lived session that has been stolen. It is valid only for the confirmation the user submits that once. The session issued after confirmation still needs its own expiry and revocation. When a user reports that someone else has seen the code, invalidate codes not yet used, and revoke sessions already established with that code. Sending a new code alone leaves operations inside the old session still running.