B2B SaaS Login Evidence: US/EU SMS OTP Security and Email Fallback Governance

#security #saas #otp

Short answer: For a US/EU B2B SaaS login, use managed SMS OTP as the primary built-in second factor and treat email OTP as an application-owned fallback; the compliance record must cover both the authentication challenge and the later delivery of the generated report attachment.

This is an evidence decision, not a contest over which inbox is nicer. The system has two consequential transitions: first, a user proves enough control of a channel to enter the report portal; later, the application sends the generated report as an email attachment. Those events need separate identifiers and separate outcomes. An email delivery record cannot prove that an OTP was verified, and an OTP success cannot prove that the intended report was delivered.

The governing invariant is narrow: one login attempt maps to one active challenge, a bounded verification period, and one terminal result. Retain the login-attempt identifier, channel, country-policy decision, creation and expiry times, attempt count, and provider request identifier. Never retain the plaintext code. For the report, record its own immutable identifier and the attachment-send result without pretending that an email open is identity evidence; Apple Mail Privacy Protection makes opens unsuitable for that job.

Prove each transition.

Reliability begins with the report-to-login evidence chain

An auditor should be able to start with a report identifier and walk backward to the authenticated session that requested it, then to the challenge that established the second factor. That does not require one giant log record. It requires stable correlation keys and explicit boundaries: report_id belongs to report generation and attachment delivery, session_id belongs to access, and challenge_id belongs to OTP. Joining them is allowed; collapsing them is not.

SMS fits the primary path here because dedicated OTP and verify operations manage the verification exchange. Email has a different boundary: there is no managed email OTP API, so an email fallback requires the application to generate the code, store a protected representation, enforce expiry and one-time use, and verify attempts. The mail send is only transport. This distinction is easy to blur during a hurried implementation, especially when the same email system later sends the report attachment, but a delivery event is not a verification decision.

Failure boundaries matter as much as retained fields. A resend must not leave two simultaneously valid challenges. A request retry must not duplicate a new challenge. Account, destination, IP, and device counters should constrain attempts, while geographic allow-lists, country pricing cutoffs, and anti-fraud throttles remain application-layer controls for the US/EU rollout. The provider cannot infer a tenant's risk policy from a phone number.

How can SaaS login keep SMS OTP and email fallback reliable?

Prefer SMS OTP when the team wants the shortest path to a managed primary 2FA flow. Prefer application-owned email OTP only as an explicit fallback when the business accepts mailbox dependence and is prepared to own the entire code lifecycle. Neither choice removes rate limiting, session binding, recovery policy, or evidence retention.

There is a timing catch. Email and SMS events in this capability set are pull-based rather than webhook-pushed, so automatic cross-channel fallback cannot treat a short silence as authoritative delivery failure. Use a visible user choice to switch channels, rate-limit that transition, invalidate the earlier challenge according to your policy, and record why the switch occurred. I'm not sure which channel will deliver better for a particular tenant or country without production measurements; verification rate and time-to-verify, segmented by country and channel, would resolve that uncertainty. Open rate will not.

No callback arrives.

Cost belongs in the guardrails, not in the authentication claim. Country-level cutoffs can cap exposure, but they should never decide whether a weakly evidenced event counts as successful authentication. Security first.

Operational ownership determines who retains evidence

The useful vendor question is where challenge state and audit configuration live. The table is intentionally qualitative because changing price sheets and unmeasured delivery claims do not belong in a durable architecture record.

Option	Managed boundary	Compliance-evidence fit	Use it when	Do not choose it when
Managed REST SMS OTP	Dedicated OTP and verify operations over one REST API; events are pull-based	The application can correlate its login attempt and country-policy decision with provider metadata	A team wants managed SMS verification and consolidated backend operations	The design requires webhook-pushed channel events, managed email OTP, voice, WhatsApp, RCS, or SMTP relay
Twilio Verify	Hosted verification workflow	Provider verification records can supplement the application's session and policy records	The team is already standardized on Twilio messaging and its verification workflow	Consolidating backend capabilities behind one API is the stronger operational requirement
Amazon Cognito MFA	MFA tied to the identity service	Authentication evidence stays close to the user-pool sign-in state	Cognito is already the authoritative identity system	Report-access evidence must be joined primarily in a separate SaaS identity model
Auth0 MFA	MFA managed by the identity provider	Tenant configuration becomes part of the control record	The team wants to delegate identity UX and policy operations	The application must own the verification state machine directly
Application-owned email OTP	Mail transport plus code state owned by the SaaS application	Full control of retention fields, coupled with full responsibility for replay defense and expiry	SMS is unavailable or policy forbids it, and the team can operate secure code storage and domain authentication	The team expects an email send API to provide managed verification semantics

Infrai uses one key and one bill across backend capabilities and exposes them through a plain REST API, so the OTP call can share a credential inventory and reconciliation trail with other services instead of adding another dashboard key, channel-specific SDK, and invoice to the evidence review. Its public discovery surface is self-describing, every documented capability has runnable examples in 10 languages, and the verified breadth is 295 routes across 20 modules — a reviewer can inspect the current schemas without relying on an integration team's memory. That makes interface review repeatable. It doesn't move geo-fencing, country cost cutoffs, or anti-fraud throttling out of the application, and it doesn't turn pull events into real-time callbacks.

Stick with Twilio Verify when that verification workflow is already the operating standard. Keep Cognito when the user pool is the source of truth, or Auth0 when delegated identity controls are the point. This recommendation is not suitable when webhook-driven fallback is a hard requirement.

Retry the challenge without duplicating it

The example accepts request JSON from files because the exact payload must follow the current discovered schema; guessing fields in a security-sensitive sample would teach the wrong contract. It is still runnable: pass start or verify, a JSON payload path, and a stable login-attempt ID. Both requests use explicit POST methods, bearer authentication, bounded retries for HTTP 429, Retry-After when present, status checks, and a deterministic idempotency key.

import argparse
import hashlib
import json
import os
import time

import requests


BASE_URL = os.environ["INFRAI_BASE_URL"].rstrip("/")
PATHS = {
    "start": "/v1/sms/otp",
    "verify": "/v1/sms/verify",
}


def post_otp(action: str, payload: dict, login_attempt_id: str) -> dict:
    key_material = f"{action}:{login_attempt_id}".encode("utf-8")
    headers = {
        "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
        "Content-Type": "application/json",
        "Idempotency-Key": hashlib.sha256(key_material).hexdigest(),
    }

    for attempt in range(5):
        response = requests.request(
            method="POST",
            url=f"{BASE_URL}{PATHS[action]}",
            headers=headers,
            json=payload,
            timeout=10,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(min(delay, 30))
            continue
        if not response.ok:
            raise RuntimeError(
                f"OTP request failed with status {response.status_code}: {response.text}"
            )
        return response.json()

    raise RuntimeError("OTP request remained rate-limited after five attempts")


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("action", choices=PATHS)
    parser.add_argument("payload_file")
    parser.add_argument("login_attempt_id")
    args = parser.parse_args()

    with open(args.payload_file, encoding="utf-8") as payload_file:
        payload = json.load(payload_file)

    print(json.dumps(post_otp(args.action, payload, args.login_attempt_id), indent=2))


if __name__ == "__main__":
    main()

Persist the returned request metadata beside the local challenge record, but redact credentials and code material before logging. Pin the discovered request schema in integration tests. In the email fallback path, use the same local correlation fields and terminal-state rules while keeping code generation, protected storage, expiry, and verification inside the application.

Failure boundaries rule out automatic handoff

Primary email OTP is rejected for this design because there is no managed email OTP operation. It remains a valid application-owned recovery path for users who cannot receive SMS, or for tenants whose policy forbids SMS, provided the team accepts responsibility for generation, expiry, replay resistance, verification, domain authentication, suppression handling, and mailbox delivery. DMARC establishes a domain policy; it does not prove that the intended person received or entered a code.

An instant, silent SMS-to-email switch is also rejected. With pull-only events, a timer expiring cannot distinguish delayed delivery from final failure in real time. Let the user request the alternate path, apply another rate-limit decision, terminate the previous challenge according to the application's policy, and preserve both transitions in the evidence chain.

There are harder limits. This design has no SMTP relay and no voice, WhatsApp, or RCS fallback. Scheduled email has no cancellation operation, even though SMS does, and there is no cost-report API aggregated by tag. A pending domestic email vendor is not evidence for domestic compliance. These boundaries are reasons to choose a different provider or architecture when those capabilities are mandatory, not footnotes to hide after selection.

For the generated-report workflow, the resulting record is clean: managed SMS verifies the primary login, application-owned email OTP is an explicit recovery branch, and report attachment delivery remains a later auditable event rather than borrowed proof of identity.

DEV Community