Sua rede provavelmente já apresenta os sintomas. Alguns termostatos inteligentes chegaram com um instalador. Os controladores de portas vieram com outro. A equipe de instalações adicionou sensores de vazamento. O marketing quer contadores de fluxo de pessoas. As operações querem etiquetas de ativos. Dispositivos de convidados, tablets de funcionários, câmeras, quiosques e sistemas prediais precisam de conectividade, mas nem todos falam a mesma língua e, definitivamente, nem todos se comportam como laptops.
É aí que muitos projetos de IoT corporativos começam a oscilar. As equipes se concentram no dispositivo, no rádio ou no painel de nuvem, e deixam o modelo de comunicação como uma reflexão tardia. Então, a propriedade cresce. De repente, o problema não é adicionar mais um sensor. É operar centenas ou milhares de dispositivos com diferentes padrões de tráfego, diferentes níveis de confiança e modos de falha muito distintos.
A solução prática começa com a compreensão dos protocols for IoT. Não como um exercício de glossário, mas como um modelo operacional. Depois que você sabe qual protocolo faz o quê, onde ele se posiciona na pilha e como ele afeta a integração, o isolamento e a sobrecarga de suporte, o caos se torna gerenciável.
Domando o Caos dos Dispositivos Conectados
Em um hotel, um problema de perda de pacotes em uma rede de convidados pode parecer menor até que os controles dos quartos compartilhem o mesmo tempo de transmissão de WiFi e comecem a perder atualizações. No varejo, um contador de filas que reporta a cada poucos segundos tem necessidades muito diferentes de um reprodutor de sinalização digital que puxa conteúdo rico. Em um hospital ou escritório grande, os sensores alimentados por bateria podem precisar durar longos períodos, enquanto a infraestrutura fixa pode tolerar protocolos mais pesados e planos de controle mais rígidos.
O erro é tratar todos os dispositivos conectados como se pertencessem a um único design de rede padrão.
Por que a escolha do protocolo se torna um problema operacional
Um protocolo não é apenas uma preferência técnica. Ele define:
- Com que frequência os dispositivos conversam e quão ativos eles são na rede
- Quanta bateria eles consomem para enviar dados úteis
- Quão fáceis eles são de integrar sem credenciais compartilhadas
- Quão bem eles escalam quando vários sistemas precisam da mesma telemetria
- Quão limpa é a integração com serviços em nuvem, brokers, gateways e controles de identidade
Para equipes que gerenciam propriedades mistas, isso se torna um problema de suporte tanto quanto de arquitetura. Se você já está lidando com um número crescente de endpoints conectados, a análise da Purple sobre how many devices are connected to the internet é um lembrete útil de que o crescimento dos dispositivos não está desacelerando. Mais endpoints significam mais diversidade de protocolos, não menos.
Regra prática: Padronize seu modelo de integração e segurança sempre que puder, mas não force todos os tipos de dispositivos a usarem o mesmo protocolo de comunicação.
O que é um bom modelo
Um ambiente de IoT viável geralmente apresenta três características.
Primeiro, o protocolo corresponde às restrições do dispositivo. Sensores minúsculos não devem carregar o peso da comunicação do tipo web se eles só precisam publicar alterações de estado.
Segundo, o protocolo corresponde ao ambiente. Espaços internos densos, edifícios de concreto e locais multi-tenant punem designs que pareciam ótimos em condições de laboratório.
Terceiro, o protocolo suporta o modelo de segurança que você precisa. Se a sua equipe não puder atribuir uma identidade única, revogar o acesso de forma limpa e segmentar os dispositivos por função, o protocolo criará problemas futuros, mesmo que o projeto piloto funcione.
Essa é a estrutura que deve ser mantida em mente em cada decisão de protocolo.
As Quatro Camadas de Comunicação de IoT
Quando as equipes ouvem nomes como MQTT, CoAP, Thread, LoRaWAN, TCP, UDP e WiFi na mesma reunião, a conversa geralmente fica confusa porque esses protocolos não resolvem todos o mesmo problema. A maneira mais clara de entendê-los é separá-los em camadas.
Pense na comunicação de IoT como o envio de um pacote.
A analogia do pacote que realmente ajuda
- Camada de aplicação. Este é o item dentro do pacote. É o significado dos dados. Uma leitura de temperatura, um comando para abrir uma porta, uma atualização de status do dispositivo.
- Camada de transporte. É assim que o pacote é manuseado. Você quer entrega confirmada ou quer que seja enviado rapidamente com menos sobrecarga?
- Camada de rede. Este é o endereço e a lógica de roteamento que leva o pacote ao destino correto através das redes.
- Camada de enlace. Este é o veículo de entrega e o caminho local. WiFi, Ethernet, Zigbee, Thread, IoT celular e outros métodos de conectividade local vivem aqui.
Esse modelo mental encerra muitos debates sobre designs ruins. Comparar MQTT com WiFi é como comparar o item na caixa com a van que o transporta. Eles pertencem a camadas diferentes.
Por que as equipes corporativas precisam dessa visão em camadas
Depois de visualizar a pilha de forma clara, a seleção do protocolo se torna muito menos emocional. Você pode misturar e combinar com base nas restrições, em vez de escolher um nome familiar e tentar usá-lo em todos os lugares.
Por exemplo, um sensor predial pode usar um protocolo de aplicação leve, uma escolha de transporte adequada para mensagens pequenas, um caminho de rede baseado em IP por meio de um gateway e uma camada de enlace de baixa potência dentro do edifício. Uma câmera, por outro lado, pode usar Ethernet com fio ou WiFi e utilizar um padrão de aplicação completamente diferente.
Um marco importante nesse espaço foi a padronização do MQTT como um padrão OASIS e do CoAP como definido no RFC 7252. Isso importava porque o mercado corporativo precisava de formas comuns e interoperáveis para lidar com dispositivos limitados. O pano de fundo é de ampla adoção. A TechAhead citou dados mostrando que os dispositivos IoT foram usados por 29% das empresas da UE em 2021 no contexto de adoção corporativa e padronização de protocolos, o que é relevante para as equipes do Reino Unido que planejam a interoperabilidade e a segurança em ambientes digitais semelhantes ( EMQX sobre MQTT, CoAP e LwM2M ).
Uma stack simples que você pode usar em revisões de projeto
| Camada | Pergunta a ser feita | Exemplos comuns |
|---|---|---|
| Aplicação | O que os dados significam e como são trocados? | MQTT, CoAP, HTTP, LwM2M |
| Transporte | Como a entrega é gerenciada? | TCP, UDP |
| Rede | Como o tráfego é endereçado e roteado? | Rede baseada em IP |
| Enlace | Como o dispositivo se conecta fisicamente? | Ethernet, WiFi, Zigbee, Thread, LoRaWAN, NB-IoT |
Se uma revisão de projeto ficar travada, faça uma pergunta primeiro: “De qual camada estamos realmente falando?” Isso geralmente esclarece a confusão rapidamente.
Comparando os Principais Protocolos de Aplicação e Transporte
No topo da stack, a decisão fundamental geralmente gira em torno de como os dispositivos trocam dados com aplicações, brokers ou plataformas de gerenciamento. As equipes corporativas sentem esse impacto de forma mais direta porque esses protocolos determinam o estilo de mensagens, o esforço de integração e quanto tráfego desnecessário acaba na rede.
O mercado se moveu em direção a opções mais leves por um motivo. Espera-se que os protocolos de IoT desenvolvidos especificamente para essa finalidade, como MQTT e CoAP, cresçam 11% ao longo de dois anos, com a facilidade de uso e a confiabilidade identificadas como os requisitos mais importantes pelos desenvolvedores, de acordo com o IoT Analytics sobre protocolos de IoT . Isso se alinha com o que a maioria das equipes corporativas vê na prática. Dispositivos limitados não se beneficiam de carregar muito overhead de protocolo apenas para dizer “a temperatura ainda está normal”.
Comparação de Protocolos de Aplicação e Transporte
| Protocolo | Modelo | Transporte Subjacente | Overhead | Melhor Para |
|---|---|---|---|---|
| MQTT | Publicação e assinatura | Geralmente TCP | Baixo | Telemetria, monitoramento remoto, distribuição de dados de muitos para muitos |
| CoAP | Requisição e resposta | Geralmente UDP | Muito baixo | Dispositivos limitados, mensagens pequenas, interações locais de baixa latência |
| HTTP(S) | Solicitação e resposta | TCP | Mais alto | Integração web, APIs, fluxos de trabalho compatíveis com navegadores |
| LwM2M | Orientado ao gerenciamento de dispositivos | Comumente utilizado com transportes leves | Baixo a moderado | Provisionamento, gerenciamento de ciclo de vida, configuração remota |
O MQTT funciona quando muitos sistemas precisam dos mesmos dados
O MQTT costuma ser o padrão para IoT corporativo porque é eficiente e operacionalmente limpo. Os dispositivos publicam mensagens em tópicos. Os sistemas interessados se inscrevem. Isso significa que um único sensor pode alimentar o monitoramento de instalações, análises, alertas e fluxos de trabalho de manutenção sem que cada consumidor precise consultar o dispositivo separadamente.
Para propriedades de hospitalidade e varejo, isso é fundamental. Um sensor de refrigeração, sensor de ocupação ou medidor de energia frequentemente precisa atender a várias funções de back-end ao mesmo tempo. O MQTT faz isso com elegância.
O CoAP se adapta a dispositivos muito pequenos e limitados
O CoAP geralmente é a melhor opção quando a pegada do dispositivo é minúscula, o tráfego é simples e o envio de mensagens leves baseado em UDP é aceitável. É útil onde a baixa latência e a sobrecarga mínima importam mais do que um modelo de mensagens mais rico.
Dito isso, as equipes às vezes subestimam a sobrecarga de integração em torno do CoAP. Ele pode ser elegante do lado do dispositivo e complexo do lado corporativo se suas ferramentas, brokers, pilha de observabilidade e controles de segurança forem construídos em torno de premissas diferentes.
Cuidado no design: O protocolo mais eficiente no papel não é automaticamente a escolha com menor atrito em produção.
O HTTP ainda tem seu lugar, mas não em todos os lugares
O HTTP e o HTTPS continuam úteis porque toda equipe de nuvem, desenvolvedor e plataforma de integração já os compreende. Se o dispositivo precisa chamar uma API REST, fazer upload de payloads maiores ocasionalmente ou se integrar a um fluxo de trabalho de aplicação web existente, o HTTP pode ser a resposta certa.
O problema é o uso incorreto. Um sensor alimentado por bateria enviando pequenas atualizações de status por meio de um padrão pesado de solicitação e resposta geralmente cria uma sobrecarga evitável. Funciona, mas "funciona" e "funciona bem em escala" não são a mesma coisa.
O LwM2M ajuda quando o gerenciamento é a prioridade
O LwM2M merece atenção quando o maior desafio não é a telemetria, mas as operações da frota. Provisionamento, configurações remotas, status do software e gerenciamento de ciclo de vida tornam-se mais estruturados com um protocolo desenvolvido para gerenciamento de dispositivos. Na prática, muitas organizações usam um protocolo para telemetria e outra camada de gerenciamento para funções de controle e ciclo de vida.
Um teste corporativo que vai além da teoria
Pergunte o seguinte: O dispositivo precisa publicar pequenas atualizações repetidamente, responder a comandos diretos ou expor uma interface amigável para a web?
- Telemetria frequente para múltiplos consumidores: O MQTT geralmente se adapta melhor
- Pegadas muito pequenas e trocas leves: CoAP é ideal
- Integração direta de API e compatibilidade com navegador/nuvem: HTTP(S) é ideal
- Gerenciamento de frota e controle estruturado de dispositivos: LwM2M merece atenção
Se o seu ambiente inclui vídeo, não confunda o envio de mensagens gerais de IoT com protocolos de transmissão de streaming. Para equipes que avaliam fluxos de trabalho de câmeras, este manual sobre transmissões RTSP é útil porque o transporte de vídeo tem prioridades de design muito diferentes da telemetria de sensores de baixo consumo.
Navegando pelos Protocolos de Rede e de Camada de Link
Uma vez escolhido o protocolo de aplicação, a questão do mundo real mais difícil costuma ser como o dispositivo entra na rede de forma geral. Esse desafio frequentemente leva à falha de projetos em edifícios, propriedades rurais e locais de uso misto. A pilha de protocolos pode parecer perfeita na camada de aplicação e ainda assim ter um desempenho abaixo do esperado porque as escolhas de link e rede foram incorretas para o ambiente.
Edifícios densos precisam de uma resposta diferente de locais abertos
Para ambientes industriais e campus, opções de malha de baixo consumo como Zigbee e Thread atendem a nós alimentados por bateria em espaços internos densos, enquanto LoRaWAN e NB-IoT são mais adequados para telemetria de vários quilômetros. A compensação é entre largura de banda, latência e vida útil da bateria, e a resposta correta depende do caso de uso real do Reino Unido, como rastreamento de ativos internos versus monitoramento remoto de propriedades, conforme descrito em este guia sobre protocolos de comunicação de IoT industrial .
Essa compensação importa mais do que a preferência do fornecedor.
Como eu agrupo as escolhas de link no design empresarial
Curto alcance e maior taxa de transferência
WiFi e Ethernet pertencem aqui. Eles são a escolha óbvia para dispositivos com energia estável, pacotes de dados maiores ou integração simples de TI. Câmeras, quiosques, reprodutores de mídia e aparelhos fixos geralmente se enquadram nessa categoria.
A desvantagem é o uso de energia e a disputa por tempo de transmissão. Se você colocar muitos dispositivos de baixo valor e muito comunicativos na mesma infraestrutura sem fio que o tráfego crítico, criará suas próprias chamadas de suporte.
Curto alcance e malha de baixo consumo de energia
Zigbee e Thread fazem mais sentido quando os dispositivos são pequenos, alimentados por bateria e distribuídos por um edifício denso. Salas inteligentes, sensores de prateleira, dispositivos de ocupação e monitoramento ambiental geralmente se encaixam nesse padrão.
A rede em malha pode ser excelente em ambientes internos, mas apenas quando as equipes planejam o posicionamento do gateway, o comportamento de roaming e a interferência do ambiente de rádio ao redor.
Longo alcance e rede ampla de baixo consumo de energia
LoRaWAN e NB-IoT são as melhores opções quando o local é amplo, os dados são esparsos e a eficiência da bateria importa mais do que a taxa de transferência. Serviços públicos, propriedades, monitoramento de perímetro e telemetria remota são exemplos comuns.
O ponto cego da equipe de rede
Muitos engenheiros de rede conhecem bem a parte de IP, mas não passaram muito tempo com redes de dispositivos limitados ou não tradicionais. Se a sua equipe precisar de uma reciclagem sobre conceitos básicos de roteamento e comutação antes de adicionar a complexidade de IoT, uma sólida preparação para o exame Cisco CCNA pode ajudar, pois muito do diagnóstico de problemas de IoT ainda depende de fundamentos sólidos de rede.
Para propriedades de IoT baseadas em IP, o planejamento de endereçamento também importa mais do que muitas equipes esperam. O crescimento misto de endpoints, a segmentação e os longos ciclos de vida dos dispositivos são boas razões para revisitar a diferença entre IPv6 e IPv4 antes que a implantação se torne grande.
Em IoT, a escolha do rádio raramente tem a ver com o "melhor alcance". Trata-se de saber se o sinal sobrevive ao edifício real, à interferência real e ao modelo de suporte real.
O que geralmente funciona e o que geralmente não funciona
- Funciona bem: WiFi para dispositivos alimentados com padrões de tráfego mais ricos
- Funciona bem: Zigbee ou Thread para propriedades densas de bateria em ambientes internos
- Funciona bem: LoRaWAN ou NB-IoT para telemetria esparsa e de longo alcance
- Geralmente falha: um único padrão de conectividade forçado em todas as classes de dispositivos
- Geralmente falha: escolher com base em mapas de cobertura de laboratório em vez de condições do local
Esse último ponto causa dores de cabeça intermináveis. Materiais internos, densidade de inquilinos e ruído de RF mudam a resposta.
Como Escolher o Protocolo Certo para o seu Negócio
A maioria dos compradores pergunta qual protocolo é o melhor. Essa é a pergunta errada. A pergunta útil é qual protocolo melhor se adapta ao dispositivo, ambiente, padrão de tráfego e modelo de segurança que você precisa operar.
No Reino Unido, isso é especialmente importante porque a seleção do protocolo é frequentemente moldada por condições de rádio reais, em vez do alcance teórico. Os dados da Ofcom mostram o uso intenso de bandas isentas de licença, e os dados do governo destacam pontos cegos de cobertura móvel interna, o que significa que a penetração nas paredes, a interferência e a confiabilidade do backhaul geralmente importam mais do que o título da folha de especificações. A Kore Wireless resume bem esse desafio em sua discussão sobre as vantagens e desvantagens dos protocolos de IoT no Reino Unido .
Comece com a realidade física
Um hotel de concreto, uma unidade de varejo com estrutura de aço e um local de serviços públicos ao ar livre não se comportam da mesma maneira. Comece com o local, não com os slides de apresentação do fornecedor.
Pergunte:
- Onde o dispositivo ficará? Sala de máquinas, quarto, corredor, estacionamento, telhado, borda do campus.
- O que bloqueia o sinal? Concreto, metal, elevadores, unidades de refrigeração, alta densidade de ocupação.
- Quem é o proprietário do backhaul? Sua equipe, um provedor gerenciado, um terceiro ou uma operadora móvel.
Um protocolo que parece ideal em uma sala de teste vazia pode falhar em um edifício real cheio de interferências e movimento.
Combine o protocolo com o comportamento empresarial
Uma abordagem de seleção útil é mapear cada caso de uso para o menor conjunto de requisitos reais.
Termostatos de hotel e sensores ambientais
Esses dispositivos geralmente enviam pequenas atualizações, frequentemente em intervalos fixos ou mudanças de estado. Eles não precisam de comunicação do tipo web, mas precisam de operação estável e comportamento gerenciável de bateria ou energia. Mensagens leves e uma disciplina de gateway local geralmente superam designs pesados centrados em API.
Beacons de varejo e dispositivos de fluxo de pessoas
A densidade interna é o que importa aqui. Você se preocupa com coexistência, vida útil da bateria e operação previsível em condições de RF movimentadas. Se os dispositivos estiverem espalhados por uma loja ou shopping center, opções de curto alcance e baixo consumo de energia geralmente fazem mais sentido do que forçar tudo para o WiFi padrão.
Rastreadores de ativos em hospitais ou campus
A cobertura se torna a parte difícil. Pontos cegos, materiais de construção e padrões de movimento importam mais do que as promessas de folheto. Protocolos de telemetria de longo alcance podem ajudar em propriedades distribuídas, mas podem não ser adequados para localização interna detalhada ou atualizações frequentes.
Um checklist prático de decisão
- Orçamento de energia primeiro: Se o dispositivo funciona com bateria, descarte opções barulhentas ou pesadas logo no início.
- Padrão de tráfego em seguida: Alterações de estado pequenas e frequentes favorecem mensagens leves.
- Tolerância à latência importa: Alguns monitoramentos podem tolerar atrasos. Segurança e controle muitas vezes não podem.
- O peso da integração conta: Um protocolo que sua equipe de plataforma já consegue proteger e observar pode valer mais do que uma alternativa ligeiramente mais leve.
- O modelo de suporte decide a escala: Se as equipes de campo não puderem substituir, redefinir ou provisionar novamente os dispositivos de forma limpa, seu custo operacional aumentará rapidamente.
Regra de seleção: Escolha o protocolo que oferece um desempenho aceitável do dispositivo com a menor complexidade operacional. Não o protocolo com a melhor ficha técnica.
Os designs mais robustos geralmente não são puros. Eles usam uma família de protocolos para telemetria restrita, outra para aplicações mais ricas e um plano de gerenciamento separado para identidade e política.
Unificando a segurança de IoT com a identidade do dispositivo
A maioria das discussões sobre protocolos termina cedo demais. Elas comparam o tamanho da mensagem, o uso da bateria e o alcance, e assumem que o problema de segurança pode ser adicionado depois. Em ambientes corporativos, isso é o inverso. O principal desafio é provar que cada dispositivo é legítimo, atribuir a ele o acesso correto e revogar esse acesso de forma limpa quando algo muda.
É aí que muitas implantações de IoT ainda falham.
A conformidade mudou a conversa
O regime PSTI do Reino Unido e as orientações do NCSC exigem credenciais exclusivas por dispositivo e proíbem senhas padrão. Isso direciona o planejamento de protocolos além de uma simples discussão entre MQTT e CoAP, rumo a uma questão mais difícil: quais protocolos e plataformas tornam mais fácil impor a identidade do dispositivo, o gerenciamento do ciclo de vida dos certificados e o acesso com privilégio mínimo? Esse ângulo de conformidade costuma ser esquecido em análises gerais de protocolos, mas é central no contexto do Reino Unido discutido nesta revisão dos requisitos de segurança e políticas de IoT.
Credenciais padrão, chaves pré-compartilhadas comuns e confiança em rede única não escalam bem em locais multiusuário. Eles também tornam a resposta a incidentes complexa. Se um instalador conhece uma chave comum, ou se um dispositivo controlado por um locatário compartilha um acesso amplo, a contenção se torna mais difícil do que deveria ser.
Por que a identidade importa mais do que a pureza do protocolo
Um design de IoT seguro precisa que cada dispositivo responda a quatro perguntas de forma clara:
- Quem é você?
- Como você foi integrado?
- O que você tem permissão para acessar?
- Como posso revogar ou rotacionar a confiança sem interrupções?
É por isso que a autenticação baseada em certificados costuma ser mais defensável do que segredos compartilhados para propriedades corporativas sérias. Ela suporta uma identidade exclusiva por dispositivo, uma revogação mais limpa e um alinhamento muito melhor com a política de zero trust.
Para equipes acostumadas com o controle de acesso Wi-Fi tradicional, entender o que é um servidor RADIUS ajuda, pois o acesso baseado em identidade para dispositivos ainda depende de autenticação disciplinada e aplicação de políticas, mesmo quando o endpoint não é uma pessoa com um laptop.
Credenciais compartilhadas fazem o IoT parecer simples no momento da implantação e caro pelo resto de sua vida útil.
A pergunta sobre plataforma que as equipes empresariais devem fazer
Não pergunte apenas se um protocolo suporta criptografia. Pergunte se sua plataforma pode vincular a identidade do dispositivo à política, lógica de diretório, segmentação e controles de ciclo de vida.
Em ambientes mistos, isso pode envolver corretores, gateways, ferramentas de NAC, PKI e sistemas de integração de WiFi trabalhando juntos. Uma opção nessa camada de identidade mais ampla é a Purple, que suporta acesso sem senha, fluxos de integração baseados em certificados e integração com sistemas de identidade como Microsoft Entra ID, Google Workspace e Okta para funcionários e ambientes multi-tenant. O objetivo não é forçar um único protocolo. É dar a dispositivos e usuários diversos uma estrutura de confiança consistente.
Isso se torna especialmente importante em setores onde a falha tem um custo operacional mais alto. A área da saúde é um exemplo óbvio. Se você quiser uma visão mais ampla do setor, este artigo sobre IoT na área médica é útil porque os ambientes médicos mostram exatamente por que a identidade, a segmentação e o acesso controlado importam mais do que a conectividade bruta.
Construindo sua Estratégia Coesa de IoT
Não existe uma resposta única e ideal em termos de protocolos para IoT. Existe um conjunto de compensações, e uma boa arquitetura surge ao alinhar essas compensações com a tarefa necessária.
O padrão prático é simples. Use um modelo em camadas para que sua equipe saiba se está discutindo o comportamento do aplicativo, transporte, endereçamento ou conectividade física. Escolha mensagens leves onde os dispositivos forem limitados. Escolha a tecnologia de link certa para o edifício ou propriedade real, não para o laboratório. Deixe os protocolos mais complexos para os dispositivos que realmente precisam deles.
Como é uma abordagem empresarial madura
Uma estratégia sólida de IoT geralmente inclui:
- Diferentes protocolos para diferentes classes de dispositivos, em vez de um padrão forçado
- Um modelo comum de integração e política, para que as operações não se fragmentem
- Segmentação por função e risco, não apenas por hábito de VLAN
- Segurança focada em identidade, para que cada dispositivo possa ser autenticado, autorizado e revogado de forma limpa
É isso que transforma uma coleção desorganizada de sensores e endpoints inteligentes em uma plataforma gerenciável.
A maior mudança é mental. Pare de tratar a IoT como uma exceção de rede. Trate-a como parte de sua infraestrutura de identidade e acesso. Quando as equipes fazem isso, a seleção de protocolos se torna mais fácil, a integração se torna mais segura e o suporte de longo prazo fica muito mais previsível.
Se você está analisando como os dispositivos conectados se autenticam em ambientes de visitantes, colaboradores e IoT, o Purple merece ser avaliado como parte da camada de identidade. Ele oferece às equipes corporativas uma maneira de substituir senhas compartilhadas e onboarding fragmentado por um acesso sem senha baseado em políticas em locais multiusuários e parques de dispositivos mistos.
