OTP and 2FA glossary
These are the terms that come up when scoping, buying or building a one-time passcode flow. Each entry explains what the term means and why it changes a decision. Where the term maps to something documented on this site, there is a link to the detail.
- OTP (one-time passcode)
A short code that is valid once and only for a short period. It is generated for a specific challenge, delivered to a destination already recorded for the user, and then checked against what the user typed.
Why it matters. An OTP is evidence that someone controlled a phone number, messaging account or mailbox at that moment. It is not evidence of who the person is, so the surrounding policy decides how much the signal is worth.
- 2FA (two-factor authentication)
Authentication that requires two different kinds of evidence, most commonly something the user knows (a password) plus something the user has (a device, number or mailbox).
Why it matters. Adding an OTP to a password login is the most common way to reach two factors. Whether that is sufficient depends on the value of the action being protected.
- MFA (multi-factor authentication)
The general term for requiring more than one factor. 2FA is the two-factor case; MFA covers designs that may require additional or stronger factors depending on risk.
Why it matters. Procurement documents often say MFA when they mean OTP. Establishing which factors are actually required avoids buying a delivery layer when the requirement was a phishing-resistant authenticator.
- SMPP
Short Message Peer-to-Peer protocol, the long-standing telecom protocol messaging platforms use to submit SMS. Flow2FA accepts an SMPP v3.4 bind.
Why it matters. If authentication messages already leave through a gateway, CRM or messaging platform that speaks SMPP, that submit path can often be retained instead of rewritten. Validation and correlation on this path are agreed during implementation rather than assumed.
- IdP (identity provider)
The system that owns user accounts, credentials and sessions, and issues assertions or tokens that other applications trust.
Why it matters. Flow2FA is not an identity provider. Your IdP still decides who is being authenticated and whether a session is issued; the OTP layer only carries and checks a code.
- DLR / delivery receipt
A status report returned by a network or provider indicating what happened to a submitted message — accepted, delivered, rejected or unknown.
Why it matters. A delivery receipt describes a network event, not a user action. Treating receipts as a success metric hides the gap between messages reported delivered and verifications actually completed.
- Verification completion
The proportion of generated challenges where the user entered a valid code before it expired and your application recorded the outcome.
Why it matters. This is the commercial outcome you are paying for. It is the only figure that captures delivery, latency, message clarity and user experience together.
- otpId
The identifier the documented REST endpoint POST /otp/generate returns for a challenge. It is passed back to POST /otp/validate together with the code the user entered.
Why it matters. There is no caller-supplied request ID in the current public REST surface. Your application stores the otpId against its own session, transaction or recovery record — that stored link is what binds the challenge to the action.
- Provider / delivery profile
The value the REST generate request requires in its `provider` field. It is the account-configured provider or delivery-profile value issued during onboarding for that channel.
Why it matters. Documentation examples are illustrative only; use the values issued for your account. Whether a permitted value maps to one underlying vendor or to an account-specific managed routing arrangement is confirmed during setup, and credentials stay server-side.
- Route
The specific path a message takes to reach a destination network — a particular provider, connection or interconnect for a given country and channel.
Why it matters. Route quality varies by market and changes over time. A provider comparison that ignores which routes serve your top countries is not comparing the thing that determines your results.
- Sender ID
The name or number a recipient sees as the origin of an SMS. Depending on the market this may be alphanumeric, a short code or a long number, and it often requires registration.
Why it matters. Registration requirements and lead times differ by country and can gate a launch entirely. Confirm who owns the registrations in your provider model before committing to dates.
- Fallback
Attempting an alternative channel or route after a first attempt fails or is not confirmed within a defined window.
Why it matters. Fallback changes assurance as well as delivery. Moving a high-value approval from SMS to email should be an approved decision for that use case, not an unexamined default. Whether fallback applies at all is configuration-dependent.
- Resend
Issuing another code for the same flow, usually because the user believes the first one did not arrive.
Why it matters. Resend rate is an early warning of delivery or user-experience problems, and uncontrolled resends create several live codes, higher cost and an abuse surface. Throttles and invalidation rules are policy you define.
- Out-of-band authentication
Authentication that uses a separate communication path from the one being authenticated — for example a code sent to a phone while the user signs in through a browser.
Why it matters. NIST treats out-of-band authentication over the public telephone network, such as SMS or voice, as restricted, and recommends considering signals such as SIM change and number porting.
- Phishing-resistant authentication
Authentication that cannot be completed by relaying a secret to an attacker, because the authenticator is cryptographically bound to the origin it is used on.
Why it matters. Manually entered OTPs are not phishing-resistant: a code can be relayed in real time. Where phishing resistance is the requirement, an OTP delivery layer is not the product being asked for.
- Passkey
A phishing-resistant credential stored on a device or in a platform account, used in place of a password and typically unlocked with a biometric or device PIN.
Why it matters. Passkeys and OTP solve different problems. Many organisations run passkeys for high-risk access and keep OTP for recovery, onboarding or markets where passkey enrolment is not realistic.
- FIDO2
The set of open standards behind passkeys and security keys, combining WebAuthn in the browser with the CTAP protocol for external authenticators.
Why it matters. Security reviews often ask for a FIDO2 roadmap alongside OTP. Being explicit about which flows use which factor prevents an OTP layer being presented as something it is not.
- WebAuthn
The browser API that lets a website register and authenticate a FIDO2 credential such as a passkey or security key.
Why it matters. WebAuthn is an in-band, origin-bound flow. It has different failure modes from OTP, including device loss — which is often exactly where an OTP recovery path is still used.
- E.164
The international standard format for telephone numbers: a plus sign, country code and subscriber number, with no spaces or local trunk prefixes.
Why it matters. Numbers captured without a country code or with local prefixes fail silently and look like delivery problems. Normalising to E.164 before submission removes a large share of apparent failures.
- p50
The median value in a distribution: half of observations are faster and half slower. Usually quoted for request-to-delivery latency.
Why it matters. A healthy median can coexist with a bad experience for a meaningful minority of users, so p50 alone never answers whether codes arrive in time.
- p95
The value below which 95% of observations fall. The tail of the latency distribution rather than its centre.
Why it matters. Tail latency is what causes abandonment and expired codes. Ask for p95 by country and channel, not a single global average.
- KYC (know your customer)
Regulated identity proofing: establishing and verifying who a person actually is, typically using documents, data sources or biometrics.
Why it matters. Verifying a phone number or mailbox is not KYC. If the requirement is identity proofing, an OTP delivery layer does not satisfy it and a separate service is needed.
- 3-D Secure
A card-network authentication protocol used during online payments, in which the issuer decides how to challenge the cardholder.
Why it matters. 3-D Secure sits with the issuer and payment stack, not with your OTP provider. Your own step-up challenges are complementary to it, not a replacement for it.
- SIM swap
An attack in which a phone number is moved to an attacker-controlled SIM, usually by social-engineering the mobile operator or a retail channel.
Why it matters. A successful SIM swap makes SMS OTP an attacker-controlled channel. Where signals such as SIM change or recent porting are available, high-risk flows should take them into account.
- SMS pumping / artificial traffic
Abuse in which an attacker drives large volumes of OTP requests to numbers on expensive routes, generating revenue for the parties in that path.
Why it matters. The cost lands on you, and it usually enters through an unauthenticated signup or resend endpoint. Rate limits per user, destination, prefix and country are controls you own in the application.
For the full product model see the OTP API page, for field-level detail the API reference, and for evaluation criteria the OTP provider buyer guide.