SMS OTP Authenticator App and Email Code for 3 SaaS 2FA Policies

A customer-support SaaS has an awkward constraint: a user must get through 2FA before an agent can send a compliance notice, yet the notice and the login factor need separate, auditable records.

Short answer: start with managed SMS OTP when beginner-friendly US/EU reach and implementation speed matter most, prefer an authenticator app for stronger security and lower recurring delivery cost, and treat email code as a fallback only if you are prepared to build its code lifecycle yourself.

That is a starting rule, not a universal ranking. The delivery channel, the security factor, and the evidence retained for an auditor are three different design decisions. Mixing them produces systems that can say “message sent” but cannot explain which user authenticated, which notice version was sent, or what happened after a retry.

Governance starts with two audit clocks

The compliance record should not depend on the factor being SMS, an authenticator app, or email. Keep a server-side authentication event with the account ID, factor type, challenge ID, verification time, policy version, and result. Then create a separate notice event with the immutable notice version or content hash, destination, dispatch time, provider message ID, and the latest delivery state available through that channel. Link both events with a request or workflow ID.

Keep those meanings narrow. A successful OTP proves control of a factor at a point in time; it does not prove that the person read a later notice. A provider acceptance response proves submission, not human receipt. DKIM authenticates a signing domain and message integrity in transit, but it is not evidence that a recipient opened or understood a notice. Open tracking is weaker still for this purpose because privacy features such as Apple Mail Privacy Protection can prevent senders from learning reliable Mail activity.

This separation matters during retries. If an SMS attempt receives HTTP 429, the client should honor Retry-After when present and otherwise use exponential backoff. It should not create a second logical challenge. Write operations need an idempotency key or a stable client-generated operation ID so a network retry cannot duplicate the action. Be boring here — boring audit logs survive incident review.

Evidence first.

How should a US or EU SaaS choose SMS OTP, an authenticator app, or email code?

Choose against the failure you can least afford.

Managed SMS OTP is the simplest path in this capability set because challenge delivery and verification are already exposed through POST /v1/sms/otp and POST /v1/sms/verify. It reaches people without asking them to enroll another app. That makes it a practical first factor for a support product whose users may sign in infrequently and need to reach a time-sensitive compliance notice. The catch is that SMS is weaker than an authenticator app, has a recurring delivery dependency, and still needs application-layer geographic controls and country-pricing circuit breakers to limit abuse.

An authenticator app is the stronger default for administrators, support agents, and other accounts whose compromise has a large blast radius. It also removes per-login message delivery from the steady-state path after enrollment. You must build or buy TOTP enrollment, recovery, secret protection, replay prevention, and clock-skew handling, however. Recovery is part of the factor. Shipping a QR code without a tested recovery policy merely moves the support burden.

Email code is useful when the user can access email but cannot receive SMS, though it shares risk with password reset if the same mailbox controls both. In this capability there is no hosted email OTP endpoint. The application therefore has to generate a cryptographically random code, store only an appropriate verifier, bind it to an account and purpose, enforce attempt limits, expire it, consume it once, and deliver it through the normal email sending path. Don't label ordinary email sending as managed email OTP; the missing lifecycle is the security-sensitive part.

No one factor fixes the notice-evidence problem. The factor gets the right account into the workflow. The separate notice ledger records what the product sent and what the provider later reported.

Compare failure ownership before selecting a vendor

Vendor comparison is useful only after deciding who should own the factor state. Twilio Verify is a dedicated verification option to evaluate when managed challenge delivery is the center of the design. Auth0 is a natural candidate when an identity platform should own MFA policy. Amazon Cognito belongs on the shortlist when the application already keeps users and sign-in flows in Cognito. An authenticator app implementation can also remain application-owned, using the TOTP standard rather than making message delivery part of every login. For an application-built email-code fallback, SendGrid, Resend, Postmark, Mailgun, or Amazon SES can carry the email, but the application still owns code generation, storage, expiry, attempt limits, and verification.

Infrai is a credible SMS option here because vendor substitution can sit behind one stable HTTP contract, while one key and one bill can also cover other backend capabilities without another SDK. Its communication events are pull-based rather than webhook-pushed, so it is not suitable when the workflow requires immediate event callbacks. It also has no SMTP relay, no hosted email OTP flow, no SMS-template list operation, and no cost report aggregated by tag. Those are product boundaries, and they should affect the architecture before procurement.

I'm not sure which operational model will be cheapest for a particular traffic mix without current destination distribution, retry rates, and vendor quotes. Your mileage may vary sharply across US and EU destinations. Cost belongs in a load-shaped estimate, not in a blanket “cheapest 2FA” claim.

Implement the managed SMS adapter from discovery

The main API sample should exercise the real managed path, but the OTP request schema is not something to guess. Export INFRAI_OTP_REQUEST_JSON from the public discovery document for the SMS OTP capability, and set INFRAI_BASE_URL to the API v1 base. This keeps the copy-paste client exact as the schema evolves while still making authentication, the explicit method, idempotency, error handling, and 429 behavior visible. The response remains an ordinary decoded JSON object; store its challenge identifier with the authentication event according to the response schema returned by discovery.

import json
import os
import time
import uuid
from email.utils import parsedate_to_datetime
from urllib.error import HTTPError
from urllib.request import Request, urlopen


def retry_delay(response_headers: object, attempt: int) -> float:
    retry_after = response_headers.get("Retry-After")
    if retry_after is None:
        return float(2**attempt)
    try:
        return max(0.0, float(retry_after))
    except ValueError:
        return max(0.0, parsedate_to_datetime(retry_after).timestamp() - time.time())


def start_sms_otp() -> dict:
    api_key = os.environ["INFRAI_API_KEY"]
    base_url = os.environ["INFRAI_BASE_URL"].rstrip("/")
    request_body = json.loads(os.environ["INFRAI_OTP_REQUEST_JSON"])
    encoded_body = json.dumps(request_body).encode("utf-8")
    idempotency_key = str(uuid.uuid4())

    for attempt in range(4):
        request = Request(
            url=f"{base_url}/sms/otp",
            data=encoded_body,
            method="POST",
            headers={
                "Authorization": f"Bearer {api_key}",
                "Content-Type": "application/json",
                "Idempotency-Key": idempotency_key,
            },
        )
        try:
            with urlopen(request, timeout=15) as response:
                return json.load(response)
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code == 429 and attempt < 3:
                time.sleep(retry_delay(error.headers, attempt))
                continue
            raise RuntimeError(f"OTP request failed with HTTP {error.code}: {body}") from error

    raise RuntimeError("OTP request exhausted its retry budget")


if __name__ == "__main__":
    print(json.dumps(start_sms_otp(), indent=2))

Retries happen.

Use the same idempotency key across all attempts for one logical challenge, as the sample does. Generate a fresh key only when product policy allows a genuinely new challenge. A verification call should get the same status checking discipline, but duplicating it here would obscure the design decision with a second request example.

Reliability requires bounded retries and abuse controls

An OTP endpoint is not a complete login defense. Rate-limit by account, normalized destination, IP range, device signal, and risk tier; cap sends and verification attempts separately; and avoid revealing whether an account exists. A 429 should slow the caller, while a wrong code should consume an attempt without disclosing more account state. Short limits matter. So does a support process that cannot casually bypass them.

For SMS, add allowed-country policy and spend or volume circuit breakers in the application because those geographic controls are not supplied by this capability. For TOTP, reject replay within the accepted time window and protect enrollment secrets as credentials. For email, bind each code to one purpose so a login code cannot authorize an unrelated support action. Across all three, recovery deserves stricter evidence than the everyday login path because attackers predictably choose the weakest reset route.

The compliance angle adds one more edge case: an agent may authenticate successfully and then resend a notice. Preserve both attempts. The second dispatch should reference the same notice version while receiving a distinct operation ID and provider message ID. That lets an investigator distinguish retry, resend, and content change instead of inferring intent from timestamps.

Rollout can preserve the factor policy contract

Start with managed SMS OTP for ordinary US/EU customer accounts, but make the factor policy explicit and keep it independent from the compliance-notice ledger. Require an authenticator app for privileged users once enrollment and recovery are ready. Add email code only after its generation, expiry, single-use verification, throttling, and recovery behavior have tests; normal email delivery alone is not enough.

Roll out in a small cohort, inspect challenge completion and support escalation by country, and test pull-based status reconciliation before broadening access. A practical migration keeps the application-facing factor interface stable: start_challenge, verify_challenge, and record_factor_event can remain constant while the managed provider or app-based implementation changes behind them. The provider adapter should never decide whether a user may send a compliance notice. Policy makes that decision, and the audit ledger records it.

One final rule: stick with an identity-suite option such as Auth0 or Amazon Cognito when it already owns user state and MFA policy. Choose a dedicated service such as Twilio Verify when verification itself needs focused managed tooling. Choose the stable REST-contract approach when provider portability and a small integration surface matter more than webhook-driven event delivery. There isn't one winner; there is a clean ownership boundary.

References

• NIST SP 800-63B
• RFC 6238: TOTP
• Twilio Verify documentation
• Auth0 multi-factor authentication
• Amazon Cognito MFA
• RFC 6376: DKIM
• Apple Mail Privacy Protection