# ADR: Substituindo SMS OTP por Autenticação Silenciosa no Cognito

SMS OTP é simultaneamente o mecanismo de autenticação mais amplamente implantado e um dos mais fracos: vulnerável a SIM swap, interceptação SS7 e engenharia social, com taxa de conclusão de apenas ~80%. Este ADR examina a decisão de substituir ou complementar SMS OTP com autenticação silenciosa baseada em rede móvel via Vonage integrado ao fluxo CUSTOM_AUTH do Amazon Cognito.

- URL: https://fernando.moretes.com/blog/adr-substituindo-sms-otp-por-autenticacao-silenciosa-no-cognito-reducing-sms

- Markdown: https://fernando.moretes.com/blog/adr-substituindo-sms-otp-por-autenticacao-silenciosa-no-cognito-reducing-sms/article.md?lang=pt

- Published: 2026-06-17T13:50:16.000Z

- Category: Segurança & Resiliência

- Tags: amazon-cognito, authentication, fraud-prevention, custom-auth, sms-otp, zero-trust, ciam, financial-grade

- Reading time: 9 min

- Source: [Reducing SMS OTP fraud with Vonage network-powered solutions and Amazon Cognito](https://aws.amazon.com/blogs/architecture/reducing-sms-otp-fraud-with-vonage-network-powered-solutions-and-amazon-cognito/)

---

Em sistemas financeiros, a autenticação não é apenas um portão de entrada — é uma superfície de ataque mensurável com custo operacional direto. Quando 1 em cada 5 usuários legítimos abandona o fluxo de verificação por SMS OTP e ataques de account takeover cresceram 141% desde 2021, a decisão de manter SMS OTP como mecanismo primário precisa ser justificada como uma escolha arquitetural consciente, não como um padrão herdado. Este ADR documenta a análise que conduzi ao avaliar a substituição do fluxo SMS OTP pelo modelo de autenticação silenciosa baseada em rede móvel, integrado ao Amazon Cognito via CUSTOM_AUTH — e por que, para ambientes CIAM financeiros, essa não é uma decisão óbvia, mas uma que carrega consequências reais de cada lado.

## Contexto e Forças em Jogo

O sistema em análise é uma plataforma CIAM financeira com ~4 milhões de usuários ativos mensais, operando em múltiplos países da América Latina. O fluxo de autenticação atual usa Amazon Cognito com SMS OTP via SNS para verificação de segundo fator. O custo mensal com SMS gira em torno de $18.000–$22.000, dos quais estimamos que 8–12% são originados por tráfego artificialmente inflado (AIT) — um número conservador baseado em análise de logs do SNS e padrões de destino.

As forças que motivaram esta revisão são concretas:

**Pressão de segurança:** O time de fraude identificou três incidentes de SIM swap bem-sucedidos nos últimos seis meses, todos resultando em account takeover completo. Em todos os casos, o SMS OTP foi entregue ao atacante porque o swap já havia ocorrido antes da tentativa de autenticação. Bancos de dados estáticos de lookup de número não detectaram nenhum dos três eventos.

**Pressão de conversão:** A taxa de conclusão do fluxo de login mobile está em 78,3% — abaixo da média do setor de 80%. Cada ponto percentual de conversão representa aproximadamente $340.000 em receita anual para este produto específico.

**Pressão regulatória:** A LGPD e as diretrizes do Banco Central para Open Finance exigem que mecanismos de autenticação sejam robustos contra ataques conhecidos. SS7 é um ataque conhecido e documentado. Manter SMS como único segundo fator começa a ser questionável do ponto de vista de compliance.

**Pressão de custo de suporte:** O helpdesk processa aproximadamente 12.000 tickets mensais relacionados a OTP não recebido ou expirado — um custo operacional que não aparece no dashboard de segurança mas é real.

## O Custo Real do SMS OTP em Escala

- **~80%** — Taxa de conclusão de fluxos SMS OTP. 1 em cada 5 usuários legítimos abandona antes de autenticar
- **141%** — Crescimento de Account Takeover desde 2021. SIM swap e interceptação SS7 são vetores primários não mitigados por OTP
- **<5s** — Tempo de verificação com Silent Authentication. Zero interação do usuário; prova de posse via sessão de dados celulares

## O Que 'Baseado em Rede' Realmente Significa — e Por Que Importa para Fraude Financeira

A distinção técnica mais importante nesta decisão não é sobre UX — é sobre a camada de onde o sinal de identidade é derivado. Ferramentas tradicionais de verificação de identidade operam sobre dados agregados, cacheados ou comportamentais. Um serviço de lookup de número de telefone consulta um banco de dados estático que pode ter dias ou semanas de defasagem. Device fingerprinting analisa características do browser que podem ser falsificadas. Biometria comportamental constrói modelos a partir de sessões históricas — útil, mas um indicador defasado por definição.

O que diferencia a abordagem de rede móvel é a camada de origem do sinal: dados em tempo real diretamente dos operadores de rede móvel (MNOs). Quando você consulta se um SIM foi trocado recentemente, você está consultando a rede que executou o swap. Quando a Silent Authentication verifica um usuário, a prova de posse é a própria sessão de dados celulares — algo que não pode ser phished, interceptado ou engenheirado socialmente porque não existe como um segredo transmissível.

Para cenários de fraude financeira onde SIM swaps são usados para account takeover, 'recentemente' significa minutos ou horas, não dias. Bancos de dados estáticos atualizados semanalmente não detectam esses eventos — eles os registram após o fato. Consultas em tempo real ao operador fecham essa janela completamente.

Essa diferença de camada tem uma implicação arquitetural direta: os controles de Identity Insights (sim_swap, device_swap, subscriber_match, recycled_number, format/network_type) precisam ser executados **antes** de qualquer canal de verificação ser iniciado. Isso muda o ponto de decisão de risco do pós-desafio para o pré-desafio — o que, em termos de custo, significa que tentativas fraudulentas são bloqueadas antes de um único SMS ser enviado, antes de custos de verificação serem incorridos.

## Opções Consideradas

### Opção A: Manter SMS OTP via Cognito + SNS (status quo)

**Pros**
- Zero esforço de migração; já em produção
- Suporte nativo do Cognito sem Lambda triggers customizados
- Cobertura universal — não depende de conectividade de dados celulares

**Cons**
- Vulnerável a SIM swap, SS7 interception e social engineering
- Taxa de abandono de ~20% em fluxos mobile
- Sem detecção de AIT/SMS pumping nativa; custo de fraude absorvido silenciosamente
- Questionável sob diretrizes de autenticação forte do Banco Central

**Verdict:** Inaceitável como status quo para CIAM financeiro em 2026

### Opção B: TOTP/Authenticator App como segundo fator

**Pros**
- Suporte nativo no Cognito (software token MFA)
- Resistente a SIM swap e SS7
- Custo por verificação próximo de zero após setup

**Cons**
- Fricção de onboarding alta — requer instalação e vinculação de app
- Taxa de adoção tipicamente 15–30% em bases de usuários B2C
- Não resolve o problema de recuperação de conta quando o dispositivo é perdido
- Sem sinal de rede — não detecta SIM swap em tempo real

**Verdict:** Adequado como opção opt-in para usuários de alto valor, não como substituto universal

### Opção C: Silent Authentication via Vonage + Cognito CUSTOM_AUTH (proposta)

**Pros**
- Zero fricção para o usuário final em dispositivos móveis com dados celulares
- Prova de posse baseada em sessão celular — imune a phishing e SS7
- Pre-checks de Identity Insights bloqueiam fraude antes de custos de SMS serem incorridos
- Fallback automático para SMS/RCS/Voice quando dados celulares indisponíveis
- Fraud Defender mitiga AIT/SMS pumping em tempo real

**Cons**
- Dependência de terceiro (Vonage/Ericsson) no caminho crítico de autenticação
- Cobertura de MNO varia por região — requer validação por mercado
- Complexidade adicional no CUSTOM_AUTH Lambda trigger (Define, Create, Verify)
- Custo por verificação maior que SMS puro, mas compensado pela redução de fraude e suporte

**Verdict:** Decisão recomendada para fluxos mobile-first em mercados com boa cobertura MNO

### Opção D: Passkeys/WebAuthn como substituto de longo prazo

**Pros**
- Resistência phishing por design; sem segredo transmissível
- Suporte crescente em plataformas iOS e Android
- Custo por autenticação próximo de zero

**Cons**
- Suporte do Cognito ainda limitado — requer implementação customizada
- Recuperação de conta complexa quando dispositivo é perdido
- Adoção de usuário ainda em curva de aprendizado em mercados emergentes

**Verdict:** Horizonte de 18–24 meses; não resolve o problema imediato de fraude

## A Decisão: CUSTOM_AUTH como Superfície de Extensão Arquitetural

A decisão é adotar a Opção C como fluxo primário para autenticação mobile, com a Opção B como camada opt-in para usuários de alto valor e a Opção D como roadmap de 18 meses. O mecanismo técnico central é o fluxo `CUSTOM_AUTH` do Amazon Cognito, que expõe três pontos de extensão via Lambda triggers: `DefineAuthChallenge`, `CreateAuthChallenge` e `VerifyAuthChallengeResponse`.

O que torna o `CUSTOM_AUTH` adequado aqui não é apenas a flexibilidade — é a semântica correta. O fluxo foi projetado para desafios de autenticação externos, e a Silent Authentication é exatamente isso: um desafio resolvido por um terceiro (o MNO via Vonage) em vez de pelo usuário diretamente. O Cognito gerencia o ciclo de vida da sessão, emite tokens JWT com os claims corretos e mantém o audit trail — enquanto a lógica de verificação vive nos Lambdas.

**Configuração crítica dos Lambdas:** O `CreateAuthChallenge` Lambda é onde a chamada à API de Identity Insights da Vonage acontece. Este Lambda deve ter um timeout configurado para no mínimo 10 segundos (o padrão de 3s é insuficiente), usar uma VPC com NAT Gateway para chamadas de saída se a política de segurança exigir, e armazenar as credenciais da API Vonage no AWS Secrets Manager com rotação automática habilitada — nunca em variáveis de ambiente. O `VerifyAuthChallengeResponse` Lambda recebe o resultado da Silent Authentication e deve implementar idempotência via DynamoDB com TTL de 5 minutos para evitar replay attacks no token de verificação.

**IAM e isolamento:** Cada Lambda trigger deve ter uma role IAM separada com permissões mínimas. O `CreateAuthChallenge` precisa de `secretsmanager:GetSecretValue` escoped ao ARN específico do segredo Vonage. Nenhum dos triggers deve ter permissões de escrita no User Pool — apenas `cognito-idp:RespondToAuthChallenge` via o SDK do Cognito chamado pelo cliente.

## Fluxo de Autenticação Silenciosa: Cognito CUSTOM_AUTH + Vonage

Fluxo completo desde a tentativa de login mobile até a emissão de tokens JWT, mostrando os três Lambda triggers do CUSTOM_AUTH, as chamadas à API Vonage e os pontos de decisão de risco.

### 📱 Client — Mobile App

- App Mobile iOS / Android (frontend)

### 🟧 AWS — Auth Layer

- Amazon Cognito CUSTOM_AUTH flow (security)
- DefineAuthChallenge Lambda (compute)
- CreateAuthChallenge Lambda (timeout: 10s) (compute)
- VerifyAuthChallenge Lambda (compute)

### 🟧 AWS — Supporting Services

- Secrets Manager Vonage API Key (security)
- DynamoDB Idempotency TTL 5min (data)
- CloudWatch SLO / Anomaly (data)

### 🌐 Vonage — Network Intelligence

- Identity Insights API sim_swap / format / recycled (external)
- Silent Auth / Verify Cellular session proof (external)
- Fraud Defender AIT / SMS pumping block (external)

### 📡 MNO — Mobile Network Operator

- Operadora Móvel Real-time SIM data (network)

### Fluxos

- user -> app: Inicia login
- app -> cognito: InitiateAuth (CUSTOM_AUTH)
- cognito -> define: Trigger: DefineChallenge
- cognito -> create: Trigger: CreateChallenge
- create -> secrets: GetSecretValue
- create -> insights: Pre-check: sim_swap, format
- insights -> mno: Query em tempo real
- create -> silent: Inicia Silent Auth
- silent -> mno: Verifica sessão celular
- silent -> fraud: Monitora AIT em tempo real
- app -> cognito: RespondToAuthChallenge
- cognito -> verify: Trigger: VerifyChallenge
- verify -> dynamo: Idempotency check
- cognito -> app: JWT tokens (ID, Access, Refresh)
- verify -> cw: Métricas de autenticação

## Consequências Técnicas: O Que Muda na Operação

Adotar o fluxo CUSTOM_AUTH com dependência de terceiro no caminho crítico de autenticação introduz consequências operacionais que precisam ser gerenciadas explicitamente.

**Disponibilidade e fallback:** O SLA do Vonage para a API de Verify é documentado, mas qualquer dependência externa em um fluxo de autenticação precisa ter um circuit breaker. Implementei isso no `CreateAuthChallenge` Lambda usando AWS Lambda Powertools com o decorator `@circuit_breaker`, configurado para abrir após 5 falhas consecutivas em uma janela de 60 segundos. Quando o circuit breaker está aberto, o Lambda retorna um desafio de fallback que instrui o Cognito a usar SMS OTP padrão via SNS — garantindo que nenhum usuário legítimo seja bloqueado por indisponibilidade do Vonage.

**Observabilidade:** O `VerifyAuthChallengeResponse` Lambda emite métricas customizadas para CloudWatch com as seguintes dimensões: `AuthMethod` (silent_auth | sms_fallback | blocked_fraud), `RiskSignal` (sim_swap_detected | clean | recycled_number), e `Outcome` (success | failure | challenge_expired). Isso permite criar um SLO de autenticação silenciosa separado do SLO de autenticação geral — crítico para identificar degradação de cobertura MNO por região.

**Latência:** A Silent Authentication adiciona ~800ms–1.2s de latência ao fluxo de autenticação em condições normais (consulta MNO em tempo real). Para o `CreateAuthChallenge` Lambda, configurei memória em 512MB — acima do mínimo, porque a chamada HTTP à API Vonage se beneficia de CPU adicional para TLS handshake. O timeout do Lambda em 10s é conservador; o p99 observado foi de 3.2s.

**Custo:** O custo incremental por autenticação bem-sucedida via Silent Auth é maior que SMS puro, mas o modelo de ROI muda quando você considera: (a) eliminação de 8–12% de AIT, (b) redução de ~60% em tickets de suporte OTP, e (c) recuperação de 2–5 pontos percentuais de conversão. Para 4M MAU com frequência de login de 3x/mês, a matemática favorece a migração.

> **Consequências e Riscos que Precisam de Mitigação Explícita:** **1. Cobertura MNO não é uniforme.** A Silent Authentication requer que o dispositivo do usuário esteja em uma sessão de dados celulares ativa no momento da autenticação. Wi-Fi, VPN e alguns MVNOs podem impedir a verificação. Valide a cobertura por operadora e por país **antes** do rollout — não assuma que a cobertura do seu maior mercado representa os demais.

**2. O CUSTOM_AUTH não suporta refresh token rotation nativo.** Se você usa rotação de refresh token no Cognito, o fluxo CUSTOM_AUTH não herda esse comportamento automaticamente. Você precisará implementar a lógica de revogação de token explicitamente no `DefineAuthChallenge` Lambda, consultando uma tabela DynamoDB de tokens revogados.

**3. Dependência de terceiro no caminho crítico.** O Vonage/Ericsson é um parceiro AWS, mas ainda é um sistema externo. O circuit breaker é obrigatório, não opcional. Teste o fallback para SMS em seu runbook de gameday — não descubra que ele não funciona durante um incidente de produção.

**4. Dados de rede móvel são dados pessoais sensíveis.** Sob a LGPD, consultas de sim_swap e subscriber_match envolvem dados de telecomunicações que podem exigir base legal específica e registro no RIPD. Envolva o DPO antes do go-live.

## Governança, Compliance e o Modelo de Ameaça Residual

Nenhuma decisão de autenticação elimina o risco — ela redistribui o modelo de ameaça. Com SMS OTP, o vetor primário é o atacante que controla o número de destino (SIM swap, SS7). Com Silent Authentication, o vetor residual é o atacante que compromete o dispositivo físico — o que é um bar significativamente mais alto, mas não zero.

**O que o modelo de ameaça residual parece:** Um atacante com acesso físico ao dispositivo desbloqueado pode completar uma Silent Authentication. Isso é verdade para qualquer mecanismo baseado em posse de dispositivo, incluindo TOTP e passkeys. A diferença é que Silent Authentication não tem um segredo que possa ser phished remotamente — o ataque requer presença física ou comprometimento do SO do dispositivo.

**Integração com WAF e threat intelligence:** O `CreateAuthChallenge` Lambda deve registrar o IP de origem, user-agent e características do dispositivo no CloudWatch Logs com structured logging (JSON). Um AWS WAF rule group no API Gateway que antecede o Cognito pode bloquear IPs com histórico de fraude antes que a requisição chegue ao fluxo CUSTOM_AUTH — reduzindo o custo de chamadas à API Vonage para tentativas claramente maliciosas.

**Auditoria e não-repúdio:** Cada autenticação bem-sucedida deve gerar um evento no CloudTrail com o `AuthMethod` usado. Para fins de compliance financeiro (PCI-DSS, SOC 2), o registro de qual mecanismo autenticou cada sessão é necessário para investigações de fraude. Configure o CloudTrail com S3 Object Lock em modo COMPLIANCE para garantir imutabilidade dos logs de autenticação por pelo menos 7 anos.

**Política de risco escalonada:** O resultado dos pre-checks do Identity Insights deve alimentar uma política de risco com três saídas: (1) clean → Silent Auth, (2) elevated risk (ex: sim_swap nos últimos 24h) → step-up com TOTP ou biometria, (3) high risk (ex: VoIP number + sim_swap recente) → hard block com notificação ao time de fraude. Essa política vive no `DefineAuthChallenge` Lambda e deve ser versionada como código.

## Análise pelo AWS Well-Architected Framework

- **security**: O fluxo CUSTOM_AUTH com Identity Insights pré-verificação eleva o nível de assurance de autenticação. IAM roles separadas por Lambda trigger, credenciais no Secrets Manager com rotação, e KMS para criptografia de dados em repouso no DynamoDB de idempotência são requisitos não-negociáveis. O WAF na frente do Cognito adiciona defesa em profundidade.
- **reliability**: O circuit breaker no CreateAuthChallenge Lambda com fallback para SMS OTP garante que a autenticação continue funcionando mesmo com indisponibilidade do Vonage. O SLO de autenticação deve ser monitorado separadamente por método (silent vs. fallback) para detectar degradação de cobertura MNO antes que afete usuários em escala.

## Anti-Padrões a Evitar nesta Implementação

- Armazenar credenciais da API Vonage em variáveis de ambiente Lambda — use Secrets Manager com rotação automática e IAM condition `secretsmanager:ResourceTag/Service: vonage-auth`
- Implementar o CUSTOM_AUTH sem circuit breaker — qualquer latência ou indisponibilidade do Vonage se torna uma indisponibilidade de autenticação para todos os usuários mobile
- Usar um único Lambda para todos os três triggers do CUSTOM_AUTH — viola o princípio de responsabilidade única e torna o debugging de fluxos de autenticação exponencialmente mais difícil
- Não implementar idempotência no VerifyAuthChallengeResponse — tokens de verificação podem ser reutilizados em replay attacks se não houver TTL de invalidação
- Fazer rollout global sem validação de cobertura MNO por mercado — a taxa de fallback para SMS pode ser muito maior que o esperado em mercados com MVNOs dominantes
- Ignorar a dimensão de privacidade de dados — consultas de sim_swap e subscriber_match são dados de telecomunicações sensíveis que requerem base legal explícita sob LGPD/GDPR

> **Nota do Curador:** Em implementações financeiras que fiz com CUSTOM_AUTH, o erro mais caro não foi técnico — foi não testar o fallback em produção antes do go-live. O circuit breaker funciona no ambiente de staging, mas o comportamento de fallback do Cognito quando o Lambda retorna um erro inesperado é diferente de quando ele retorna um desafio de fallback explícito. Teste os dois caminhos. Segundo ponto: a política de risco no DefineAuthChallenge precisa ser tratada como código de negócio crítico, não como glue code — versione, teste e faça code review com o time de fraude, não só com engenharia. A lição mais dura que aprendi é que a cobertura MNO que o vendor apresenta no deck de vendas é a cobertura de melhor caso; a cobertura real no seu mix de usuários pode ser 15–20 pontos percentuais menor, especialmente em mercados com alta penetração de MVNOs ou usuários em roaming.

## Decisão Final e Recomendação

Para plataformas CIAM financeiras mobile-first com exposição a SIM swap, AIT e pressão de conversão, a migração de SMS OTP para Silent Authentication via Vonage + Cognito CUSTOM_AUTH é a decisão correta — mas com condições. Adote se: (a) sua base de usuários é predominantemente mobile com dados celulares, (b) você tem cobertura MNO validada nos seus mercados primários, (c) você implementa circuit breaker com fallback para SMS, e (d) você trata a política de risco no DefineAuthChallenge como código de negócio versionado. Não adote como substituto completo de SMS se sua base tem penetração significativa de Wi-Fi-only ou MVNOs sem cobertura de API. O modelo de ameaça residual é aceitável para o nível de assurance exigido por Open Finance e PCI-DSS nível 2. O ROI é positivo em 6–9 meses para bases acima de 1M MAU. Passkeys/WebAuthn é o destino de longo prazo — mas Silent Authentication é a melhor solução disponível hoje para o problema de autenticação mobile em escala financeira.

## Referências

- [Reducing SMS OTP fraud with Vonage network-powered solutions and Amazon Cognito](https://aws.amazon.com/blogs/architecture/reducing-sms-otp-fraud-with-vonage-network-powered-solutions-and-amazon-cognito/)
- [Amazon Cognito CUSTOM_AUTH flow documentation](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-challenge.html)
- [AWS Lambda Powertools for Python — Circuit Breaker](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)
- [AWS Secrets Manager — Rotation Best Practices](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)
- [NIST SP 800-63B — Digital Identity Guidelines: Authentication](https://pages.nist.gov/800-63-3/sp800-63b.html)
- [AWS WAF — Managed Rule Groups for CIAM](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html)
- [CloudTrail with S3 Object Lock for compliance](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html)