Como projetar autenticação multifator no controle de acesso físico combinando cartão, PIN e biometria, com risco, contingência, integração e critérios de aceite.
Confira!
Autenticação multifator no controle de acesso físico é a exigência de duas ou mais evidências independentes antes de autorizar uma passagem. Em uma porta, catraca, eclusa ou outro ponto controlado, isso pode significar combinar cartão e PIN, credencial móvel e biometria, cartão e biometria ou outra composição coerente com o risco. O objetivo não é simplesmente adicionar uma segunda etapa: é reduzir a chance de que uma única credencial perdida, copiada, compartilhada ou comprometida seja suficiente para liberar uma área crítica.
No projeto de um EACS — Electronic Access Control System — MFA precisa ser tratado como requisito de engenharia. É necessário definir onde dois fatores são realmente necessários, quais combinações são aceitas, em que ordem são apresentados, como o sistema se comporta offline, como ficam fluxo e acessibilidade, quais exceções são permitidas, quais eventos devem ser registrados e como tudo será comprovado no FAT, SAT e comissionamento. Aplicar MFA sem essa arquitetura pode produzir filas, falsos rejeites, bypass operacional e contingências que enfraquecem justamente o controle que se pretendia reforçar.
A IEC 60839-11 fornece a estrutura funcional do controle de acesso eletrônico físico, enquanto referências de identidade digital como o NIST SP 800-63B ajudam a organizar o conceito de fatores independentes. Essas fontes não são intercambiáveis: autenticação de login e autenticação em uma porta têm requisitos operacionais diferentes. O projeto físico precisa acrescentar controladoras, leitores, atuadores, sensores de porta, continuidade, emergência, anti-passback, capacidade de passagem, integração e evidências de campo.
O que é MFA em um sistema de controle de acesso físico
Um ponto de acesso normalmente executa uma cadeia: recebe uma solicitação de entrada, identifica ou verifica uma pessoa, consulta regras de autorização, comanda o ponto físico e registra o resultado. MFA aparece quando a política exige mais de uma categoria de evidência antes de considerar a autenticação suficiente.
As três categorias clássicas são:
- algo que a pessoa possui, como cartão inteligente, credencial móvel ou token;
- algo que a pessoa sabe, como PIN ou outro segredo memorizado;
- algo que a pessoa é, como impressão digital, face ou palma, quando a biometria for apropriada ao contexto.
Dois meios da mesma categoria não criam necessariamente multifator. Dois cartões continuam sendo duas evidências de posse; duas perguntas memorizadas continuam sendo conhecimento. O ganho nasce da independência entre fatores e da dificuldade de comprometer ambos pelo mesmo vetor.
Identificação, autenticação e autorização são decisões diferentes
A matrícula de um usuário pode apenas localizar um cadastro. O cartão pode identificar a pessoa ou funcionar como autenticador, dependendo da arquitetura. A biometria pode verificar uma identidade já indicada por outra credencial, ou realizar identificação 1:N em uma galeria. E mesmo depois de a identidade ser autenticada, a pessoa ainda pode não estar autorizada naquela área, horário ou estado operacional.
Essa separação precisa aparecer no modelo de eventos. Uma negação por PIN incorreto não é igual a uma negação por horário, anti-passback ou ausência de privilégio. Misturar tudo em “acesso negado” dificulta investigação, manutenção e auditoria.
Em áreas críticas, a decisão de exigir dois fatores precisa nascer da análise de risco, capacidade de fluxo e comportamento em falha — não do catálogo do leitor.
MFA físico não é a mesma coisa que MFA de login
O NIST SP 800-63B-4 organiza autenticação digital em fatores e níveis de garantia. O conceito de exigir fatores distintos é útil ao controle físico, mas um EACS precisa administrar variáveis que não existem em um login comum.
Em um acesso físico existem barreiras mecânicas, tempo de abertura, passagem, sensor de posição, porta mantida aberta, porta forçada, emergência, perda de alimentação, fluxo de pessoas, rotas acessíveis e risco de tailgating. Uma política que funciona bem em uma aplicação web pode ser inviável em uma catraca durante a troca de turno.
O NIST SP 800-116 Rev. 1, voltado ao uso de credenciais PIV em acesso a instalações, reforça uma ideia particularmente útil: o mecanismo de autenticação deve ser escolhido segundo risco e nível de proteção, e não aplicado de forma uniforme a qualquer porta.
Quando exigir dois fatores
O critério principal deve ser o risco do acesso indevido, combinado com impacto operacional. Áreas de baixa criticidade podem ser adequadamente controladas por um fator robusto; áreas de alta criticidade podem justificar dois fatores, dupla custódia ou outras regras adicionais.
| Contexto | Exemplo de risco | Estratégia possível |
| Área administrativa comum | impacto limitado | um fator forte e política de autorização |
| Laboratório, arquivo restrito ou CPD secundário | informação ou ativo sensível | MFA por perfil, horário ou área |
| Sala-cofre, data center crítico ou processo sensível | alto impacto operacional ou patrimonial | MFA obrigatório e exceção governada |
| Área com segregação de funções | risco de ação individual | MFA combinado com dupla custódia |
| Acesso temporário de terceiro | vínculo transitório | credencial com validade + segundo fator conforme risco |
A matriz acima é apenas um modelo de raciocínio. O projeto deve relacionar cada área ao risco e definir o requisito em uma matriz de acesso. Escrever apenas que “o sistema deve suportar MFA” comprova capacidade de produto, mas não determina onde a função será aplicada.
Combinações comuns e seus efeitos de engenharia
Cartão + PIN
Cartão e PIN combinam posse e conhecimento. É uma arquitetura madura, mas exige política para tamanho do PIN, número de tentativas, bloqueio, recuperação, observação visual, troca de segredo e proteção administrativa.
O PIN deve ser individual. PIN coletivo por setor reduz responsabilização e cria um segredo difícil de revogar seletivamente. Logs não devem registrar o valor do PIN; devem registrar apenas que o fator foi solicitado, aceito ou rejeitado.
Em acessos de alto fluxo, a digitação aumenta o tempo de transação. O projeto deve medir esse impacto e evitar que o desconforto operacional gere atalhos como manter portas abertas em horários de pico.
Cartão + biometria
A credencial pode indicar a identidade e a biometria verificar se a pessoa que apresenta o cartão é o titular. Isso permite uma arquitetura 1:1 eficiente, porque o sistema não precisa procurar a pessoa em toda a galeria.
A biometria adiciona requisitos próprios: qualidade do enrollment, FAR, FRR, failure to acquire, liveness/PAD quando necessário, privacidade, acessibilidade e alternativa para pessoas que não conseguem usar a modalidade. O desempenho do segundo fator precisa ser testado com a população real.
Credencial móvel + autenticação do dispositivo
Um smartphone pode proteger a credencial por biometria ou PIN local. Isso aumenta a resistência ao uso por terceiros, mas o projeto precisa documentar onde o segundo fator é realmente validado. O terminal de acesso pode receber apenas uma credencial já liberada pelo dispositivo, sem conhecer a autenticação local realizada no telefone.
Essa arquitetura pode ser adequada, desde que o modelo de ameaça, as evidências e a responsabilidade de cada camada sejam compreendidos. Não se deve assumir que “celular com biometria” significa automaticamente MFA no EACS.
PIN + biometria
Essa composição combina conhecimento e inerência sem necessariamente usar cartão. É tecnicamente possível, mas é preciso distinguir um identificador digitado de um segredo. Se a pessoa informa uma matrícula pública para localizar seu template, essa matrícula não deve ser contada como fator de conhecimento.
Cartão + PIN + biometria
Três etapas podem ser justificadas em áreas muito críticas, mas o custo operacional cresce rapidamente. Mais fatores não significam automaticamente maior segurança se o processo induzir bypass, se as contingências forem frágeis ou se a equipe não conseguir sustentar a política.
Ordem dos fatores e experiência do usuário
A sequência altera desempenho e diagnóstico. Em cartão + biometria, apresentar o cartão primeiro permite localizar o template correto e executar verificação 1:1. Em cartão + PIN, a credencial pode indicar qual política e qual PIN validar. Em outras arquiteturas, os fatores são coletados antes de qualquer decisão.
O terminal precisa dar feedback claro. O usuário deve saber se o sistema espera cartão, PIN, biometria, nova tentativa ou contato com a portaria. Uma mensagem genérica de “erro” aumenta repetição e chamados.
Também é importante limitar o quanto o feedback revela. Informar detalhadamente a um usuário não autorizado qual fator falhou pode ajudar tentativa maliciosa. O projeto deve equilibrar usabilidade e exposição de informação.
Capacidade, latência e formação de filas
MFA adiciona tempo por transação. O impacto real não pode ser estimado apenas pelo tempo de processamento anunciado pelo fabricante.
O ciclo completo pode incluir:
- aproximação ao ponto;
- apresentação do primeiro fator;
- feedback do terminal;
- apresentação do segundo fator;
- processamento local ou central;
- autorização;
- comando da barreira;
- abertura;
- passagem;
- rearme;
- repetição em caso de falha.
Em uma catraca, segundos adicionais multiplicados pelo pico de entrada podem produzir uma fila significativa. Em áreas industriais, isso pode impactar troca de turno. Em recepções, pode transferir pressão operacional para a portaria.
O projeto deve trabalhar com throughput de serviço, não apenas tempo nominal. Deve considerar percentis de latência, tentativas adicionais e usuários que necessitam assistência.
Arquitetura local, centralizada e híbrida
MFA conecta credenciais, leitores, controladoras, servidores e, em ambientes enterprise, diretórios e IAM. Uma revisão de interfaces antes da implantação reduz incompatibilidades e bypass.
A decisão de MFA pode ocorrer na controladora, em terminal inteligente, no servidor central ou em uma combinação dessas camadas.
Decisão local
Regras e dados suficientes ficam próximos ao ponto de acesso. A vantagem é a continuidade durante perda de comunicação. Em contrapartida, aumenta a necessidade de proteger armazenamento local, sincronizar alterações e garantir revogação nos dispositivos distribuídos.
Decisão centralizada
O servidor processa a lógica. A política pode ser mais rica e mais fácil de administrar, mas a porta passa a depender de rede, servidor, serviços de identidade e latência. O comportamento durante falha precisa ser definido.
Arquitetura híbrida
Parte das regras permanece local e parte é coordenada centralmente. É comum em sistemas corporativos distribuídos. O projeto deve listar explicitamente o que continua funcionando quando cada dependência falha.
Modo offline não pode ser uma incógnita
Uma das maiores fragilidades em MFA surge quando a rede cai. Se a porta normalmente exige cartão + biometria, o que acontece quando o terminal perde acesso ao servidor biométrico? Se cartão + PIN depende de um diretório externo, qual regra permanece localmente?
O projeto precisa definir estados de contingência:
- manter dois fatores localmente;
- negar o acesso até restauração;
- aceitar um modo degradado para grupos específicos;
- exigir autorização de supervisor;
- utilizar credencial de emergência controlada.
Qualquer relaxamento deve ter prazo, responsável e log. Caso contrário, o “modo de contingência” pode virar uma configuração permanente mais fraca.
Falhas de fator e política de exceção
Falhas previsíveis precisam ser tratadas antes da implantação:
- cartão perdido ou danificado;
- PIN esquecido ou bloqueado;
- sensor biométrico indisponível;
- smartphone sem bateria;
- failure to acquire;
- usuário incapaz de fornecer a modalidade biométrica;
- base local desatualizada;
- servidor de identidade indisponível;
- controladora isolada;
- erro de relógio ou sincronismo.
A exceção deve preservar equivalência de segurança. Se uma área crítica exige dois fatores em condição normal, substituir automaticamente por um único cartão sempre que houver problema transforma a falha em vetor de bypass.
MFA, dupla custódia e coação não são a mesma coisa
MFA valida múltiplos fatores de uma mesma identidade. Dupla custódia exige duas identidades distintas. Coação ou duress é uma função para indicar que o acesso está ocorrendo sob ameaça. Os controles podem coexistir.
Uma sala de alta criticidade pode exigir cartão + PIN de cada pessoa e ainda exigir que duas pessoas autorizadas estejam presentes. A lógica precisa ser definida como máquina de estados para que integrador e fiscalização não implementem interpretações diferentes.
Integração com anti-passback, horários e níveis de acesso
Autenticar corretamente não significa autorizar. Depois de validar os fatores, o EACS ainda pode negar o acesso por:
- horário;
- calendário;
- área;
- perfil;
- anti-passback;
- lotação;
- lockdown;
- credencial suspensa;
- vínculo expirado;
- falta de autorização temporária.
A decisão final deve registrar a causa. Isso permite distinguir problemas de autenticação de problemas de política.
Integração com RH, diretórios e IAM
Em ambientes enterprise, o EACS pode receber identidade e atributos de fontes corporativas. RH pode ser a fonte de vínculo; um diretório pode fornecer identificadores; um IAM pode orquestrar grupos e ciclo de vida. MFA físico passa então a fazer parte de uma cadeia maior de identidade.
Mudança de função, transferência de unidade, afastamento e desligamento precisam repercutir nas permissões físicas. A integração deve definir qual sistema é fonte de verdade para cada atributo, qual o SLA de propagação e como divergências são reconciliadas.
Essa automação reduz trabalho manual, mas cria dependências. Um mapeamento incorreto de grupo pode conceder acesso em massa; uma falha de integração pode impedir revogações. Por isso, integrações precisam de logs, monitoramento e testes negativos.
Logs e evidências de uma transação multifator
Um log útil deve permitir reconstruir a decisão sem armazenar segredos desnecessários. Campos típicos incluem:
- identificador do usuário;
- ponto de acesso;
- data e hora sincronizadas;
- política aplicada;
- fatores solicitados;
- resultado de cada etapa;
- condição online ou offline;
- regra final de autorização;
- uso de exceção;
- origem de alteração administrativa.
PIN não deve ser armazenado em claro. Dados biométricos exigem proteção adicional por serem dados pessoais sensíveis segundo a LGPD.
LGPD e biometria como segundo fator
Quando o segundo fator é biométrico, a organização precisa governar finalidade, base legal, minimização, retenção, acesso administrativo, segurança e eliminação. Não é necessário manter imagem bruta se o processo puder funcionar com template adequadamente protegido e se a imagem não tiver finalidade legítima posterior.
A arquitetura também deve considerar cópias em terminais. Um template distribuído para centenas de dispositivos amplia a superfície de proteção e torna revogação e descarte mais complexos.
MFA não justifica coleta excessiva. A pergunta deve ser: qual combinação atende ao risco com a menor exposição compatível com a finalidade?
Acessibilidade e alternativa equivalente
Teclados, leitores biométricos e terminais móveis precisam estar posicionados e configurados para a população real. Altura, alcance, contraste, feedback, lateralidade e limitações motoras podem afetar uso.
O projeto deve prever alternativa para quem não consegue utilizar um fator. Essa alternativa deve possuir nível de controle equivalente e processo governado. Criar uma “porta acessível” que opere permanentemente com política mais fraca pode introduzir um bypass estrutural.
Como especificar MFA por desempenho
Uma especificação independente de fabricante descreve comportamento, não catálogo. Em vez de exigir um leitor específico, pode estabelecer:
- pelo menos duas categorias independentes de fatores onde a matriz de risco exigir;
- política configurável por porta, usuário, grupo e horário;
- sequência de autenticação definida;
- limite de tentativas e bloqueio;
- funcionamento offline conforme matriz de continuidade;
- logs individualizados por etapa;
- integração com diretório ou IAM quando aplicável;
- contingências auditáveis;
- requisitos de latência e throughput;
- proteção de credenciais e templates;
- capacidade de revogação e sincronização;
- documentação as built da política;
- matriz de testes de aceite.
Esse formato preserva concorrência e mantém na engenharia a decisão sobre risco e desempenho.
Matriz de MFA por área
| Área | Fator 1 | Fator 2 | Offline | Exceção | Evidência de aceite |
| Administrativo | cartão | não requerido | sim | portaria | leitura e autorização |
| CPD | cartão | PIN | sim | supervisor | sucesso, erro e bloqueio |
| Sala crítica | cartão | biometria | restrito | processo formal | matching, regra e logs |
| Acesso temporário | credencial temporária | conforme risco | definido por projeto | portaria | validade e expiração |
| Área de dupla custódia | MFA individual | segunda identidade | conforme matriz | emergência formal | máquina de estados completa |
A matriz deve ser elaborada a partir do programa de necessidades e da análise de risco. Ela se torna referência para configuração e comissionamento.
FAT, SAT e comissionamento
MFA só está implantado quando a lógica foi testada. O FAT verifica política, integração e estados antes do campo. O SAT verifica comportamento no ambiente real. O comissionamento fecha a cadeia desde a apresentação dos fatores até o comando físico e o registro do evento.
Casos positivos
- dois fatores válidos;
- usuário autorizado no horário correto;
- operação offline conforme projeto;
- restauração e sincronização.
Casos negativos
- primeiro fator válido e segundo inválido;
- fatores de usuários distintos;
- credencial revogada;
- usuário autenticado mas não autorizado;
- limite de tentativas excedido;
- biometria não correspondente;
- política fora de horário.
Casos de contingência
- falha de rede;
- falha do servidor;
- falha do leitor;
- uso de credencial de emergência;
- bypass autorizado;
- retorno ao modo normal;
- reconciliação de eventos.
O aceite não deve comprovar apenas que a porta abriu. Deve comprovar que abriu pela condição correta, negou pela condição correta e gerou a evidência correta.
Indicadores após a implantação
A operação assistida pode acompanhar:
- taxa de rejeição por fator;
- tempo médio e percentil de transação;
- bloqueios por tentativas;
- exceções e bypass;
- credenciais perdidas;
- recadastros biométricos;
- falhas de sincronização;
- períodos offline;
- divergências entre política e configuração;
- chamados por ponto de acesso.
Uma elevação de exceções pode indicar que a política se tornou impraticável. Um aumento de rejeições biométricas pode revelar degradação de sensor, enrollment ruim ou mudança na população. Indicadores transformam MFA de configuração estática em controle operacional gerenciável.
Como contratar um projeto que inclua autenticação multifator
A contratação deve pedir entregáveis verificáveis. Um escopo maduro pode incluir:
- análise de risco por área;
- matriz de fatores e regras;
- diagrama de arquitetura;
- matriz de interfaces;
- requisitos de integração;
- estratégia offline e de contingência;
- requisitos de logs e cibersegurança;
- critérios de capacidade;
- casos de teste;
- matriz requisito–teste–evidência;
- documentação as built;
- procedimentos de operação e exceção.
O resultado esperado não é “instalar leitores com PIN e biometria”, mas demonstrar uma política de autenticação coerente com risco, operação e continuidade.
Erros comuns de projeto
Exigir dois fatores em todas as portas
Aumenta custo e fricção sem ganho proporcional em áreas de baixo risco.
Confundir identificador com fator
Matrícula digitada pode apenas localizar o usuário e não constituir segredo.
Ignorar o pico de fluxo
Uma política segura no laboratório pode gerar filas e bypass durante operação real.
Não definir offline
O sistema funciona enquanto toda a infraestrutura está disponível e se torna imprevisível na primeira falha de rede.
Aceitar exceções sem expiração
A contingência temporária vira o novo padrão.
Tratar biometria como infalível
FAR, FRR, FTA, qualidade de enrollment e PAD precisam ser considerados.
Não separar autenticação de autorização
O diagnóstico e a auditoria ficam pobres e o sistema passa a reportar tudo como “acesso negado”.
Considerações finais
Autenticação multifator no controle de acesso físico deve ser uma decisão seletiva, orientada por risco e comprovada por testes. O valor não está em acumular leitores ou etapas, mas em combinar fatores independentes, manter continuidade, preservar capacidade de fluxo, controlar exceções e produzir evidências auditáveis.
Quando a matriz de risco, a arquitetura, a política offline, os logs e os testes são definidos antes da compra, MFA deixa de ser uma função de catálogo e passa a ser um requisito mensurável de engenharia. Essa abordagem também evita dois extremos: subproteger áreas críticas e sobrecarregar áreas comuns com controles que a operação tende a contornar.
O aceite precisa provar que o ponto abre pela combinação correta, nega pelas condições previstas e mantém evidências em contingência.
Referências técnicas
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. 2013. Disponível em: https://webstore.iec.ch/en/publication/3662.
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-2:2014 — Alarm and electronic security systems — Part 11-2: Electronic access control systems — Application guidelines. 2014. Disponível em: https://webstore.iec.ch/en/publication/3663.
[3] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management. 2025. Disponível em: https://csrc.nist.gov/pubs/sp/800/63/B/4/final.
[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-116 Rev. 1 — Guidelines for the Use of PIV Credentials in Facility Access. 2018. Disponível em: https://csrc.nist.gov/pubs/sp/800/116/r1/final.
[5] BRASIL. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais. 2018. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.
Perguntas frequentes
É a exigência de dois ou mais fatores independentes antes da autorização de passagem, como cartão + PIN ou cartão + biometria.
Não necessariamente. Se a matrícula serve apenas para identificar o cadastro e não é um segredo, ela não representa um fator independente de conhecimento.
Não. A combinação deve resultar da análise de risco, capacidade, continuidade, privacidade e população. Cartão + PIN pode ser mais adequado em muitos cenários.
Pode, se a arquitetura mantiver localmente regras e dados suficientes. O comportamento offline precisa ser definido e testado no projeto.
Não. MFA combina fatores de uma mesma identidade; dupla custódia exige duas pessoas distintas. Os dois controles podem ser usados em conjunto.
Com casos positivos, negativos e de contingência que validem fatores, autorização, modo offline, bloqueios, revogação, exceções e evidências de log até o comando físico.
Materiais técnicos complementares
Serviços relacionados
- Programa de Necessidades e Requisitos de Engenharia
- Design Review em Projetos de Engenharia
- Comissionamento de Equipamentos: FAT, instalação, SAT, partida e aceite
Conteúdos principais sobre o tema
Conteúdos técnicos correlatos
- MFA e 2FA: autenticação multifator para acesso remoto e ambientes OT
- Credenciais móveis no controle de acesso: NFC x BLE, segurança e critérios de projeto
- MIFARE e DESFire em controle de acesso: segurança, chaves e migração
- Dupla custódia no controle de acesso: regra de duas pessoas, dual access e dual occupancy
- FAR, FRR e EER em biometria: como medir desempenho e definir o threshold