ADR: Replacing SMS OTP with Silent Authentication in Cognito

The system under analysis is a financial CIAM platform with ~4 million monthly active users, operating across multiple Latin American countries. The current authentication flow uses Amazon Cognito with SMS OTP via SNS for second-factor verification. Monthly SMS costs run approximately $18,000–$22,000, of which we estimate 8–12% originates from artificially inflated traffic (AIT) — a conservative number based on SNS log analysis and destination patterns.

The forces driving this review are concrete:

Security pressure: The fraud team identified three successful SIM swap incidents over the past six months, all resulting in complete account takeover. In every case, the SMS OTP was delivered to the attacker because the swap had already occurred before the authentication attempt. Static number lookup databases detected none of the three events.

Conversion pressure: The mobile login flow completion rate sits at 78.3% — below the 80% industry average. Each percentage point of conversion represents approximately $340,000 in annual revenue for this specific product.

Regulatory pressure: LGPD and Banco Central guidelines for Open Finance require authentication mechanisms to be robust against known attacks. SS7 is a known, documented attack. Keeping SMS as the sole second factor is becoming questionable from a compliance standpoint.

Support cost pressure: The helpdesk processes approximately 12,000 monthly tickets related to OTP not received or expired — an operational cost that doesn't appear on the security dashboard but is very real.

The most important technical distinction in this decision is not about UX — it is about the layer from which the identity signal is derived. Traditional identity verification tools operate on aggregated, cached, or behavioral data. A phone number lookup service queries a static database that may be days or weeks out of date. Device fingerprinting analyzes browser characteristics that can be spoofed. Behavioral biometrics builds models from historical sessions — useful, but a lagging indicator by definition.

What differentiates the mobile network approach is the origin layer of the signal: real-time data directly from mobile network operators (MNOs). When you query whether a SIM was recently swapped, you are querying the network that performed the swap. When Silent Authentication verifies a user, the possession proof is the cellular data session itself — something that cannot be phished, intercepted, or socially engineered because it does not exist as a transmissible secret.

For financial fraud scenarios where SIM swaps are weaponized for account takeover, 'recently' means minutes or hours, not days. Static databases refreshed weekly are not detecting these events — they are logging them after the fact. Real-time operator queries close that window entirely.

This layer difference has a direct architectural implication: the Identity Insights controls (sim_swap, device_swap, subscriber_match, recycled_number, format/network_type) must execute before any verification channel is initiated. This shifts the risk decision point from post-challenge to pre-challenge — which, in cost terms, means fraudulent attempts are blocked before a single SMS is sent, before verification costs are incurred.

The decision is to adopt Option C as the primary flow for mobile authentication, with Option B as an opt-in layer for high-value users and Option D as an 18-month roadmap item. The central technical mechanism is Amazon Cognito's CUSTOM_AUTH flow, which exposes three extension points via Lambda triggers: DefineAuthChallenge, CreateAuthChallenge, and VerifyAuthChallengeResponse.

What makes CUSTOM_AUTH appropriate here is not just flexibility — it is the correct semantics. The flow was designed for external authentication challenges, and Silent Authentication is exactly that: a challenge resolved by a third party (the MNO via Vonage) rather than directly by the user. Cognito manages the session lifecycle, issues JWT tokens with correct claims, and maintains the audit trail — while verification logic lives in the Lambdas.

Critical Lambda configuration: The CreateAuthChallenge Lambda is where the Vonage Identity Insights API call happens. This Lambda must have a timeout configured for at least 10 seconds (the 3s default is insufficient), use a VPC with NAT Gateway for outbound calls if security policy requires it, and store Vonage API credentials in AWS Secrets Manager with automatic rotation enabled — never in environment variables. The VerifyAuthChallengeResponse Lambda receives the Silent Authentication result and must implement idempotency via DynamoDB with a 5-minute TTL to prevent replay attacks on the verification token.

IAM and isolation: Each Lambda trigger must have a separate IAM role with minimum permissions. The CreateAuthChallenge needs secretsmanager:GetSecretValue scoped to the specific Vonage secret ARN. None of the triggers should have write permissions to the User Pool — only cognito-idp:RespondToAuthChallenge via the Cognito SDK called by the client.

Adopting the CUSTOM_AUTH flow with a third-party dependency in the critical authentication path introduces operational consequences that need to be managed explicitly.

Availability and fallback: Vonage's SLA for the Verify API is documented, but any external dependency in an authentication flow needs a circuit breaker. I implemented this in the CreateAuthChallenge Lambda using AWS Lambda Powertools with the @circuit_breaker decorator, configured to open after 5 consecutive failures within a 60-second window. When the circuit breaker is open, the Lambda returns a fallback challenge that instructs Cognito to use standard SMS OTP via SNS — ensuring no legitimate user is blocked by Vonage unavailability.

Observability: The VerifyAuthChallengeResponse Lambda emits custom CloudWatch metrics with the following dimensions: AuthMethod (silent_auth | sms_fallback | blocked_fraud), RiskSignal (sim_swap_detected | clean | recycled_number), and Outcome (success | failure | challenge_expired). This enables creating a silent authentication SLO separate from the general authentication SLO — critical for identifying MNO coverage degradation by region.

Latency: Silent Authentication adds ~800ms–1.2s of latency to the authentication flow under normal conditions (real-time MNO query). For the CreateAuthChallenge Lambda, I configured memory at 512MB — above the minimum, because the HTTP call to the Vonage API benefits from additional CPU for TLS handshake. The Lambda timeout at 10s is conservative; observed p99 was 3.2s.

Cost: The incremental per-authentication cost via Silent Auth is higher than raw SMS, but the ROI model changes when you factor in: (a) elimination of 8–12% AIT, (b) ~60% reduction in OTP support tickets, and (c) recovery of 2–5 percentage points of conversion. For 4M MAU with a 3x/month login frequency, the math favors migration.

No authentication decision eliminates risk — it redistributes the threat model. With SMS OTP, the primary vector is the attacker who controls the destination number (SIM swap, SS7). With Silent Authentication, the residual vector is the attacker who compromises the physical device — a significantly higher bar, but not zero.

What the residual threat model looks like: An attacker with physical access to an unlocked device can complete a Silent Authentication. This is true for any device-possession-based mechanism, including TOTP and passkeys. The difference is that Silent Authentication has no secret that can be phished remotely — the attack requires physical presence or OS-level device compromise.

WAF and threat intelligence integration: The CreateAuthChallenge Lambda should log the source IP, user-agent, and device characteristics to CloudWatch Logs with structured logging (JSON). An AWS WAF rule group on the API Gateway preceding Cognito can block IPs with fraud history before the request reaches the CUSTOM_AUTH flow — reducing the cost of Vonage API calls for clearly malicious attempts.

Audit and non-repudiation: Each successful authentication should generate a CloudTrail event with the AuthMethod used. For financial compliance purposes (PCI-DSS, SOC 2), recording which mechanism authenticated each session is necessary for fraud investigations. Configure CloudTrail with S3 Object Lock in COMPLIANCE mode to guarantee immutability of authentication logs for at least 7 years.

Tiered risk policy: The Identity Insights pre-check output should feed a risk policy with three outputs: (1) clean → Silent Auth, (2) elevated risk (e.g., sim_swap in last 24h) → step-up with TOTP or biometrics, (3) high risk (e.g., VoIP number + recent sim_swap) → hard block with fraud team notification. This policy lives in the DefineAuthChallenge Lambda and must be versioned as code.