Warehouse Login OTP by Email — 6 Signals When SMS Is Unavailable

The page says compliance_notice_ack_rate has fallen, but the first visible symptom is misleading: an email fallback for login OTP is now carrying drivers whose SMS is unavailable, and they still cannot acknowledge a required warehouse notice. The notice system is healthy. The authentication path in front of it is not.

Use email as a recovery channel, not as a silent substitute for the second factor. Choose a short email verification code when users commonly move between a handheld scanner and a separate mail device; choose a magic link when they can reliably open mail and finish the sign-in in the same browser context. In either case, bind one short-lived challenge to one login attempt, consume it once, redact its secret, and retain an auditable state transition. Geography does not change that mechanism: the US or EU deployment boundary should change data handling and retention decisions, not turn email possession into a stronger authenticator.

That is the operational answer. The rest is about catching the failure before a compliance workflow becomes an authentication incident.

What should page before the acknowledgment rate falls?

The late page measures business damage. An earlier signal has to sit where the channel decision is made. For a warehouse portal, I want six separate views: SMS challenge requests, accepted SMS sends, challenge age, email fallback offers, completed fallbacks, and duplicate consumptions. A single blended "OTP success" ratio hides the transition from one channel to another and makes a regional SMS failure look like ordinary user abandonment.

The alert should begin with a cohort, not a global average. Partition by facility or destination region, client type, and chosen channel, while keeping labels bounded. Phone numbers, email addresses, notice IDs, and challenge IDs belong in protected event records, not metric labels. An on-call responder needs to see that SMS completions fell after accepted sends remained flat, email fallback offers rose, and the affected users still could not reach the notice acknowledgment screen.

This distinction matters because an accepted send is not proof that a person received or used a challenge. Likewise, an email delivery event is not an authentication result. The application owns the final state: issued, channel selected, presented, verified, consumed, expired, or locked. Provider events can enrich that history, but they cannot replace it.

Page on sustained user impact with a minimum event count. A ratio over three attempts is noise; a ratio over a meaningful login cohort can be actionable. The exact count and window must come from the facility's normal traffic and response objective, not from a copied threshold. In production, I've been paged for both missed jobs and duplicate deliveries, so I treat absence and repetition as separate failure modes. The same reflex applies here: alert both when expected terminal events disappear and when a supposedly single-use challenge succeeds twice.

Trace one attempt, not two delivery channels

The clean integration boundary is a challenge record. SMS and email are delivery adapters around it, not independent authentication systems. When SMS becomes unavailable, the service should not mint an unrelated email credential with a fresh identity context. It should create a controlled transition for the same login intent and invalidate any credential that the policy says can no longer win the race.

An audit record can stay compact:

package auth

import "time"

type ChallengeEvent struct {
    ChallengeID string
    LoginID     string
    Channel     string // "sms" or "email"
    Kind        string // "code" or "link"
    State       string // "issued", "verified", "consumed", "expired", "locked"
    OccurredAt  time.Time
    Reason      string // policy reason, never the secret
}

Do not put the code, link token, phone number, or email address in this event. Store only what an investigator needs to reconstruct the decision, under the retention and access rules for that deployment. The verification service can retain a one-way verifier for a code or token and compare it inside the transaction that consumes the challenge.

That transaction is the hard part.

Two browser tabs, a delayed SMS, and an email opened on another device can all arrive close together. The database operation should change issued to consumed only if the challenge is still eligible, then reject every later contender. A queue cannot provide that invariant by itself. Make the state transition conditional at the system of record, and give the resulting session its own identifier so retries return the prior outcome instead of creating another session.

package auth

import (
    "context"
    "errors"
    "time"
)

var ErrChallengeUnavailable = errors.New("challenge unavailable")

type Store interface {
    Consume(ctx context.Context, challengeID string, now time.Time) (sessionID string, changed bool, err error)
}

func Finish(ctx context.Context, store Store, challengeID string, now time.Time) (string, error) {
    sessionID, changed, err := store.Consume(ctx, challengeID, now)
    if err != nil {
        return "", err
    }
    if !changed {
        return "", ErrChallengeUnavailable
    }
    return sessionID, nil
}

The interface is deliberately dull. Its implementation must make the eligibility check and update atomic.

One winner.

This is where duplicate-delivery incidents are either prevented or merely documented afterward.

Should email fallback for login OTP use a code or magic link?

Both options prove access to the same email inbox. A magic link does not become a stronger factor because it is longer, and a six-digit code does not become safe because it expires quickly. NIST SP 800-63B says email must not be used for out-of-band authentication. If the system has an assurance requirement governed by that guidance, email recovery cannot quietly inherit the label previously attached to an SMS-based factor. It may be an account-recovery or risk-managed continuity path, with the resulting session limited accordingly.

This is the central limitation: email fallback is not suitable when policy requires an independent second factor and the mailbox is protected by the same compromised session or device. The trade-off is continuity versus assurance, not code versus link. In that case, stop at a restricted recovery flow or require another authenticator rather than pretending the fallback preserved the original assurance level.

The integration-effort decision is more concrete:

Constraint	Email code	Magic link
Mail is read on another device	User can transcribe the code	Cross-device handoff needs additional design
Same browser and mailbox	Requires a return and entry step	Can resume directly after token validation
Link scanners or mail previews	Usually do not submit the code	May fetch a URL before the user acts
Browser state was lost	Code can be paired with an explicit login attempt	Link must recover context without becoming a bearer shortcut
Support investigation	Attempt count and terminal state are explicit	Fetch, confirmation, and consumption must be distinguished

For a mixed warehouse fleet, the first row often decides it. A driver may start on a shared terminal and read mail on a managed phone. A code crosses that device boundary without trying to transfer browser state. If the workforce uses one managed device and mail links reliably return to the initiating browser, a link removes a manual entry step.

Treat automated link fetching as expected internet behavior. A GET request should not consume the credential or finish login. Land on a confirmation view, recover the bound login context, and require an intentional action that performs the atomic consume. Never place a reusable session credential in the URL. Also set an attempt limit for codes, expire both forms, and issue a generic response to avoid turning fallback into an account-discovery endpoint.

Email content deserves less cleverness than it usually gets. Keep the code or action unambiguous, name the login context the user can recognize, and explain what to do if they did not initiate it. If templates use Mustache, remember that HTML escaping and unescaped variables are distinct syntax. Keep user-controlled values escaped, and test rendered text and HTML variants with missing and unusually long data. Template success is not delivery success, but a broken template can make every downstream metric look like a channel outage.

Instrument the handoff as a state machine

The first instrumentation change I would make is an event for the fallback decision itself: which policy made email eligible, which prior channel state was observed, and which challenge remained authoritative. Without that event, responders infer policy from send logs. Inference is slow during a page.

Use counters for transitions and histograms for elapsed time from issue to terminal state. Then derive funnels from the audit stream for deeper investigation. A useful trace tells a short story: SMS requested, fallback offered, email selected, credential presented, challenge consumed, notice displayed, acknowledgment recorded. Missing steps become visible without logging secrets.

Test the ugly sequences before deployment. Deliver the SMS after the email succeeds. Open the link twice. Submit the right code from two concurrent requests. Fetch the link with a scanner before a human sees it. Retry the compliance-notice dispatch after authentication completes. Every test should assert one terminal authentication result and an idempotent notice-dispatch record.

Roll out by bounded cohorts, and keep the channel policy reversible independently of the verification state machine. A feature flag may stop new fallback offers; it must not make already issued challenges unverifiable without an explicit policy decision. During rollout, compare terminal outcomes rather than provider acceptance rates.

The runbook ends at a policy decision

When the page fires, first establish whether the loss is before channel selection, during delivery, during credential presentation, or at atomic consumption. Check the cohort and deployment boundary. Confirm that duplicate consumption remains zero. Only then decide whether to widen email eligibility, restrict the resulting session, or pause new attempts while preserving audit evidence.

For US and EU users, do not fork code-versus-link behavior merely from a country field. Document the applicable assurance, privacy, retention, and incident-response requirements with the responsible security and legal owners, then encode the resulting policy as versioned configuration. The authentication event should record that policy version. This keeps a later audit focused on the rule that actually ran rather than the rule currently displayed in a dashboard.

The final alert threshold has a cost. Set it too loose and the first reliable signal remains the collapsed acknowledgment rate. Set it too tight and routine cohort variance wakes an engineer, trains the team to distrust the page, and encourages risky channel switching during healthy operation. Start from observed baselines, require enough volume, and page on sustained terminal failure; route weaker early signals to a ticket or dashboard. A false positive is not free simply because no login failed.

The durable rule is narrow: preserve one login intent, one consumable challenge, and one reviewable history across the channel change. Codes and links are interface choices around that invariant.

Further reading

• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management: https://pages.nist.gov/800-63-3/sp800-63b.html
• Mustache template syntax manual: https://mustache.github.io/mustache.5.html