Autenticação multifator no controle de acesso físico: cartão, PIN, biometria e critérios de projeto

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

A arquitetura de um sistema de controle de acesso conecta identidade, autorização, barreiras, infraestrutura e operação. Neste tema, o projeto deve preservar essa visão de conjunto e transformar as decisões específicas em requisitos verificáveis.

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.

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

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”.

Exemplo de dimensionamento: dois fatores sem criar um gargalo

Considere um cenário ilustrativo de 180 pessoas chegando em dez minutos a um conjunto de acessos. A demanda média dessa janela é de 18 pessoas por minuto, mas a chegada pode se concentrar nos primeiros minutos. Se o ciclo completo observado de uma passagem for seis segundos, a capacidade nominal de uma faixa será dez pessoas por minuto. Duas faixas ofereceriam vinte passagens por minuto apenas sob condições ideais, deixando pequena margem para tentativas repetidas, orientação e usuários que necessitam assistência. Esses números são hipóteses de cálculo, não desempenho de produto nem limite normativo.

Com três faixas equivalentes, a capacidade nominal seria trinta pessoas por minuto e a utilização média, nessa hipótese, seria 60%. Isso ainda não demonstra atendimento: é preciso observar distribuição das chegadas, duração das transações e indisponibilidade de uma faixa. A dimensão da fila e o tempo de espera não podem ser deduzidos apenas da divisão entre volume total e capacidade média. O estudo deve simular ou medir o pico e verificar se a fila ocupa circulação, interfere na recepção ou cria incentivo para passagem acompanhada sem autenticação individual.

O ensaio deve começar na apresentação do primeiro fator e terminar no rearme da barreira. Medir apenas o matching biométrico exclui digitação, feedback, aproximação, abertura e passagem. Também convém separar primeira tentativa bem-sucedida, repetição, rejeição legítima e atendimento assistido. Uma configuração pode apresentar excelente média e, ainda assim, penalizar uma parcela da população. A amostra deve representar condições reais de iluminação, luvas quando compatíveis, mobilidade, turnos e treinamento, sem expor dados pessoais desnecessariamente.

O relatório de capacidade deve comparar demanda de projeto, desempenho medido, cenário degradado e medidas de tratamento. As alternativas podem envolver reposicionamento de leitores, ajuste do fluxo, ampliação de faixas ou escolha de outra combinação de fatores. Reduzir a política de segurança no pico não é uma consequência automática do dimensionamento: qualquer mudança exige avaliação de risco, aprovação e configuração documentada.

Vinculação dos fatores e reinício seguro da transação

Dois fatores válidos, isoladamente, não demonstram uma transação válida. Eles precisam pertencer à mesma identidade e à mesma tentativa. Depois de apresentar um cartão, o usuário não deve deixar no terminal um primeiro fator indefinidamente disponível para que outra pessoa conclua a sequência. A especificação precisa declarar janela de associação, cancelamento, nova tentativa e comportamento quando uma segunda credencial é apresentada antes da conclusão da primeira.

Um teste útil apresenta a credencial de uma pessoa de ensaio e o segundo fator de outra, ambas previamente autorizadas. O resultado esperado é negar a combinação incompatível, registrar o motivo técnico em ambiente autorizado e retornar ao estado inicial. Outro teste aguarda o encerramento da janela entre fatores e verifica se a transação antiga foi descartada. O procedimento deve utilizar usuários de teste, com autorização da operação, sem coletar ou divulgar segredos de pessoas reais.

A interface de comunicação entre leitor e controladora também participa da confiança. Se a verificação termina no leitor, o projeto precisa entender o que ele transmite: uma identidade, um resultado autenticado ou uma informação simples cuja origem não pode ser verificada. Não basta o equipamento exibir a palavra MFA. A análise deve acompanhar a evidência até o componente que decide a liberação, verificando proteção do canal, comportamento em violação e restrições da combinação efetivamente fornecida.

Na recuperação de falha, uma tentativa parcialmente concluída não deve ser retomada de modo ambíguo. Reiniciar o serviço, reconectar a rede ou trocar de modo operacional precisa resultar em estado conhecido. O ensaio de regressão deve cobrir essas transições, porque uma autenticação nominal correta pode coexistir com um tratamento inadequado de sessões interrompidas.

Do piloto à liberação operacional: responsabilidades e evidências

O piloto precisa ter fronteira definida: pontos abrangidos, população de ensaio, política vigente, duração, critérios de interrupção e responsável pela decisão. Segurança aprova o risco e as exceções; operação valida fluxo e atendimento; TI verifica dependências; a equipe de engenharia consolida requisitos e evidências; o integrador implementa e demonstra a configuração. O proprietário aceita os resultados segundo o escopo contratado, sem transferir a aprovação de risco a uma escolha informal de campo.

Uma aprovação condicionada deve identificar o requisito ainda não demonstrado, a exposição residual, o controle temporário, o responsável e a data de reteste. Problemas de conforto e falhas que permitem acesso indevido não recebem o mesmo tratamento. A criticidade deve ser decidida antes da campanha, para que a pressão do cronograma não transforme uma vulnerabilidade em simples observação administrativa.

O pacote final inclui versão da política por área, associação dos fatores, temporizações, limites de tentativa, alternativas acessíveis, perfis administrativos, resultados de ensaio, configuração de recuperação e procedimentos de manutenção. O documento deve permitir distinguir uma alteração aprovada de uma configuração feita posteriormente. Fotografias de leitores e uma lista de equipamentos não substituem esse conjunto, porque não mostram a lógica que governa a passagem.

Na contratação da A3A Engenharia, o problema pode ser estruturado em levantamento de requisitos, projeto ou revisão, acompanhamento técnico e comissionamento, conforme a fase da instalação. O serviço deve definir entregáveis e responsabilidades para demonstrar a política, sem prometer redução de risco não medida. Para a transferência à operação, o framework de handover ajuda a organizar configuração, treinamento, manutenção e custódia das evidências, além do teste inicial da porta.

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.

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

O que é autenticação multifator no controle de acesso físico?

É a exigência de dois ou mais fatores independentes antes da autorização de passagem, como cartão + PIN ou cartão + biometria.

Cartão mais matrícula digitada é MFA?

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.

Toda área crítica precisa usar biometria como segundo fator?

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.

MFA pode funcionar quando o servidor está fora do ar?

Pode, se a arquitetura mantiver localmente regras e dados suficientes. O comportamento offline precisa ser definido e testado no projeto.

MFA substitui dupla custódia?

Não. MFA combina fatores de uma mesma identidade; dupla custódia exige duas pessoas distintas. Os dois controles podem ser usados em conjunto.

Como comprovar MFA no comissionamento?

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: demandas, desempenho e critérios de projeto
• Design Review em Projetos de Engenharia: revisão técnica, interfaces e maturidade do projeto
• Projeto de Controle de Acesso: arquitetura, dispositivos, integração e especificação
• Apoio Técnico à Fiscalização de Obras e Contratos de Engenharia: controle, evidências e conformidade
• Comissionamento de Equipamentos: FAT, instalação, SAT, partida e aceite

Conteúdos principais sobre o tema

• Sistema de Controle de Acesso: tipos, tecnologias, normas e projeto
• Cadastro biométrico no controle de acesso: enrollment, qualidade, segurança e LGPD
• Credenciais móveis no controle de acesso: NFC x BLE, segurança e critérios de projeto
• 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
• Integração entre controle de acesso, RH, Active Directory e IAM: arquitetura, ciclo de identidade e critérios de projeto
• Comissionamento de sistemas de controle de acesso conforme a IEC 60839

Conteúdos técnicos correlatos

• Comissionamento: guia completo do planejamento, testes, aceite e handover
• Framework de Handover Técnico de Obras e Sistemas: da completação à operação
• Entenda como é possível viabilizar o seu Projeto de Segurança Digital