Guia técnico sobre controle de acesso por QR Code: credenciais temporárias, validade, revogação, visitantes, operação online/offline, LGPD, especificação, contratação e comissionamento.
Confira!
O controle de acesso por QR Code utiliza um símbolo óptico como meio de apresentar uma credencial ao sistema. O leitor captura o código, extrai um identificador ou token e encaminha essa informação para validação. A autorização não está no desenho do QR em si: ela depende das regras do sistema, da validade da credencial, do ponto de acesso, do horário, do perfil do usuário e das condições definidas para aquela jornada.
Isso significa que dois sistemas que usam QR Code podem ter níveis de segurança diferentes mesmo utilizando a mesma simbologia. Uma credencial de longa validade e sem governança de ciclo de vida possui comportamento distinto de uma credencial temporária associada a uma visita, com período definido, possibilidade de revogação e regras de uso.
Em controle de acesso, o QR Code é especialmente útil para visitantes, acessos temporários, eventos, prestadores e jornadas em que não se deseja emitir cartão físico. Ele pode ser distribuído previamente ao usuário e integrado ao processo de portaria ou gestão de visitantes, reduzindo etapas manuais de emissão.
A facilidade operacional exige controles proporcionais. O projeto deve definir validade, revogação, contexto de uso, rastreabilidade, tratamento de exceções e, quando o risco justificar, mecanismos adicionais de autenticação. A engenharia não deve presumir que a simbologia, isoladamente, oferece segurança suficiente.
Do ponto de vista técnico, QR Code deve ser tratado como uma modalidade de credencial dentro do sistema eletrônico de controle de acesso. Leitor, controladora, software, gestão de visitantes, rede, operação online ou offline, privacidade, logs e critérios de teste fazem parte da solução. Se esses elementos não forem definidos, a implantação pode funcionar na leitura do código e ainda assim falhar na política de acesso.
O que o QR Code representa no sistema
A ISO/IEC 18004 define a simbologia QR Code — estrutura, codificação, dimensões e correção de erros. Ela não define políticas de controle de acesso. Por isso, o projeto precisa separar o formato visual da credencial da lógica que decide se aquele código está associado a uma autorização válida.
O QR pode carregar um identificador, token ou outro dado que permita ao sistema localizar a credencial. O conteúdo visual não precisa representar diretamente nome, documento, área autorizada ou horário. Em muitos projetos, é preferível que a imagem contenha apenas uma referência opaca e que as regras permaneçam no sistema, onde podem ser alteradas ou revogadas de forma centralizada.
Essa separação é coerente com a arquitetura mais ampla de um sistema eletrônico de controle de acesso: a credencial identifica uma entidade, a controladora ou o software aplica a política e o ponto físico executa a decisão. Trocar cartão por QR Code não altera essa lógica fundamental.
O projeto também precisa definir a relação entre o código e a identidade. Em uma visita, por exemplo, o token pode estar associado a um cadastro aprovado, responsável interno, período de validade e conjunto limitado de áreas. Em um evento, a credencial pode representar inscrição válida para uma única entrada ou para uma janela específica. Em acesso recorrente, a escolha precisa considerar se QR Code continua sendo o meio mais adequado ao risco e à frequência de uso.
Assim, a pergunta técnica não é apenas “o leitor reconhece QR Code?”. É preciso saber quem emite, onde a credencial é validada, quais regras são aplicadas, como ocorre a revogação, quais eventos são registrados, como o sistema opera sem conectividade e quais evidências serão utilizadas no aceite.
QR estático e QR dinâmico
Um QR estático permanece igual durante sua vida útil. Isso simplifica emissão, distribuição e leitura, mas exige que a segurança seja garantida por outras regras do sistema, como validade, associação a uma visita, revogação e controle de uso. O fato de o símbolo não mudar não significa necessariamente que a autorização também seja permanente.
Um QR dinâmico pode variar ao longo do tempo ou representar um token de curta duração. Essa arquitetura reduz a janela em que uma credencial permanece utilizável, mas aumenta dependência de sincronismo, disponibilidade do serviço que gera o código e compatibilidade com o dispositivo do usuário. A decisão precisa avaliar risco e disponibilidade em conjunto.
Também existem arquiteturas intermediárias. Um QR visualmente estático pode apontar para um registro cuja autorização muda no servidor; um código temporário pode permanecer igual por algumas horas e ser invalidado ao final da visita; um convite pode ser emitido previamente e só se tornar ativo após validação na portaria. Portanto, “estático” e “dinâmico” descrevem apenas uma parte do comportamento.
| Critério | QR estático | QR dinâmico |
|---|---|---|
| Experiência do usuário | Simples, sem atualização frequente | Pode depender de aplicativo ou serviço ativo |
| Validade | Controlada principalmente pelo sistema | Pode combinar sistema e curta duração do token |
| Conectividade | Pode admitir mais opções offline | Frequentemente depende de sincronismo mais rigoroso |
| Operação | Menor complexidade de emissão | Maior complexidade de ciclo de vida |
| Aplicação típica | Visitas e eventos com regras bem controladas | Cenários que exigem validade curta ou atualização frequente |
A escolha deve considerar risco, frequência de uso, experiência do usuário, infraestrutura disponível e capacidade operacional. O requisito deve nascer do processo: não faz sentido adotar credencial dinâmica se a aplicação não consegue manter sincronismo ou se o usuário precisa operar em ambiente sem conectividade confiável.
A escolha entre QR estático e dinâmico não deve ser feita por tendência de mercado. A engenharia precisa definir ciclo de vida, validade, operação offline, integrações e critérios de aceite para que a credencial seja compatível com o risco e com a operação real.
Validade, expiração e uso único
Credenciais temporárias devem possuir ciclo de vida definido. O projeto pode combinar:
- início e fim de validade;
- número máximo de utilizações;
- uso único;
- horário permitido;
- ponto ou área autorizada;
- vínculo com visitante, evento ou responsável;
- revogação antecipada.
Um QR enviado para uma visita de curta duração não deve permanecer ativo além da janela definida. A validade precisa ser aplicada pelo sistema, e não depender de ação do usuário sobre a imagem recebida.
O ciclo de vida deve começar na emissão. O sistema precisa registrar quem solicitou ou autorizou a credencial, para quem ela foi criada, quais pontos ou áreas podem ser utilizados e qual intervalo de tempo foi aprovado. Se houver alteração posterior, a mudança também deve permanecer rastreável.
Revogação é uma função diferente de expiração. Expiração encerra a validade automaticamente em um momento previsto; revogação permite cancelar antecipadamente uma credencial que deixou de ser necessária. Em processos de visitantes, isso é relevante quando a reunião é cancelada, o responsável altera a autorização ou a visita termina antes do horário previsto.
Uso único também precisa ser definido com cuidado. Em alguns cenários, a credencial deve deixar de ser aceita após uma passagem válida; em outros, o visitante precisa entrar e sair mais de uma vez durante a janela autorizada. O requisito deve refletir a jornada real e, quando houver controle de presença, conversar com a lógica de anti-passback.
Quando existem vários pontos de acesso, o escopo da credencial é tão importante quanto o tempo. Uma autorização para o lobby e uma sala de reunião não deveria habilitar automaticamente áreas técnicas. A engenharia deve tratar tempo, área, sentido e quantidade de utilizações como dimensões independentes da regra.
Em operação offline, o desafio é preservar esse ciclo de vida com informações potencialmente desatualizadas. O projeto precisa estabelecer por quanto tempo uma autorização local pode ser confiável, como credenciais revogadas são tratadas e o que acontece quando a comunicação é restabelecida.
Compartilhamento, captura de tela e replay
A principal fragilidade operacional do QR é que o símbolo pode circular além do contexto originalmente previsto. Por isso, a arquitetura não deve considerar a imagem como um segredo equivalente a uma credencial física protegida.
A proteção precisa estar no ciclo de vida e na validação. Validade curta, associação a uma visita específica, revogação, restrição por área e regras de utilização reduzem a dependência do sigilo visual. Em aplicações de maior criticidade, a política pode exigir um fator adicional ou confirmação operacional.
Também é necessário definir o que caracteriza reutilização indevida para aquela aplicação. Um evento com múltiplas entradas autorizadas não deve ser tratado da mesma forma que uma visita prevista para uma única passagem. A regra precisa ser explícita e mensurável.
O sistema deve registrar situações incompatíveis com o estado esperado da credencial, como tentativa após expiração, uso após revogação ou repetição além da política definida. Esses eventos alimentam auditoria e permitem identificar problemas de configuração, processo ou comportamento.
O objetivo não é tornar o QR “incopiável”, mas garantir que uma cópia isolada não tenha autoridade ilimitada. A segurança vem da combinação entre credencial, contexto, regra e registro.
QR Code para visitantes
O uso mais natural do QR Code em controle de acesso está na jornada de visitantes. O processo pode começar antes da chegada: o anfitrião ou sistema cria o convite, associa a pessoa a uma data, horário, destino e responsável, e a credencial temporária é enviada somente após a aprovação prevista pela política.
A chegada precisa confirmar que a visita ainda está válida. Dependendo do risco, a portaria pode apenas verificar o estado do convite ou executar uma validação adicional de identidade. A portaria integrada ao controle de acesso deve tratar esse momento como parte de uma jornada maior, e não como emissão isolada de um código.
Após a validação, o sistema ativa ou mantém a credencial dentro do escopo definido. Área, horário, sentido de passagem e duração precisam ser coerentes com o objetivo da visita. Um visitante direcionado a uma sala de reunião não deve receber automaticamente o mesmo perfil de um colaborador ou prestador técnico.
Exceções também precisam ser previstas. Visitante antecipado, convite cancelado, responsável indisponível, alteração de sala, extensão de horário ou falha do smartphone são situações operacionais normais. O processo deve definir quem pode resolver cada caso, como a alteração é registrada e se uma nova credencial precisa ser emitida.
O encerramento fecha o ciclo. A saída confirmada, a expiração da janela ou o encerramento pelo responsável deve retirar a autorização conforme a política. Se o sistema controla estado de presença, a visita não pode permanecer indefinidamente marcada como ativa após a saída.
Esse fluxo reduz emissão de cartões físicos, mas não elimina a necessidade de governança. Responsável, área, validade, tratamento de exceção, encerramento, retenção de registros e eventual associação com identidade precisam ser definidos antes da implantação.
Leitura em catracas e portas
A experiência depende da posição do leitor, distância, iluminação, tamanho do símbolo, brilho da tela e velocidade de aproximação. Em catracas, uma leitura demorada pode reduzir a capacidade efetiva do corredor e formar filas mesmo quando a barreira mecânica possui alta vazão nominal.
O ponto de leitura precisa ser compatível com a jornada física. Em uma porta, o usuário pode ter tempo para aproximar o smartphone; em uma linha de catracas, a interação ocorre em movimento e se repete centenas de vezes durante o pico. Altura, ângulo e distância devem permitir apresentação natural sem obrigar o usuário a parar em posição inadequada.
O projeto deve testar códigos em telas com diferentes tamanhos e níveis de brilho, além de versões impressas quando permitidas. Películas, telas trincadas, modo escuro, exposição solar ou iluminação refletida podem alterar a condição de leitura. O objetivo do ensaio não é validar um único aparelho, mas verificar uma faixa realista de dispositivos e condições de uso.
Em catracas de acesso, o tempo de autenticação deve entrar no dimensionamento do fluxo. Se o leitor demora, se a credencial precisa consultar servidor remoto ou se visitantes precisam de ajuda frequente, o gargalo está na jornada de autenticação e não na velocidade de abertura da barreira.
Portas e catracas também podem ter requisitos diferentes de feedback. Indicação luminosa, mensagem no terminal ou sinal sonoro deve permitir que o usuário entenda se a leitura ocorreu, se o acesso foi negado ou se precisa tentar novamente, sem expor informações pessoais desnecessárias.
A posição física do leitor precisa ser coordenada com acessibilidade, passagem de pessoas, mobiliário e proteção contra danos. Em retrofit, pode ser necessário revisar conduítes, alimentação, rede e superfície de montagem antes de definir o equipamento.
O critério de aceite deve combinar taxa de leitura, tempo de decisão e conclusão da passagem. Um QR reconhecido rapidamente pelo scanner não representa bom desempenho se a consulta ao servidor ou a lógica de autorização acrescentar atraso incompatível com o fluxo esperado.
Correção de erros não é mecanismo de segurança
QR Code possui mecanismos de correção de erros destinados a preservar a capacidade de leitura quando parte do símbolo está degradada, encoberta ou reproduzida com imperfeições. Essa característica pertence à simbologia e melhora robustez de captura; ela não define identidade, autorização, validade ou proteção contra reutilização.
É importante separar resiliência da simbologia de segurança da credencial. Um código que continua legível apesar de dano parcial não se torna mais seguro por isso. Da mesma forma, um QR visualmente perfeito pode representar uma credencial expirada ou revogada e deve ser negado pelo sistema.
Criptografia, assinatura, tokenização, expiração e validação pertencem à aplicação e à arquitetura de controle de acesso. Nem todos esses mecanismos são necessários em todas as aplicações; a seleção deve considerar risco, capacidade da plataforma, operação offline e necessidade de interoperabilidade.
Na especificação e no teste, essa distinção evita requisitos vagos como “QR Code criptografado” sem explicar qual dado precisa ser protegido, quem valida a credencial e qual ameaça se pretende controlar. O requisito deve descrever comportamento verificável do sistema, não apenas um atributo comercial.
Dados pessoais e LGPD
Quando o QR está associado a visitante, empregado ou prestador, o sistema trata dados pessoais mesmo que o símbolo mostre apenas um token. A organização deve definir finalidade, base legal aplicável, minimização, controle de acesso administrativo, retenção e descarte dos registros.
Evitar dados pessoais diretamente no QR reduz exposição acidental. Um identificador opaco pode ser validado pelo sistema sem revelar nome, documento, empresa, destino ou outras informações a quem simplesmente visualize o código. Isso não elimina a necessidade de proteger o cadastro de origem, mas reduz a quantidade de informação exposta na credencial.
A minimização deve alcançar o processo inteiro. Se o objetivo da visita pode ser atendido com nome, anfitrião, validade e área autorizada, coletar campos adicionais apenas porque o software os oferece aumenta o volume de dados sem ganho técnico correspondente. O projeto deve distinguir requisitos funcionais de hábitos administrativos.
Perfis de operador também fazem parte da proteção. A equipe da portaria pode precisar consultar uma visita e reemitir uma credencial, mas não necessariamente exportar a base completa, alterar políticas globais ou acessar históricos sem limite. Permissões administrativas e logs de alteração precisam ser definidos conforme a função.
Retenção deve ser compatível com finalidade e governança. O registro de acesso pode possuir necessidade operacional ou jurídica diferente do convite original, mas essa diferença precisa ser deliberada e documentada. Backups, exportações e integrações também devem ser considerados, porque manter cópias indefinidas pode frustrar a política aplicada ao sistema principal.
Quando a jornada inclui fotografia, biometria ou outro dado sensível, o desenho precisa considerar requisitos adicionais de proteção e governança. Nesse caso, o QR continua sendo apenas um meio de apresentação da credencial; ele não reduz a responsabilidade associada aos demais dados vinculados à pessoa.
Operação online e offline
Em arquitetura online, o leitor, terminal ou controlador consulta o estado atual da credencial em uma camada central ou recebe atualizações frequentes. Isso facilita revogação imediata, regras dinâmicas e sincronização com gestão de visitantes, mas cria dependência de rede, servidor, DNS, horário e demais serviços que participam da decisão.
Em operação offline, a decisão precisa existir localmente. A controladora de acesso ou terminal pode armazenar credenciais e regras suficientes para manter pontos selecionados operacionais. O projeto deve especificar quais dados são mantidos, por quanto tempo, quantas credenciais podem ser armazenadas e quais funções deixam de existir sem o servidor.
O principal trade-off é entre continuidade e atualidade da autorização. Quanto mais tempo um ponto permanece autônomo sem sincronização, maior a possibilidade de trabalhar com informação que já mudou no sistema central. Credenciais revogadas, visitas canceladas ou alterações de perfil podem não chegar imediatamente ao dispositivo local.
Por isso, o requisito deve definir a janela aceitável de desatualização. Em pontos de menor criticidade, algumas horas de autonomia podem ser toleráveis; em acessos mais sensíveis, a política pode exigir comportamento mais restritivo. A decisão deve ser associada ao risco do ponto, e não aplicada de forma idêntica a toda a instalação.
A recuperação precisa ser especificada tanto quanto a falha. Quando a comunicação retorna, novos cadastros, revogações e eventos acumulados devem ser reconciliados. O sistema precisa preservar timestamps, evitar duplicidade e demonstrar se houve período em que uma credencial potencialmente desatualizada permaneceu utilizável.
Sincronismo de horário é especialmente importante para QR temporário. Uma credencial cuja validade termina às 18h depende de relógios coerentes entre emissor, servidor, controladora e terminal. Diferenças de horário podem produzir negações indevidas ou ampliar a janela de autorização além do previsto.
Esse ponto é decisivo em sites com conectividade instável ou multi-site. O requisito de continuidade deve ser equilibrado com o risco de operar usando dados desatualizados e precisa ser exercitado em testes de perda e recuperação de comunicação.
Integração com portaria e gestão de visitantes
QR Code não substitui a gestão de visitantes. Ele é um meio de credencialização dentro de um processo maior que começa na solicitação ou convite e termina quando a autorização é encerrada.
Pré-cadastro, aprovação, chegada, validação, acesso, permanência e encerramento continuam existindo. A portaria integrada ao controle de acesso deve conseguir consultar o estado da visita, confirmar exceções, revogar a credencial e acompanhar o ciclo sem criar acessos paralelos fora do sistema.
A integração precisa definir qual sistema é fonte da verdade de cada dado. O módulo de visitantes pode manter convite e anfitrião; o EACS mantém perfis e eventos; o diretório corporativo pode fornecer dados de empregados; o VMS registra vídeo. Replicar manualmente os mesmos cadastros em plataformas diferentes aumenta divergência e dificulta revogação.
O processo de emissão precisa indicar quem tem autoridade para criar credenciais. Convites automáticos sem controle de perfil podem ampliar privilégios além do necessário; por outro lado, exigir intervenção manual para toda visita pode criar gargalo operacional. A política deve combinar autoatendimento e aprovação conforme risco, área e tipo de visitante.
Integrações por API ou middleware precisam considerar autenticação, disponibilidade, versionamento, tratamento de erro e logs. Se a interface de visitantes ficar indisponível, o projeto deve definir se novas credenciais deixam de ser emitidas, se existe procedimento alternativo e como dados criados em contingência serão reconciliados depois.
Também é necessário prever visitantes sem smartphone, dispositivos incompatíveis ou situações em que o convite não chegou. O fluxo alternativo deve manter a mesma governança: identificar, aprovar, limitar e registrar, sem transformar a exceção em acesso livre.
Quando QR Code depende de gestão de visitantes, portaria, EACS, rede e VMS, o desafio é de integração de sistemas. A engenharia deve definir fontes de dados, interfaces, estados de falha e responsabilidades antes da implantação.
Eventos e rastreabilidade
Cada leitura deve gerar contexto suficiente para auditoria: ponto de acesso, horário, resultado da decisão e identificação lógica da credencial. O evento precisa permitir reconstruir o que ocorreu sem depender da memória do operador ou de uma planilha externa.
O registro deve diferenciar, quando a plataforma suportar, credencial válida, expirada, revogada, fora do horário, fora da área autorizada, acima do limite de utilização e outras negações relevantes. Essa classificação ajuda a separar problema de política, falha técnica e comportamento inesperado.
Também é necessário registrar alterações administrativas que afetam o ciclo de vida: emissão, cancelamento, extensão de validade, mudança de área e reemissão. Uma auditoria útil precisa responder não apenas quem tentou entrar, mas também quem alterou a autorização e quando.
Sincronismo de horário é condição básica para correlação entre sistemas. EACS, gestão de visitantes, VMS e servidores precisam manter timestamps suficientemente coerentes para que um evento de acesso possa ser associado à imagem, ao convite e à ação administrativa correspondente.
Quando houver integração entre controle de acesso e VMS, eventos selecionados podem abrir câmera, criar marcador ou facilitar investigação. A associação deve ser planejada por ponto e evento; não basta abrir vídeo genérico sem relação inequívoca com a passagem.
A retenção dos logs precisa combinar necessidade operacional e governança de dados. Período de retenção, permissões de consulta, exportação e integridade dos registros devem ser definidos conforme o contexto da organização.
Esses eventos também são evidência de teste. Durante o comissionamento, um QR expirado ou revogado deve produzir não apenas negação física, mas o registro esperado no sistema, com horário, motivo e identificação do ponto compatíveis com o plano de testes.
Como especificar QR Code em um projeto
A especificação deve descrever comportamento, não apenas exigir “leitor de QR”. Entre os requisitos estão formato suportado, tipo de token, validade, política de reutilização, operação online/offline, velocidade de leitura, ergonomia, integração, registros, revogação e testes.
Os requisitos precisam ser verificáveis. “Leitura rápida” deve ser substituída por um critério de desempenho compatível com a jornada; “funcionar offline” precisa indicar quais credenciais e regras permanecem disponíveis; “integrar com visitantes” deve explicitar quais dados e estados são trocados; “ser seguro” deve ser decomposto em ciclo de vida, privilégios administrativos, logs e controles pertinentes.
Também é necessário definir quem emite a credencial, quem pode cancelar, quais sistemas participam do fluxo e como visitantes sem smartphone ou com dispositivo incompatível serão atendidos. Esses casos alternativos fazem parte do requisito funcional e precisam ser incluídos no desenho da operação.
A especificação deve distinguir requisitos do leitor e requisitos do sistema. O leitor precisa capturar o símbolo nas condições ambientais previstas; o EACS precisa validar autorização e registrar eventos; o módulo de visitantes precisa administrar convite e ciclo de vida; a rede precisa suportar a arquitetura; e a barreira deve executar a decisão corretamente.
| Requisito | Critério de engenharia | Evidência de aceite |
|---|---|---|
| Validade | Início, fim e revogação definidos | Testes antes, dentro e após a janela |
| Escopo | Áreas, pontos, horários e sentido autorizados | Teste em ponto permitido e ponto negado |
| Operação offline | Funções locais e janela de desatualização definidas | Perda e recuperação de comunicação |
| Leitura | Condições de tela, distância e tempo compatíveis com uso | Ensaio com dispositivos e condições representativas |
| Rastreabilidade | Eventos e alterações administrativas registrados | Logs correlacionados ao caso de teste |
| Integração | Dados, origem, destino e tratamento de falha documentados | Teste ponta a ponta entre sistemas |
As interfaces precisam indicar responsabilidades. Quem fornece o leitor? Quem configura o terminal? Quem integra o sistema de visitantes? Quem disponibiliza rede e alimentação? Quem define a política de retenção? Quem executa testes integrados? Sem essa definição, uma característica pode existir em todos os produtos e ainda não funcionar no sistema final.
O projeto deve evitar copiar ficha técnica de fabricante como especificação. A intenção é declarar o resultado necessário e as condições de verificação para permitir comparação entre alternativas tecnicamente equivalentes.
Como contratar engenharia para controle de acesso por QR Code
Quando QR Code é apenas uma das credenciais de um sistema existente, a contratação pode parecer simples. Entretanto, projetos que envolvem visitantes, novas catracas, integrações, operação offline ou múltiplos sites exigem definição de escopo suficiente para que fornecedores diferentes entreguem propostas comparáveis e para que o aceite não dependa de interpretações posteriores.
O objeto deve indicar se a contratação abrange levantamento, projeto, licenças de software, leitores, controladoras, integração com gestão de visitantes, configuração, instalação, treinamento, testes e documentação. Também deve declarar exclusões relevantes, como infraestrutura de rede, obras civis, alimentação, integração com diretório corporativo ou desenvolvimento de APIs.
Os entregáveis de engenharia podem incluir arquitetura, matriz funcional, fluxos de visitante, lista de pontos, requisitos de credenciais, critérios online/offline, especificação por desempenho, matriz de interfaces, quantitativos e plano de testes. Esses documentos transformam decisões operacionais em requisitos que podem ser medidos e aceitos.
A equipe contratada precisa compreender controle de acesso, rede, software e operação. Em ambientes com dados pessoais, a governança de privacidade deve participar da definição de campos, retenção e perfis administrativos. Quando o sistema conversa com VMS, portaria ou RH, as equipes responsáveis pelas interfaces precisam estar incluídas no processo de revisão e teste.
A medição deve ser associada a marcos verificáveis. Projeto aprovado, configuração concluída, integração testada, operação offline validada, treinamento realizado e As Built entregue são exemplos de resultados que podem sustentar pagamento. Concentrar o valor contratual no fornecimento do leitor reduz a capacidade do contratante de exigir o fechamento das integrações.
O aceite deve utilizar requisitos previamente definidos. Tempo de leitura, comportamento de credenciais expiradas, revogação, recuperação após perda de comunicação, logs e tratamento de visitantes alternativos precisam ter resultados esperados registrados antes dos testes.
Quando existem vários fornecedores, deve haver responsável pela integração ponta a ponta. A ausência dessa função costuma aparecer no final da implantação, quando cada subsistema funciona isoladamente mas o fluxo completo do visitante não está operacional.
Testes e comissionamento
O plano de testes deve incluir QR válido, expirado, revogado, fora do horário, acima do limite de utilização, baixa luminosidade, brilho excessivo, telas de diferentes tamanhos, código impresso quando permitido e perda de conectividade. O objetivo é reproduzir as condições que podem alterar leitura, autorização ou rastreabilidade.
Cada caso precisa declarar condição inicial, procedimento, resultado esperado e evidência. Um QR expirado, por exemplo, deve ser lido pelo scanner e negado pelo sistema pelo motivo previsto; o evento correspondente deve aparecer no log com ponto e horário corretos. Isso diferencia falha de captura de uma decisão de autorização.
O aceite deve verificar não apenas a leitura, mas a decisão correta do sistema e o registro do evento. Também precisa confirmar que a barreira física executa o comando e que o estado final é coerente: porta liberada, catraca com passagem confirmada ou acesso negado sem alteração indevida do estado de presença.
Testes integrados devem percorrer a jornada completa de visitante. Convite emitido, credencial recebida, chegada, validação na portaria, passagem, evento de vídeo quando aplicável, saída e expiração precisam formar uma sequência consistente. Se cada plataforma é testada isoladamente, falhas de interface podem permanecer ocultas.
A operação offline deve ser exercitada deliberadamente. O teste precisa retirar a comunicação prevista, verificar quais credenciais continuam válidas, observar o registro local, aplicar uma alteração no sistema central quando possível e confirmar como a reconciliação ocorre após a recuperação.
Falhas de horário também merecem verificação em credenciais temporárias. NTP indisponível, relógio incorreto ou divergência entre servidor e terminal podem alterar a janela de validade. O comissionamento deve demonstrar que a infraestrutura temporal utilizada pelo sistema está coerente.
Documentação e configuração precisam fazer parte do aceite. Lista de pontos, arquitetura, matriz funcional, parâmetros relevantes, backups, evidências de teste e As Built devem representar o sistema entregue. O artigo sobre comissionamento de sistemas de controle de acesso conforme a IEC 60839 detalha essa rastreabilidade entre requisito, teste e evidência.
Pendências devem ser classificadas e encerradas antes do aceite final conforme sua criticidade. Uma falha estética não possui o mesmo impacto de uma credencial revogada que continua funcionando offline ou de um evento que não chega ao sistema central.
Ler o QR Code não comprova que o sistema está pronto. O comissionamento deve verificar ciclo de vida, regras, falhas, integrações, logs, recuperação e documentação com evidências rastreáveis.
Considerações finais
QR Code é um meio eficiente para credenciais temporárias quando o sistema controla validade, reutilização, revogação, dados e rastreabilidade. Sem essa camada de engenharia, ele vira apenas uma imagem fácil de copiar. A solução deve ser projetada como parte do EACS e do processo de visitantes, não como recurso isolado do leitor.
Referências técnicas
[1] ISO. ISO/IEC 18004:2024 — Information technology — Automatic identification and data capture techniques — QR code bar code symbology specification. Disponível em: https://www.iso.org/standard/83389.html
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Electronic access control systems — System and components requirements. Disponível em: https://webstore.iec.ch/en/publication/3662
[3] BRASIL. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
Perguntas frequentes
Pode ser, desde que validade, revogação, reutilização e regras de autorização sejam controladas pelo sistema. O símbolo sozinho não garante segurança.
O estático permanece igual; o dinâmico varia ou representa credencial de curta validade, reduzindo a janela de reutilização indevida.
Tecnicamente pode funcionar se a credencial aceitar reutilização. Por isso o projeto deve tratar replay por validade curta, uso único ou outras regras adequadas ao risco.
Em geral, é preferível minimizar exposição e usar identificador ou token que o sistema valide, evitando dados pessoais desnecessários no símbolo.
Pode funcionar se a arquitetura prever validação local, mas é necessário definir como revogações e atualizações serão tratadas durante a perda de conectividade.
Materiais técnicos complementares
Serviços relacionados
Conteúdos principais sobre o tema
- Sistema de Controle de Acesso: tipos, tecnologias, normas e projeto
- Portaria e controle de acesso: arquitetura, visitantes e regras de operação
- Matriz funcional de controle de acesso: como especificar cada ponto
- Controladora de acesso: como funciona, I/O, capacidade e arquitetura
Conteúdos técnicos correlatos
- Catracas de acesso: tipos, fluxo, segurança e critérios de projeto
- Anti-passback em controle de acesso
- Integração entre controle de acesso e VMS
- Comissionamento de sistemas de controle de acesso conforme a IEC 60839
- Cibersegurança em sistemas de segurança física
