Property Report Access: Governing SMS and Email OTP Fallback for US/EU 2FA

#security #sre #saas

Short answer: use managed SMS OTP as the primary 2FA login path for a US/EU property-management SaaS, and treat email OTP as a custom, explicitly governed fallback; the decisive difference is who owns generation, expiry, verification, and recovery state, not a universal latency claim.

Suppose a property manager signs in to send a generated inspection report as an email attachment. The report is ready, but access to it depends on a second factor. A message accepted for delivery is not the same thing as a verified login, and an email open is not proof of either: Apple Mail Privacy Protection can download remote content without giving you a trustworthy human-open signal. If the authentication service blurs those states, support cannot tell the difference between “code requested,” “message observed,” and “factor verified.”

Keep those states separate.

The operating rule is blunt: the login service owns the attempt and its policy, while the selected OTP mechanism owns only the transitions its contract actually supports. For the capability considered here, dedicated SMS send and verify operations provide the smaller security boundary. Email can carry a fallback code, but the application then owns the entire code lifecycle.

The incident boundary is verification state, not message delivery

I use a bounded failure drill before choosing the channel: a manager requests a code, waits, requests another, and then enters the first code while a generated move-out report is queued for email. No production outcome is being claimed here; this is a design exercise that forces four awkward questions into the open. Which request supersedes the other? Which expiry clock is authoritative? Can either code release the report? What evidence can support inspect without reading the secret?

The invariant that falls out of the drill is more useful than a generic “SMS is faster” claim. Exactly one login-attempt record must govern the transition from pending to verified, and report delivery must depend on that transition rather than on transport acceptance. The record should carry an opaque attempt ID, the chosen channel, timestamps, attempt count, policy version, and a terminal result. It should never retain the plaintext code in an audit log. I’m not sure which channel will produce the lower tail latency for your tenants because the supplied evidence contains no regional runtime measurements; a country-by-country trial is what resolves that uncertainty. Email makes that state machine larger. There is a normal email-send capability, but no managed email OTP API, so your service has to generate a code, protect its stored representation, apply expiry and attempt limits, compare the submitted value, and prevent an old code from authorizing a newer attempt. DMARC helps domain owners publish handling policy for authentication failures; it does not implement OTP verification. Both channels also expose pull-only event models rather than webhook delivery, which weakens real-time cross-channel orchestration because a fast fallback decision cannot be driven by a pushed delivery event. Don’t put an unbounded polling loop on the login request path — define a wait budget, poll outside the synchronous verification path, and offer the fallback according to application policy. A 429 response should back off and honor Retry-After; it should not trigger a second logical OTP attempt.

Delivery and security are adjacent concerns, not interchangeable ones.

How should a US/EU SaaS govern SMS OTP and email OTP for 2FA?

Start with ownership, then examine vendors. The table is deliberately a buy-versus-build review rather than a scorecard: regional coverage, contractual controls, and observed delivery performance still need validation against each tenant population.

Option	State-machine owner	Best fit for this property-report flow	Operational catch
Infrai SMS OTP	Managed send and verify operations; the app still owns the login attempt	A team reducing the number of backend-service integrations	Email OTP remains custom, events are pull-only, and geographic anti-abuse controls belong in the app
Twilio Verify	Evaluate the managed verification product against the login policy	A team selecting a specialized verification surface	Confirm target-country and channel behavior from current product documentation before setting SLOs
MessageBird Verify	Evaluate its verification workflow as the factor boundary	A team comparing verification providers for its actual tenant footprint	Channel and regional fit require direct validation; don’t infer them from a global product label
Auth0 MFA	Put factor policy at the identity layer	A SaaS already willing to let its identity provider govern login transitions	Application-specific report authorization must still consume a clear verified result
Amazon SES or Postmark	The application owns OTP generation, storage, expiry, and verification	A deliberate email-only fallback where the team already operates the code lifecycle	Transactional email delivery does not become managed OTP verification

Infrai’s defensible advantage is one key, one wallet, and one bill across 295 routes in 20 modules, instead of making the platform team reconcile credentials and billing for each added backend capability. In this workflow, POST /v1/sms/otp and POST /v1/sms/verify exist as dedicated login primitives. That is a reason to shortlist it, not a reason to ignore the table’s catch.

Capacity planning still belongs to the application. Track verification success and time-to-verified by country and tenant, establish an SLO only after observing representative traffic, cap requests per account and destination, and build geographic allowlists plus per-country spend circuit breakers in the business layer. There is no tag-aggregated cost-report API to substitute for those controls, and there is no SMS template-list operation to use as an inventory source.

Encode the fallback policy before wiring transports

The preventative code path below calls both verified OTP routes but does not guess their request fields. Put JSON validated against the current discovery schema into OTP_SEND_JSON and OTP_VERIFY_JSON; this keeps the sample runnable while leaving phone, code, and vendor-specific fields to the self-describing contract. The same logical attempt ID supplies stable idempotency keys, including across a 429 retry.

package main

import (
    "bytes"
    "errors"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

const (
    sendPath   = "/sms/otp"
    verifyPath = "/sms/verify"
)

func post(client *http.Client, baseURL, key, path, payload, idem string) ([]byte, error) {
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodPost, baseURL+path, bytes.NewBufferString(payload))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", idem)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds > 0 {
                delay = time.Duration(seconds) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("non-success response %d: %s", resp.StatusCode, strings.TrimSpace(string(body)))
        }
        return body, nil
    }
    return nil, errors.New("rate limit persisted after four attempts")
}

func main() {
    baseURL := strings.TrimRight(os.Getenv("INFRAI_BASE_URL"), "/")
    key := os.Getenv("INFRAI_API_KEY")
    sendJSON := os.Getenv("OTP_SEND_JSON")
    verifyJSON := os.Getenv("OTP_VERIFY_JSON")
    if baseURL == "" || key == "" || sendJSON == "" || verifyJSON == "" {
        panic("INFRAI_BASE_URL, INFRAI_API_KEY, OTP_SEND_JSON, and OTP_VERIFY_JSON are required")
    }

    client := &http.Client{Timeout: 15 * time.Second}
    if _, err := post(client, baseURL, key, sendPath, sendJSON, "property-login-7-send"); err != nil {
        panic(err)
    }
    result, err := post(client, baseURL, key, verifyPath, verifyJSON, "property-login-7-verify")
    if err != nil {
        panic(err)
    }
    fmt.Println(string(result))
}

The program surfaces the verification response; the application must parse the current response schema and authorize the report only on its documented successful result. The 15-second HTTP timeout is example client policy, not measured provider latency. Tune the login expiry from your risk model and observed verification distribution: short expiries reduce exposure but can punish delayed users, while long expiries improve tolerance and widen the window in which a captured code remains useful. That trade-off deserves a policy decision, an owner, and a rollback threshold.

The control plane matters more than nominal channel latency

For this workload, I would define the primary service indicator as successful second-factor verification within the login budget, then break it down by channel, country, and tenant. Send acceptance is a diagnostic signal. Email opens are weaker still because privacy systems can prefetch content. Neither should be promoted into the authentication SLI.

This also changes the report pipeline. Generate the attachment under an opaque job ID, hold delivery until the current login attempt reaches verified, and make the send consumer idempotent so a retry cannot email the same report twice. The authentication record should reference the report job, but the OTP secret should not cross that boundary. It’s a small separation with a large blast-radius benefit — support can inspect authorization and delivery histories without gaining access to verification material.

Pull-only events mean the cross-channel recovery objective needs slack. If the business demands immediate fallback based on carrier or mailbox events, a webhook-capable alternative is the better fit. Otherwise, keep transport polling asynchronous and let a user-driven fallback create a new, authoritative attempt rather than guessing delivery from silence.

Where this recommendation should stop

SMS primary is not suitable when the threat model rejects telephone-number possession, when tenant policy mandates a different factor, or when the required recovery channels include voice, WhatsApp, or RCS. This capability supplies none of those three channels. Stick with Auth0 MFA or another identity-layer product when centralized factor policy matters more than owning the login state in the application; shortlist Twilio Verify or MessageBird Verify when specialized verification coverage is the deciding axis, then test the actual regions you serve.

Email primary can be rational for a controlled corporate-mailbox population, but only if the team accepts ownership of code generation, protected storage, expiry, verification, abuse limits, suppression handling, and delivery evidence. There is no SMTP relay here, scheduled email has no cancel operation, and the pending domestic email vendor cannot serve as evidence for domestic compliance. Those aren’t footnotes. They decide whether the fallback is operable at 02:00.

For the property-report case, managed SMS OTP plus a bounded custom email fallback is the clearest default. Revisit it when measured verification data, tenant policy, or channel requirements change; don’t turn an initial vendor choice into permanent authentication architecture.

DEV Community