Liveness e anti-spoofing em biometria: PAD, ataques de apresentação e critérios de projeto

Entenda liveness, anti-spoofing e PAD em biometria, métricas como APCER/BPCER/IAPAR e como especificar, testar e aceitar o recurso em controle de acesso.

Confira!

Liveness e anti-spoofing são mecanismos usados para reduzir o risco de um sistema biométrico aceitar uma apresentação artificial, reproduzida ou manipulada como se fosse uma característica genuína de uma pessoa presente. Em terminologia normativa, o conceito mais preciso é Presentation Attack Detection (PAD): detecção de ataques realizados no dispositivo de captura durante a apresentação e a coleta da característica biométrica.

Em controle de acesso, PAD não substitui FAR/FMR, FRR/FNMR, verificação 1:1, identificação 1:N, autenticação multifator, autorização nem a própria barreira física. Ele atua sobre uma ameaça diferente. Um matcher pode distinguir muito bem usuários genuínos de impostores de tentativa zero e, ainda assim, ser vulnerável a uma fotografia, reprodução em tela, máscara, réplica de impressão digital ou outro artefato apresentado ao sensor.

Por isso, especificar apenas “biometria com liveness” é insuficiente. Um projeto tecnicamente verificável precisa definir o modelo de ameaça, a modalidade biométrica, as condições de captura, os critérios de desempenho, as evidências de ensaio, o comportamento em falha e a forma de comprovação em FAT, SAT e comissionamento. O objetivo não é prometer inviolabilidade, mas controlar um risco mensurável sem degradar indevidamente a experiência dos usuários legítimos.

Liveness, anti-spoofing e PAD não são a mesma coisa

“Liveness” é o termo comercial e operacional mais difundido para indicar que a amostra aparenta provir de uma pessoa viva e presente. “Anti-spoofing” é uma expressão mais ampla, usada para mecanismos destinados a dificultar ou detectar falsificações. Já a família ISO/IEC 30107 utiliza Presentation Attack Detection porque o problema normativo não se limita a “provar vida”: o foco é detectar apresentações feitas ao dispositivo de captura com intenção de interferir no funcionamento do subsistema biométrico.

Essa distinção evita uma especificação imprecisa. Um algoritmo pode procurar movimento ocular, textura, profundidade, resposta espectral, propriedades do tecido ou outros indícios, mas o projeto não deve contratar o “truque” tecnológico. Deve contratar um desempenho verificável diante das classes de apresentação relevantes ao risco.

Termo	Uso típico	Limitação de interpretação
Liveness	Verificar sinais associados à presença viva	Pode sugerir escopo mais estreito do que o risco real
Anti-spoofing	Impedir ou detectar falsificação	Termo amplo, sem definir por si só método de teste e aceite
PAD	Detectar presentation attacks no ponto de captura	Não cobre todas as ameaças ao sistema biométrico

A ISO/IEC 30107-1:2023 delimita PAD aos ataques que ocorrem no dispositivo de captura durante a apresentação e coleta da característica biométrica. Injeção de dados depois do sensor, comprometimento de API, roubo de template, adulteração de banco de dados, violação de credencial administrativa ou bypass da controladora pertencem a outras superfícies de ataque. Isso significa que um produto com PAD robusto continua dependendo de arquitetura, cibersegurança e política de acesso adequadas.

O guia completo sobre sistemas de controle de acesso posiciona a biometria dentro da cadeia maior de identificação, autenticação, autorização, decisão e atuação. PAD é uma camada adicional nessa cadeia, não um substituto das demais.

Presentation attack acontece no ponto de captura

Uma presentation attack ocorre quando um atacante apresenta ao sensor uma característica ou um artefato com objetivo de produzir uma resposta indevida. Em reconhecimento facial, a classe de ameaça pode incluir apresentações bidimensionais ou tridimensionais. Em impressão digital, pode incluir materiais capazes de reproduzir padrões relevantes para o sensor. Outras modalidades possuem superfícies próprias.

O requisito de projeto não deve se transformar em um catálogo de receitas de ataque. O que interessa é estabelecer, em nível adequado de detalhe, quais famílias de apresentação são plausíveis para aquele ativo, qual a criticidade do acesso e quais evidências demonstrarão resistência compatível.

A figura mostra por que PAD e matching não devem ser confundidos. Uma apresentação pode ser genuína e não corresponder ao template; pode reproduzir características suficientes para o matcher, mas ser classificada como ataque pelo PAD; ou pode superar as duas camadas e ainda ser negada pela política de autorização.

FAR baixo não comprova resistência a spoofing

FMR/FAR e FNMR/FRR caracterizam erros de comparação ou de decisão biométrica sob condições definidas. Presentation attack é um problema adversarial: alguém tenta deliberadamente explorar o sensor e o processamento. Um equipamento com excelente FMR em tentativa de impostor sem artefato não está automaticamente protegido contra apresentações artificiais.

Por isso, documentos de engenharia devem separar ao menos três famílias de requisitos: qualidade de captura, desempenho do matching e desempenho de PAD. Somar tudo em uma frase como “biometria de alta precisão com anti-spoofing” torna o aceite subjetivo.

PAD passivo e ativo são escolhas de arquitetura

Soluções chamadas de PAD passivo tentam classificar a apresentação sem solicitar ao usuário uma ação adicional perceptível. Soluções ativas podem introduzir desafio, interação ou sequência de captura. Nenhuma abordagem é universalmente superior. A escolha interfere em tempo de passagem, acessibilidade, treinamento, ergonomia, taxa de rejeição e capacidade de operar em cenários de contingência.

O projeto deve avaliar a técnica como parte do sistema. Em um acesso de baixa vazão e alta criticidade, uma interação adicional pode ser aceitável. Em uma portaria com picos de entrada, a mesma interação pode provocar fila, pressão operacional e criação de exceções que enfraquecem o próprio controle.

Modelo de ameaça: o que o PAD precisa realmente detectar

O ponto de partida não deve ser “qual leitor biométrico comprar?”, mas qual ameaça precisa ser controlada e qual consequência existe se o mecanismo falhar. A mesma tecnologia pode ser suficiente para uma área administrativa e inadequada para uma sala crítica, laboratório, data center, ambiente industrial ou zona com segregação reforçada.

Um modelo de ameaça útil considera o valor do ativo, a atratividade do acesso, o perfil dos usuários, a possibilidade de obtenção de material biométrico, a exposição pública das características, a supervisão humana existente, a presença de outras credenciais e a consequência de uma falsa liberação.

A classificação de risco deve depois ser convertida em requisitos verificáveis na matriz funcional de controle de acesso: modalidade, modo de autenticação, necessidade de PAD, fatores adicionais, política de tentativas, comportamento em falha, registro de eventos e critérios de teste por ponto ou por classe de ponto.

Foto impressa é apenas o ataque mais óbvio

Restringir o ensaio a uma única fotografia impressa pode produzir falsa sensação de segurança. A avaliação precisa considerar classes representativas de apresentação compatíveis com a modalidade, com a técnica de captura e com o cenário de ameaça. A ISO/IEC 30107-3:2023 estrutura princípios de teste e reporte justamente para evitar que uma demonstração pontual seja confundida com caracterização ampla de desempenho.

Isso também significa que a especificação deve evitar frases absolutas como “imune a fotos, vídeos e máscaras”. O resultado depende de instrumento de ataque, qualidade de fabricação, condições ambientais, posição, distância, sensor, algoritmo, versão de software e parâmetros de decisão. A engenharia deve contratar evidência, não adjetivo.

Deepfake pode ou não ser presentation attack

Deepfake não é sinônimo de presentation attack. Se conteúdo sintético for apresentado fisicamente ou em uma tela ao sensor de captura, ele pode participar de uma apresentação adversarial. Se for injetado diretamente em um fluxo digital depois da captura, a ameaça já não está no mesmo domínio de PAD definido pela ISO/IEC 30107.

A consequência de projeto é relevante: exigir PAD e ignorar integridade do canal, autenticação de dispositivos, proteção de API e hardening do servidor deixa aberta uma superfície que o mecanismo biométrico não foi projetado para resolver.

1:1 e 1:N mudam a consequência do bypass

Na verificação 1:1, o sistema compara a amostra apresentada com uma identidade alegada ou previamente selecionada. Na identificação 1:N, procura uma correspondência em uma base de candidatos. As duas arquiteturas alteram risco, tempo de processamento, probabilidade agregada de correspondência e consequências de um bypass.

O conteúdo específico sobre biometria 1:1 x 1:N aprofunda essa diferença. Para PAD, a regra é simples: a proteção contra apresentação precisa ser analisada em conjunto com o modo de comparação que virá depois dela.

MFA reduz a dependência de uma única camada

Quando a criticidade exige maior robustez, biometria pode ser combinada com outro fator, credencial ou condição operacional. Autenticação multifator não torna PAD dispensável, mas reduz a dependência de uma única barreira. Da mesma forma, PAD forte não justifica enfraquecer autorização, anti-passback, dupla custódia ou segregação física quando esses controles fazem parte do conceito de segurança.

Uma arquitetura em camadas é preferível a confiar em um único indicador proprietário de “vivacidade”. O risco residual de cada camada deve ser entendido e combinado com as demais.

Métricas de PAD: APCER, BPCER, IAPAR e desempenho do usuário legítimo

PAD introduz sua própria matriz de erros. Um sistema pode ser agressivo na rejeição de ataques e, ao mesmo tempo, recusar pessoas legítimas com frequência inaceitável. Pode também preservar excelente experiência do usuário, mas deixar uma classe de apresentação adversarial passar em condições relevantes. O projeto precisa enxergar os dois lados.

APCER e BPCER caracterizam erros de classificação

Em avaliações de PAD, APCER está associado à proporção de apresentações de ataque classificadas de forma indevida como bona fide para a classe avaliada, enquanto BPCER caracteriza apresentações bona fide classificadas indevidamente como ataque. Elas não devem ser misturadas com FMR/FNMR, pois tratam uma etapa de decisão diferente.

Indicador	Pergunta de engenharia	Risco quando é alto
APCER	O PAD deixa apresentações de ataque da classe ensaiada passarem?	Bypass da camada de detecção
BPCER	O PAD rejeita usuários genuínos como se fossem ataques?	Fila, exceções, suporte e bypass operacional
FMR/FNMR	Como o matcher se comporta em comparação biométrica?	Falsa correspondência ou rejeição de usuário legítimo
IAPAR	Qual a aceitação de apresentações de ataque no contexto de autenticação avaliado?	Sucesso adversarial no sistema sob a metodologia adotada

O valor técnico está menos em procurar um “número mágico” e mais em exigir metodologia, população, condições, instrumentos de apresentação, número de tentativas, versão do produto, configuração e forma de cálculo. Sem essa rastreabilidade, dois percentuais de fornecedores diferentes podem não ser comparáveis.

NIST é referência útil, não limite universal para acesso físico

O NIST SP 800-63B-4, publicado em julho de 2025, trata autenticação de identidades digitais em sistemas governamentais norte-americanos conectados em rede. Nesse contexto, exige PAD para reconhecimento facial, recomenda PAD para impressão digital e íris e indica, para testes de implantação, demonstração de IAPAR inferior a 0,07.

Esses requisitos são valiosos como referência contemporânea de engenharia e demonstram a separação entre desempenho biométrico e resistência a presentation attack. Porém, não devem ser copiados automaticamente como requisito legal ou limiar universal de um sistema físico brasileiro. O critério de aceite do controle de acesso deve nascer da análise de risco, da aplicação, da tecnologia e das obrigações específicas do empreendimento.

Threshold de matching e threshold de PAD precisam de governança

Algumas soluções permitem ajustar sensibilidade de matching, PAD ou ambos. Mudar threshold para “fazer a catraca andar” pode reduzir rejeições e simultaneamente alterar risco. Por isso, parâmetros críticos precisam ser definidos, documentados, protegidos por perfil administrativo e submetidos a gestão de mudanças.

O Data Book de comissionamento deve registrar configuração aprovada, versões, parâmetros relevantes, evidência dos testes e baseline de aceite. Sem baseline, uma alteração posterior pode degradar o sistema sem que a organização consiga demonstrar quando ou por que o desempenho mudou.

Projeto físico e operacional: sensor, iluminação, fluxo e acessibilidade

O desempenho de PAD não existe fora do ambiente. Câmera, lente, resolução efetiva, iluminadores, distância, ângulo, altura de instalação, fundo da cena, exposição solar, reflexos, temperatura, sujeira, umidade, vibração e posição do usuário podem alterar captura e classificação. Em impressão digital, condição da pele, contaminantes e características do sensor também interferem na experiência.

Por isso, a especificação deve conectar requisito de segurança ao projeto físico do ponto de acesso. Não basta aprovar um terminal em bancada e presumir que o comportamento será idêntico instalado próximo a uma fachada envidraçada, em área externa ou em fluxo industrial.

PAD precisa ser compatível com a vazão esperada

A segurança que não cabe na operação tende a gerar exceções. Se cada tentativa exigir repetição, reposicionamento ou intervenção do vigilante, a fila nos horários de pico pode levar a portas mantidas abertas, autenticações por terceiros, criação de atalhos ou migração para um modo menos seguro.

O projeto deve estabelecer a vazão de referência, tempo de transação esperado, taxa de retentativa, tratamento de falhas e procedimento para usuários que não conseguem completar o fluxo. Esses critérios precisam ser testados com população representativa, não apenas com a equipe técnica que instalou o sistema.

Acessibilidade faz parte do critério de aceite

Altura do equipamento, campo de captura, necessidade de aproximação, gestos, tempo de reação e instruções na interface podem criar barreiras para determinados usuários. Um projeto de biometria precisa prever alternativas operacionais e formas de autenticação compatíveis com o ambiente e com as exigências de acessibilidade aplicáveis.

A alternativa não deve virar um bypass sem governança. Se uma pessoa não puder usar a modalidade principal, o fluxo alternativo precisa manter identificação, autorização, rastreabilidade e nível de controle coerente com o risco.

Iluminação e geometria precisam ser ensaiadas no local

Para reconhecimento facial, a condição luminosa pode afetar tanto matching quanto PAD. Contraluz, baixa iluminância, luz solar variável ou reflexos podem alterar características extraídas pelo sensor. Se o PAD depender de múltiplos canais ópticos, a arquitetura física e a janela de operação também precisam ser compatíveis.

O SAT deve reproduzir situações reais previsíveis: horários diferentes, usuários com características variadas, acessórios permitidos, distâncias de aproximação e condições de fluxo. O objetivo não é “torturar” o produto com cenários impossíveis, mas demonstrar que o sistema funciona dentro da envelope operacional contratado.

Enrollment, templates, LGPD e cibersegurança

Enrollment e PAD resolvem problemas diferentes, mas se encontram em um ponto crítico. Se a identidade ou o template inicial for cadastrado de forma incorreta, todo o restante do ciclo pode operar exatamente como projetado e ainda assim proteger uma identidade falsa ou um vínculo indevido.

PAD no enrollment pode ser mais crítico do que no uso posterior

O cadastro deve ter governança sobre identidade, operador, estação autorizada, qualidade da amostra, duplicidade, aprovação e trilha de auditoria. Quando o modelo de ameaça justificar, mecanismos de PAD no enrollment ajudam a reduzir o risco de cadastrar uma apresentação adversarial como referência legítima.

Também é preciso definir revogação e recadastramento. Template biométrico não é uma senha que pode ser simplesmente trocada de característica física; comprometimentos e mudanças de fornecedor exigem estratégia de ciclo de vida.

Proteção do template continua indispensável

PAD atua antes ou durante a captura. Depois disso, representações biométricas trafegam, são processadas e podem ser armazenadas. Criptografia em trânsito e repouso, segregação de chaves, controle de acesso administrativo, hardening, logging, backup, retenção e descarte pertencem a outra camada de segurança e permanecem indispensáveis.

Quando houver integrações com sistemas corporativos, o artigo sobre API, webhooks e middleware em controle de acesso mostra por que autenticação de serviço, autorização, integridade e tratamento de eventos precisam ser projetados além do terminal biométrico.

LGPD exige governança proporcional ao caráter sensível do dado

Dados biométricos vinculados a uma pessoa natural são dados pessoais sensíveis no contexto da LGPD. Isso aumenta a necessidade de finalidade definida, base jurídica aplicável, necessidade, segurança, controle de acesso, retenção coerente e governança do tratamento. A ANPD também destaca riscos de privacidade, proteção de dados e eventuais impactos discriminatórios associados à biometria e ao reconhecimento facial.

A decisão de usar biometria, portanto, não deve ser tomada apenas porque o equipamento oferece esse recurso. É necessário justificar a função dentro do controle de acesso e limitar coleta e tratamento ao que o caso de uso requer.

PAD baseado em software ou IA exige gestão de versão

Uma atualização de firmware, modelo, biblioteca ou backend pode alterar a classificação sem mudar o hardware visível. O contrato e o plano de manutenção precisam definir como mudanças de versão serão avaliadas, quando exigem regressão de testes e como retornar à configuração anterior se o desempenho se deteriorar.

Eventos de PAD também devem ser diferenciados de simples falhas de matching. Essa granularidade melhora investigação, permite identificar tendências e evita interpretar repetidas tentativas adversariais como mera “biometria ruim”. Integração com VMS pode enriquecer a investigação, mas não melhora por si só a capacidade algorítmica de PAD.

Operação offline e falha precisam de comportamento explícito

Alguns terminais executam matching e PAD localmente; outros dependem de serviços centrais para parte da análise. O projeto deve esclarecer o que acontece quando rede, servidor, licença ou serviço de análise fica indisponível. Continuar liberando com funcionalidade degradada pode reduzir segurança; bloquear tudo pode comprometer continuidade operacional ou rotas de emergência.

Essa decisão não pode ficar escondida no comportamento default do fabricante. Deve ser especificada por classe de porta, alinhada à filosofia de operação e testada em contingência.

Como especificar e contratar PAD sem depender de promessas comerciais

Uma contratação robusta transforma necessidade em requisito verificável. “Possuir liveness” não define o que será aceito, quais evidências serão apresentadas nem como comparar proponentes. A especificação deve evitar tanto direcionamento a uma implementação proprietária quanto generalidade que torne qualquer declaração comercial suficiente.

O serviço de engenharia começa pela definição do objeto: sistema biométrico para determinado conjunto de pontos, com classes de criticidade, modalidades, políticas de autenticação e integração. Depois vêm requisitos funcionais e de desempenho, condições de ambiente, evidências prévias, testes de fornecimento e critérios de aceite.

O que exigir na especificação técnica

Sempre que aplicável, a documentação deve estabelecer:

• modalidade biométrica e modo de operação 1:1 ou 1:N;
• pontos ou classes de pontos em que PAD é requerido;
• modelo de ameaça e classes de apresentação que orientam a avaliação;
• métricas solicitadas e condições sob as quais serão reportadas;
• evidências laboratoriais ou relatórios de teste aplicáveis à versão ofertada;
• condições mínimas de captura e instalação;
• capacidade, latência, vazão e tratamento de retentativas;
• comportamento diante de indisponibilidade, falha de PAD e operação offline;
• requisitos de logs, sincronismo de tempo, exportação de eventos e integração;
• requisitos de proteção de template e segurança das comunicações;
• FAT, SAT, testes de regressão e documentação de aceite;
• política de atualização, manutenção e gestão de mudanças.

A lista deve ser calibrada ao risco. Nem todo acesso exige o mesmo nível de evidência, mas pontos críticos não deveriam depender de um checkbox que ninguém consegue testar.

Certificação e relatório de laboratório precisam ser lidos criticamente

Uma declaração de conformidade à ISO/IEC 30107-3 não deve ser interpretada como certificação genérica de invulnerabilidade. É necessário verificar escopo, modalidade, produto, versão, configuração, classes de ataque avaliadas, condições, laboratório, métricas e resultados reportados.

A ISO/IEC 30107-3:2023 estabelece princípios e métodos para avaliação e reporte de mecanismos de PAD; não padroniza um algoritmo específico nem realiza avaliação geral de segurança do sistema. Essa delimitação é essencial para procurement: um relatório válido pode responder apenas a uma parte da pergunta de engenharia.

Equalização técnica deve comparar evidência, não nomenclatura

Dois fornecedores podem chamar recursos muito diferentes de “liveness avançado”. A equalização precisa colocar lado a lado requisitos, evidências, lacunas, condições e desvios. Quando faltarem dados, o resultado deve ser “não demonstrado” ou “a esclarecer”, e não uma aprovação por inferência.

Esse raciocínio se conecta à requisição técnica para Procurement: requisitos de PAD precisam chegar ao processo de compra em formato que permita comparar propostas e manter rastreabilidade até o aceite.

Escopo de contratação recomendado

Para contratar apoio de engenharia nesse tema, o objeto pode abranger diagnóstico de risco, definição de arquitetura, especificação técnica, matriz funcional, revisão das evidências de fornecedor, equalização técnica, FAT, SAT, comissionamento e documentação final. As fronteiras devem ser explícitas: quem fornece instrumentos e amostras de ensaio, quem prepara ambiente, quem executa testes, quem registra evidências e quem possui autoridade para aceitar desvios.

Os entregáveis podem incluir memorial de critérios, matriz de requisitos, especificação técnica, matriz de pontos, protocolo de testes, relatório de FAT/SAT, lista de pendências, baseline de configuração e Data Book. A medição do serviço deve se apoiar nesses produtos e marcos, não apenas em presença em reunião ou número de horas sem resultado verificável.

FAT, SAT, comissionamento e critérios de aceite

PAD só deixa de ser promessa quando é testado de forma rastreável. O plano de testes deve distinguir aquilo que pode ser validado em ambiente controlado do que depende da instalação definitiva. FAT e SAT têm funções complementares.

FAT deve comprovar requisitos antes da mobilização definitiva

No FAT, a equipe pode verificar versão de hardware e software, parâmetros, interfaces, logs, políticas, classes de apresentação previstas, comportamento diante de tentativas bona fide e cenários de falha controlados. O protocolo precisa identificar claramente quais resultados são objetivos e quais observações demandam reteste no site.

O objetivo não é reproduzir todos os riscos do campo dentro de laboratório, mas evitar que problemas básicos sejam descobertos somente depois da implantação. Evidências devem incluir identificação do item ensaiado, configuração, data, responsáveis, resultados e não conformidades.

SAT valida o ambiente definitivo

No SAT, entram geometria, iluminação, posição, rede, controladora, fechadura ou catraca, integração, base de usuários, fluxo, políticas de acesso, contingências e experiência real. Um PAD que funciona em bancada pode apresentar comportamento diferente no local por causa das condições de captura.

O artigo sobre comissionamento de sistemas de controle de acesso conforme a IEC 60839 detalha a disciplina de testes, evidências e aceite aplicada ao sistema completo.

Testar ataque sem testar usuário genuíno produz uma visão incompleta

Uma campanha focada apenas em bloquear apresentação artificial pode ocultar BPCER elevado, repetição de tentativas e degradação da operação. O protocolo precisa medir também sucesso de usuários legítimos, tempo de transação, retentativas e comportamento em grupos e condições relevantes ao uso.

Se ajustes de threshold forem necessários, a alteração deve ser registrada e os testes pertinentes repetidos. Aceitar depois de “regular até funcionar” sem conservar a configuração final inviabiliza auditoria futura.

Critérios de aceite devem ser definidos antes do teste

O fornecedor não deveria descobrir no dia do SAT qual será o limiar de aceitação. O protocolo deve indicar previamente requisitos, amostragem, condições, número de tentativas quando aplicável, tolerâncias, tratamento de resultados inconclusivos, classificação de não conformidades e regra de reteste.

Também é recomendável separar pendências críticas, que impedem liberação, de itens menores que podem ser tratados em punch list com prazo e responsabilidade definidos.

Operação assistida consolida o baseline

Após a entrada em operação, um período assistido pode revelar situações que o SAT não capturou: picos de fluxo, iluminação sazonal, acessórios, comportamento de grupos de usuários, indisponibilidades intermitentes e procedimentos de exceção. O objetivo não é reabrir indefinidamente o aceite, mas confirmar a estabilidade e ajustar parâmetros sob governança.

Operação, manutenção e mudança

A segurança de PAD pode se degradar sem uma falha física evidente. Mudanças de firmware, reposicionamento do terminal, alteração de iluminação, substituição de câmera, limpeza inadequada, nova película, mudança de algoritmo ou configuração podem alterar o desempenho. Por isso, manutenção precisa preservar a função, não apenas verificar se o equipamento liga.

O plano de manutenção de sistemas de controle de acesso deve incluir inspeções e testes proporcionais à criticidade, além de registro de intervenções e alterações de configuração.

Indicadores operacionais ajudam a detectar degradação

Taxa de tentativas repetidas, rejeições bona fide, eventos de PAD, chamados de suporte, tempos de passagem e exceções manuais podem revelar degradação antes que ela se transforme em bypass permanente. Tendências precisam ser analisadas por ponto, período e versão, preservando as restrições de tratamento de dados aplicáveis.

Um aumento de rejeições depois de atualização de software, por exemplo, deve acionar investigação técnica. Da mesma forma, queda súbita de eventos de PAD não significa necessariamente melhora: pode indicar recurso desativado, falha de logging ou mudança de parâmetro.

Manutenção física pode alterar a captura

Reposicionar terminal, trocar suporte, alterar altura ou instalar nova iluminação parece intervenção simples, mas pode mudar o envelope de captura. Pontos críticos devem ter critérios de reinspeção e, quando necessário, reteste de funcionalidades biométricas depois de alterações relevantes.

Obsolescência deve ser tratada antes do fim do suporte

PAD frequentemente depende de software, modelos e bibliotecas que evoluem com ameaças e com a plataforma do fabricante. O plano de ciclo de vida precisa considerar fim de suporte, compatibilidade de versões, migração de templates, disponibilidade de atualizações e estratégia para substituição sem perda de governança.

Checklist de projeto para liveness e anti-spoofing

Antes de aprovar uma solução biométrica com PAD, a equipe deve conseguir responder de forma documentada às perguntas abaixo.

1. Qual é a modalidade biométrica e o modo de comparação, 1:1 ou 1:N?
2. Quais pontos de acesso exigem PAD e por qual risco?
3. Qual modelo de ameaça orienta as classes de apresentação avaliadas?
4. O recurso ofertado é PAD mensurável ou apenas uma denominação comercial de “liveness”?
5. Quais métricas são reportadas e em quais condições de teste?
6. A evidência apresentada corresponde ao produto, versão e configuração ofertados?
7. Como o sistema equilibra rejeição de ataques e rejeição de usuários bona fide?
8. Quais condições ambientais e geométricas limitam o desempenho?
9. Qual vazão precisa ser mantida e como são tratadas retentativas?
10. Existe fluxo acessível e governado para quem não consegue usar a modalidade principal?
11. Como enrollment, revogação e recadastramento são controlados?
12. Como templates e comunicações são protegidos?
13. Quais eventos são registrados e como diferenciar PAD, matching e falhas operacionais?
14. O que acontece em operação offline, falha de servidor ou indisponibilidade do recurso de PAD?
15. FAT e SAT possuem protocolos e critérios de aceite previamente definidos?
16. A configuração final fica registrada no Data Book?
17. Atualizações de versão exigem análise e testes de regressão?
18. Manutenção e operação possuem indicadores para detectar degradação?
19. O contrato define responsabilidades, evidências, retestes e fechamento de pendências?
20. Existe uma alternativa de autenticação compatível com o risco para exceções legítimas?

Se várias dessas respostas dependem de “veremos durante a instalação”, o risco ainda não foi transformado em requisito de engenharia. O melhor momento para corrigir essa lacuna é antes da contratação e da implantação.

Considerações finais

Liveness e anti-spoofing devem ser tratados como um problema de Presentation Attack Detection, e não como checkbox de produto. O objetivo é reduzir a probabilidade de uma apresentação artificial ser classificada como bona fide sem transformar usuários legítimos em exceção operacional constante.

A engenharia precisa definir ameaça, métricas, condições, comportamento em falha, evidências e critérios de aceite; depois comprovar esses requisitos em FAT, SAT, comissionamento e operação assistida. A família ISO/IEC 30107 fornece a estrutura conceitual e de teste para PAD, enquanto referenciais como o NIST SP 800-63B-4 mostram como métricas de presentation attack podem ser incorporadas a políticas contemporâneas de autenticação dentro de seu contexto específico.

PAD forte é uma camada importante, mas continua dependendo de matching adequado, proteção de dados, cibersegurança, autorização, barreira física, manutenção e gestão de mudanças para formar um sistema de controle de acesso robusto e auditável.

Referências técnicas

[1] ISO. ISO/IEC 30107-1:2023 — Information technology — Biometric presentation attack detection — Part 1: Framework. Disponível em: https://www.iso.org/standard/83828.html.

[2] ISO. ISO/IEC 30107-3:2023 — Information technology — Biometric presentation attack detection — Part 3: Testing and reporting. Disponível em: https://www.iso.org/standard/79520.html.

[3] NIST. SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management. July 2025. Disponível em: https://csrc.nist.gov/pubs/sp/800/63/b/4/final.

[4] ANPD. Radar Tecnológico nº 2 — Biometria e Reconhecimento Facial. Brasília, 2024. Disponível em: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/documentos-tecnicos-orientativos/radar-tecnologico-biometria-anpd.pdf/@@display-file/file.

[5] SUPREMA. Curso de Controle de Acesso e Biometria. Seções sobre detecção de falsas apresentações, multiespectro e autenticação biométrica. Material técnico consultado na base interna A3A Engenharia.

Perguntas frequentes

Qual é a diferença entre liveness, anti-spoofing e PAD?

Liveness costuma indicar mecanismos que buscam sinais associados a uma pessoa viva e presente. Anti-spoofing é um termo amplo para técnicas contra falsificação. PAD, ou Presentation Attack Detection, é o conceito normativo usado pela ISO/IEC 30107 para detectar ataques apresentados ao dispositivo de captura durante a coleta biométrica.

Um FAR ou FMR baixo significa que a biometria é resistente a spoofing?

Não. FAR/FMR caracterizam erros de comparação ou decisão biométrica em condições definidas. Presentation attacks são tentativas adversariais no ponto de captura e precisam de avaliação específica de PAD.

APCER e BPCER são as mesmas métricas que FAR e FRR?

Não. APCER e BPCER caracterizam erros de classificação do mecanismo de PAD para apresentações de ataque e bona fide. FAR/FMR e FRR/FNMR pertencem ao desempenho da comparação ou decisão biométrica. As duas camadas devem ser especificadas separadamente.

PAD é obrigatório em todo sistema de reconhecimento facial?

Não existe uma regra universal que torne PAD obrigatório em todo controle de acesso físico. A necessidade deve ser definida pelo risco, pela aplicação e pelos requisitos aplicáveis. No contexto específico do NIST SP 800-63B-4 para autenticação de identidade digital, PAD é exigido para reconhecimento facial.

Como avaliar um fornecedor que declara possuir liveness?

Peça evidências vinculadas ao produto, versão e configuração ofertados; verifique metodologia, classes de apresentação, métricas, condições de teste e escopo do relatório; depois transforme os requisitos relevantes em FAT, SAT e critérios de aceite rastreáveis.

O SAT deve testar liveness e PAD no ambiente real?

Sim, quando PAD fizer parte do requisito do sistema. O SAT deve verificar o comportamento na instalação definitiva, incluindo condições de iluminação, geometria, fluxo, usuários bona fide, integrações, contingências e classes de apresentação previstas no protocolo.

A LGPD proíbe o uso de biometria em controle de acesso?

Não de forma geral. Dados biométricos vinculados a uma pessoa natural são dados pessoais sensíveis e seu tratamento exige enquadramento jurídico, finalidade, necessidade, segurança e governança compatíveis com a LGPD e com o caso de uso.

Materiais técnicos complementares

Serviços relacionados

• Projeto de Controle de Acesso: arquitetura, dispositivos, integração e especificação
• Design Review em Projetos de Engenharia: revisão técnica, interfaces e maturidade do projeto
• Procurement Técnico: especificação, equalização, fornecedores e apoio à contratação
• Comissionamento de Engenharia: planejamento, testes, prontidão e handover

Conteúdos principais sobre o tema

• Sistema de Controle de Acesso: tipos, tecnologias, normas e projeto
• ABNT NBR IEC 60839: requisitos para sistemas de controle de acesso
• Matriz funcional de controle de acesso: como especificar cada ponto
• Comissionamento de sistemas de controle de acesso conforme a IEC 60839
• Biometria 1:1 x 1:N: verificação, identificação e critérios de projeto

Conteúdos técnicos correlatos

• API, webhooks e middleware em controle de acesso: integração, segurança e arquitetura
• Manutenção de sistemas de controle de acesso: plano, inspeções, testes e evidências
• Dupla custódia no controle de acesso: regra de duas pessoas, dual access e dual occupancy
• Tailgating e anti-tailgating em controle de acesso: riscos, detecção e critérios de projeto