HadleyFox8439

Posted on Oct 11

SMS OTP Compliance: 3 GDPR, PSD2, and NIST Login Boundaries

#email #sms #sre

SMS OTP is not enough by itself to establish GDPR, PSD2, or NIST compliance for a pharmacy login. It can be one 2FA control, but the system still has to address SIM-swap and phishing risks, protect recipient data, enforce the right policy, and keep refill alerts separate from authentication decisions. The page may say a scheduled alert completed while the actual safety boundary has already failed.

TL;DR: use SMS OTP as a recoverable login factor, not as a compliance verdict. Bind each OTP to one short-lived authentication attempt, rate-limit guessing and resends, and provide a stronger path for high-risk actions. Separately, treat phone validity as durable state: ingest hard failure, repeated soft failure, and an explicit recipient stop before the next pharmacy refill schedule expands its audience. A green job counter can hide both an account-takeover path and a broken notification audience.

This is mostly an integration problem. The difficult boundary is not sending a message; it is keeping authentication, consent, recipient validity, and scheduled delivery as separate, reviewable state machines without letting one malformed event lock out a patient or silence a valid subscriber.

When is SMS OTP enough for GDPR and PSD2 compliance?

No.

GDPR, PSD2, and NIST describe different scopes, so the presence of an SMS OTP field cannot answer the compliance question. An EU or US team needs to map the actual login flow, data handling, recovery process, and regulated action to the rules that apply to it. A pharmacy refill alert is also not automatically a payment authentication event merely because a phone number is involved. Record that scope decision and have the responsible legal and security reviewers approve it; do not encode a regulation name as a Boolean in application code.

The practical security question is narrower: what happens when an attacker controls the phone channel or convinces a patient to relay a code? SIM swap can redirect SMS delivery, while phishing can capture an OTP from the legitimate recipient. A six-digit code does not know which browser requested it. Binding the server-side challenge to a single pending login, expiring it, limiting attempts, invalidating it after success, and stepping up high-risk changes reduce distinct failure modes, but none of those controls turns SMS into proof of compliance.

The trade-off is real. SMS reaches users without requiring an authenticator enrollment ceremony, which lowers integration and recovery friction, but that same dependence on the phone channel makes it unsuitable as the only control for every risk tier. Keep a stronger authentication option and a recovery path that does not collapse back to “send another SMS.” For refill reminders that contain no login code, keep notification consent and delivery status out of the 2FA trust decision.

Reliability starts with the first missed refill alert

The earlier signal is feedback age. A scheduler can report success after it has handed work to a queue, while bounce and carrier feedback waits elsewhere. If that feedback is not applied before the next media campaign is expanded, known-invalid recipients are enqueued again. Every retry adds noise, and the useful delivery signal gets harder to see.

Watch three operational measurements together:

the age of the oldest unprocessed feedback event;
the ratio of newly suppressed recipients to attempted recipients, split by channel and reason;
repeat attempts made after a suppression decision should have become visible.

The third measurement is an invariant, not a business KPI. It should normally be zero. A nonzero value points toward stale caches, ordering trouble, or a scheduler that took its audience snapshot before suppression state was committed.

Do not use an email authentication failure as proof that a recipient is invalid. SPF defines a mechanism for a receiving system to check whether a host is authorized to use a domain in the SMTP HELO or MAIL FROM identity. That is about sending-domain authorization, not mailbox existence. Mixing those concepts creates a particularly bad failure mode: an infrastructure configuration error becomes a mass recipient suppression event.

Threat-model the phone channel before coding

Channel feedback needs normalization, but normalization must preserve evidence. Store the raw event reference, observed time, channel, reason class, and source identifier beside the resulting decision. Then make the transition idempotent.

Signal	Default action	Why the boundary matters
Permanent destination failure	Suppress that channel address	Repeating the same destination cannot repair it
Temporary delivery failure	Count within a defined window; retry under policy	A transient network or capacity fault is not recipient invalidity
Explicit stop or opt-out	Suppress immediately for that channel	Recipient intent must not be converted into a retry problem

The word “default” matters. Feedback taxonomies vary across transports, so the adapter should map source-specific values into internal reason classes while retaining the original value for audit and reprocessing. Do not make the scheduler understand every upstream vocabulary. Give it one read: “is this destination eligible at the schedule’s decision time?”

Keep email and phone state separate. A failed mailbox does not establish that a phone number is invalid, and an SMS stop does not answer whether a separately authorized email may be used. Cross-channel policy belongs in an explicit consent and communication-preference layer, not in a clever bounce handler.

Small state machines age better.

Implement idempotent suppression after authentication

Feedback is commonly delivered more than once or out of order. The safe handler therefore deduplicates by a stable source event ID and applies transitions in a transaction. The following Go sketch keeps transport parsing outside the domain decision and makes duplicate processing visible to the caller.

package suppression

import (
    "context"
    "time"
)

type Feedback struct {
    EventID    string
    Channel    string
    Recipient  string
    Reason     string
    ObservedAt time.Time
}

type Store interface {
    AlreadyApplied(ctx context.Context, eventID string) (bool, error)
    ApplySuppression(ctx context.Context, f Feedback) error
}

func Handle(ctx context.Context, store Store, f Feedback) (bool, error) {
    applied, err := store.AlreadyApplied(ctx, f.EventID)
    if err != nil || applied {
        return false, err
    }

    switch f.Reason {
    case "permanent_destination_failure", "recipient_stop":
        if err := store.ApplySuppression(ctx, f); err != nil {
            return false, err
        }
        return true, nil
    default:
        return false, nil
    }
}

In production, the event marker and state transition need one atomic store operation; the split interface above is deliberately readable, not a transaction recipe. A unique constraint on the source event ID closes the race between two workers. The suppression record should also carry a reason and timestamp so an operator can explain why an address disappeared from a scheduled audience.

Temporary failures need a separate counter keyed by destination and failure class. Set its window and threshold from observed delivery behavior and operational tolerance, then document both in the runbook. A magic number copied from another channel is not evidence.

Monitor lag, duplicates, and invalid recipients

Before allowing a new classifier to suppress recipients, run it in shadow mode against live-shaped feedback and compare its proposed decisions with the existing path. The useful review sample includes duplicates, late arrivals, an unknown reason, a permanent failure followed by a delayed temporary failure, and a stop event that arrives while a schedule is expanding.

The deployment order is instrumentation first, decision second. Add counters for parsed, rejected, duplicated, and applied events. Add feedback-age histograms and the post-suppression attempt invariant. Only then let the new decision feed the eligibility read used by the scheduler.

This order exposes an integration mistake without changing the audience. It also gives the on-call a trace from page to cause: schedule ID to audience snapshot, recipient hash to eligibility decision, decision to source feedback event. Avoid putting raw addresses or phone numbers in metric labels; use bounded reason and channel dimensions, with sensitive lookup data kept in access-controlled records.

The runbook should ask one question early: did delivery fail, or did feedback processing fall behind? Those incidents look similar at the top-line graph but demand different containment. Pausing schedule expansion may prevent repeated attempts during a feedback backlog. Changing suppression rules during a delivery-provider outage may instead hide valid recipients.

Trade reach for false-positive cost deliberately

An aggressive temporary-failure threshold lowers repeated traffic but raises the chance of suppressing a reachable recipient during a short-lived transport problem. A loose threshold preserves reach but keeps dead destinations circulating longer. There is no universal count that resolves that trade-off.

Measure proposed suppressions by reason before changing the threshold, and require a reversible state transition for threshold-derived decisions. Permanent failures and explicit stops should remain distinct because their recovery and audit paths differ. If an operator cannot tell which rule fired, rollback becomes guesswork.

False positives have a direct editorial cost: readers miss time-sensitive media alerts even though the publishing job appears healthy. That is why the final alert should not fire on a raw suppression count alone. Page on a meaningful deviation from the channel’s established baseline, corroborated by feedback age or post-suppression attempts; route smaller shifts to investigation. The exact threshold belongs to observed traffic and an error budget, not to an article.

The decision rule is straightforward: suppress durable invalidity and explicit stops, quarantine uncertainty, and make every transition traceable before the next schedule reads it.

DEV Community