UX encantadora, retenção por inércia e segurança que só aparece quando dá ruim. Uma análise do papel (e da omissão) da segurança na construção da confiança digital.
No ecossistema financeiro atual — agitado por buzzwords como fintechs, open banking e open insurance — a palavra "principalidade" voltou à tona: quem o cliente escolhe como principal referência em sua vida financeira.
Mas essa escolha ainda é realmente dele?
Prometemos liberdade digital. Mas, na prática, muitos produtos se assemelham a estruturas de retenção com design elegante — um labirinto com bordas arredondadas. A barrinha de progresso move? Sim. Mas para onde, exatamente?
Segurança como atrito ou pilar?
A segurança de aplicações deveria ser uma aliada da confiança — não uma ameaça à conversão.
"Esse controle de sessão quebrou o fluxo, tira." "Esse timeout atrapalha o onboarding." "Segundo fator de autenticação? Melhor remover, impacta conversão."
Segurança, nesse cenário, é tratada como um custo de atrito — não como um investimento em confiança. Seu papel vira "não atrapalhar demais".
Enquanto isso, do outro lado do espectro, profissionais de segurança criam barreiras desproporcionais por ego técnico: camadas de proteção que ninguém entende, sem clareza de impacto, desacelerando o produto e alienando o negócio.
Como vemos isso na prática
Alguns anos atrás, durante uma conversa entre profissionais de segurança, surgiu o relato de uma empresa que optou por um fluxo de onboarding leve, usando AWS Cognito sem MFA obrigatório e com verificação apenas por e-mail.
O problema surgiu em um endpoint de recuperação de conta, projetado para reativar usuários inativos por meio de token enviado por e-mail. O endpoint estava exposto no frontend, sem autenticação multifator, sem WAF e com rate limiting mínimo via API Gateway. Nenhum controle contextual — como IP, device ou comportamento anômalo — estava ativado.
Esse endpoint foi explorado por bots logo após uma campanha publicitária. Usando e-mails vazados em leaks anteriores, os atacantes conseguiram acessar contas inativas com senhas fracas e movimentar recursos vinculados.
Resultado: prejuízos financeiros na casa de milhões, desgaste reputacional e uma reformulação completa do fluxo de autenticação.
A contrapartida: projetos estratégicos foram despriorizados para refazer, com urgência, aquilo que já havia sido entregue como "pronto".
O time de produto teve problemas por meses com retenção de clientes.
O erro não foi apenas técnico — foi conceitual: segurança foi tratada como um pós-processo, e não como parte da arquitetura desde o início.
Confiança não se improvisa
Construir produtos digitais seguros não é só uma questão técnica. É uma decisão ética, estratégica e arrisco dizer madura.
Um produto que protege o cliente sem que ele perceba não está fazendo mágica — está assumindo responsabilidade. E isso é perigoso.
Principalidade não se sustenta com lock-in disfarçado. Ela exige transparência, auditabilidade e decisões de arquitetura que respeitam a autonomia do cliente, que garantam não só segurança, mas disponibilidade do serviço.
É isso que constrói a confiança de verdade — aquela que reduz churn, aumenta o NPS e protege a reputação da empresa em momentos críticos.
E há dados sólidos para reforçar essa abordagem:
- A Gartner aponta que práticas de Security by Design reduzem custos de retrabalho em até 30% e aumentam a resiliência desde o MVP.
- A Forrester indica que empresas que adotam modelagem de ameaças estruturada tiveram até 203% de ROI em três anos, com economia em engenharia e mitigação de falhas críticas.
O que está em jogo
Resumo executivo: segurança não é feature. É fundação.
Segurança, quando bem posicionada, não freia o produto — ela sustenta sua continuidade. O impacto não está apenas nos riscos evitados, mas nas decisões que deixam de gerar prejuízo, desgaste e refatoração.
Ações imediatas que mudam o jogo
- AppSec desde o discovery: segurança não pode ser anexada ao final do sprint.
- MFA progressivo e adaptativo: fricção só onde o risco exige.
- Risco como métrica de negócio: dashboards que falam com a estratégia, não só com o SOC.
Segurança é fundação — ou é desculpa depois
Se queremos liderar o mercado com produtos que inspiram confiança, precisamos tirar a segurança do porão técnico e trazê-la para a mesa de estratégia.
Isso significa:
- Incluir AppSec desde a concepção do produto;
- Medir risco com o mesmo rigor com que se mede conversão;
- Valorizar a segurança como pilar da experiência do cliente, e não como custo de fricção.
Porque, no fim das contas, segurança não é sobre impedir movimento — é sobre garantir que o cliente (ele mesmo, não um fraudador) saiba onde está pisando.
Fontes:
- Gartner (2023) — Security by Design: Reducing Rework and Increasing Resilience From MVP Onward https://www.gartner.com
- Forrester (2023) — The Total Economic Impact™ of Threat Modeling (IriusRisk) https://www.iriusrisk.com/forrester-tei-study
- IBM (2023) — Cost of a Data Breach Report 2023 https://www.ibm.com/reports/data-breach
- Zendesk (2023) — Customer Experience Trends Report https://www.zendesk.com/customer-experience-trends
- McKinsey (2023) — DevSecOps Productivity and Cost Study https://www.mckinsey.com/business-functions/mckinsey-digital
Quer debater mais sobre segurança como fundação? Me chama no LinkedIn. Adoro transformar caos em arquitetura segura.