Short answer: make an authenticator app the default for SaaS login 2FA when users can enroll and recover safely; keep SMS OTP or an email code as a deliberate fallback when reach matters more than channel independence. For US and EU traffic, choose from measured verification outcomes, not assumptions about a region or a provider's accepted-send response. An e-commerce compliance notice needs its own auditable record outside this short-lived login flow.
At 09:17, the page says customers can't sign in. The on-call sees accepted SMS and email requests, no obvious queue backlog, and a rising number of failed challenges. Those green transport checks don't answer the useful question: did the intended person verify the intended challenge before it expired?
I've been paged by missed jobs and duplicate deliveries. The same reflex applies here — start at the failed user outcome, assign one identity to each logical challenge, and work backward. The simplest-looking channel can produce the least useful incident timeline.
What should US and EU SaaS teams monitor for SMS OTP, authenticator app, and email code 2FA?
Monitor the challenge state machine first. Each event needs a pseudonymous account key, a challenge ID, the method, creation and expiration times, the attempt number, the outcome, and a terminal reason. Never log the code. A trace should distinguish incorrect, expired, superseded, and verified, because a single failed counter mixes user input, delayed delivery, repeat requests, and policy decisions into one noisy number.
The country label is only a dimension. It isn't a diagnosis. Break outcomes down by region, method, challenge age, client release, and — where the reviewed data permits it — carrier or mailbox domain. I'm not sure a regional aggregate alone can resolve a complaint; the missing dimension is often visible only after the first split.
A small event model makes the boundary reviewable:
type ChallengeEvent struct {
ChallengeID string
AccountKey string // Pseudonymous; never log the OTP.
Method string // authenticator_app, sms_otp, or email_code
Stage string // created, dispatched, verified, expired, superseded
OccurredAt time.Time
Region string
}
type NoticeEvent struct {
NoticeID string
RecipientKey string
NoticeVersion string
DeliveryStage string
OccurredAt time.Time
}
Keep it boring.
Work backward from the 09:17 page
Begin with verification outcomes, then look for the earlier signal that would have bought the on-call time. Split expiration from incorrect entry. Compare creation-to-dispatch and creation-to-verification distributions by method. Check whether repeat requests and superseded challenges rose before the page. A growing tail of challenge age can matter while queue depth still looks normal, and a delayed first code can arrive after the user has requested a second one.
That ordering forces three states apart: accepted, delivered, and consumed. DKIM defines a way for an organization to claim responsibility for a message through a cryptographic signature that a verifier can validate. It does not establish that a person read an email or used its login code. Apple Mail Privacy Protection also changes how remote content is downloaded, so an open-style event is a poor substitute for a successful challenge verification. For login 2FA, the decisive application event is the verifier accepting the correct live challenge under the configured policy.
No guessing.
The instrumentation change is to emit state transitions before enabling a new page. Preserve raw counts beside ratios, and test duplicate dispatches, out-of-order events, concurrent verification, expiration, and supersession in a non-production environment. A retry with the same idempotency key should refer to the same logical challenge; verification should atomically consume or reject that challenge according to policy. Otherwise, retry behavior becomes account-state ambiguity just when the incident is hardest to read.
Shadow the alert across ordinary traffic before it pages anyone. The observation window depends on traffic shape and release cadence — your mileage may vary — but it must include enough events that one failed challenge cannot masquerade as a regional outage. Compare the new user-outcome signal with the old transport signal and write the disagreement into the runbook.
Choose the factor after you can trace it
The default should minimize shared failure domains without creating an unrecoverable enrollment policy. That makes an authenticator app a strong default: code generation doesn't wait for an SMS or email transport hop. The catch is recovery. It is not suitable as the only option when users cannot install an app, or when the team has no defensible process for device replacement and backup access.
SMS OTP trades channel independence for familiar reach. Use it when possession of a phone number already belongs in the account relationship and the team accepts the delivery and recovery dependency. The verifier must have an explicit rule for repeat requests: commonly, the newest challenge supersedes the older one, though a deliberately bounded overlap is possible. Don't let whatever arrives first decide account state.
Email code can reduce enrollment friction for accounts that already have a verified mailbox, but it may share a failure domain with password reset and account recovery. Stick with email when that trade-off fits the risk model; don't treat it as an independent factor for privileged administration or high-impact actions without a separate review.
| Method | Reliability advantage | Operational limitation | Sensible role |
|---|---|---|---|
| Authenticator app | No message-delivery hop during login | Enrollment and lost-device recovery need support | Default when channel independence matters |
| SMS OTP | Familiar possession flow | Timely use depends on the phone delivery path | Fallback where phone reach is already required |
| Email code | Reuses a verified mailbox | Can share recovery and password-reset failure domains | Lower-friction fallback for an accepted risk tier |
“Simplest” and “cheapest” need full-path definitions. An authenticator app avoids a per-message dependency, while SMS and email add transport, support, abuse-control, and reconciliation work that varies with traffic and contracts. Cost belongs after verification reliability and recoverability. A cheap accepted send that ends in a lockout is operationally expensive.
Keep compliance evidence out of the login challenge
An e-commerce compliance notice and a 2FA code can use the same outward channel, but they have different evidence and retention needs. Give the notice a separate identifier, version, recipient reference, dispatch time, channel events, and reconciliation state. Do not reuse the OTP expiration timer, and do not let a login retry overwrite the notice record. A customer may finish 2FA while notice evidence is still being reconciled; either lifecycle must remain intelligible on its own.
DKIM verification can be one artifact in an email notice record. It still isn't proof of reading. The audit question is which notice version entered which recorded delivery states for which pseudonymous recipient, while the login question is whether one live challenge was validly consumed. Putting both behind sent=true guarantees a thin postmortem.
One state machine, two evidence streams.
The pager threshold is part of the design
Page on a sustained user-outcome condition with a minimum event count. Send lower-confidence transport movement to a dashboard or ticket. When the alert fires, the runbook should scope failures by method, region, challenge age, and client release; inspect repeat requests and supersession; apply only a preapproved fallback policy; and keep rate limits and abuse controls visible. An improvised bypass can turn a delivery incident into an account security incident.
The false-positive cost is real. A threshold set too high lets customers discover the incident first. One set too low repeatedly wakes the on-call for ordinary variance in thin slices, teaching the team to distrust the page. Review it after releases and traffic shifts, and require the page to predict an action someone can take. A perfectly quiet pager isn't the goal.
An actionable one is.
References
- RFC 6376, DomainKeys Identified Mail (DKIM): https://datatracker.ietf.org/doc/html/rfc6376
- Apple, Mail Privacy Protection guide: https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios
Top comments (0)