A sua rede provavelmente já apresenta os sintomas. Chegaram alguns termóstatos inteligentes com um instalador. Os controladores de portas vieram com outro. O departamento de instalações adicionou sensores de fuga. O marketing quer contadores de tráfego de pessoas. As operações querem etiquetas de ativos. Dispositivos de convidados, tablets de funcionários, câmaras, quiosques e sistemas de edifícios precisam todos de conectividade, mas nem todos falam a mesma língua e, definitivamente, nem todos se comportam como portáteis.
É aí que muitos projetos de IoT empresariais começam a falhar. As equipas concentram-se no dispositivo, ou no rádio, ou no painel de controlo na cloud, e deixam o modelo de comunicação como uma reflexão tardia. Depois, o parque de dispositivos 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 diferentes.
A solução prática começa por compreender os protocolos para IoT. Não como um exercício de glossário, mas como um modelo operacional. Assim que souber que protocolo faz o quê, onde se situa na pilha e como afeta a integração, o isolamento e os custos de suporte, o caos torna-se controlável.
Domar o Caos dos Dispositivos Conetados
Num hotel, um problema de perda de pacotes numa rede de convidados pode parecer menor até que os controlos dos quartos partilhem o mesmo tempo de antena e comecem a falhar atualizações. No retalho, um contador de filas que reporta de poucos em poucos segundos tem necessidades muito diferentes de um leitor de sinalização digital que extrai conteúdos ricos. Num hospital ou num grande escritório, os sensores alimentados a bateria podem precisar de durar longos períodos, enquanto a infraestrutura fixa pode tolerar protocolos mais pesados e planos de controlo mais rigorosos.
O erro é tratar todos os dispositivos conetados como se pertencessem a um único design de rede padrão.
Por que razão 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 comunicam e quão ativos são na rede
- Quanta bateria consomem para enviar dados úteis
- Como são fáceis de integrar sem credenciais partilhadas
- Como escalam facilmente quando múltiplos sistemas precisam da mesma telemetria
- Como se integram de forma limpa com serviços de cloud, brokers, gateways e controlos de identidade
Para as equipas que gerem parques de dispositivos mistos, isto torna-se tanto um problema de suporte como de arquitetura. Se já está a lidar com um número crescente de endpoints conetados, a análise da Purple sobre quantos dispositivos estão conetados à internet é um lembrete útil de que o crescimento dos dispositivos não está a abrandar. Mais endpoints significam mais diversidade de protocolos, não menos.
Regra prática: Padronize o seu modelo de integração e segurança sempre que puder, mas não force cada tipo de dispositivo a usar o mesmo protocolo de comunicação.
O que é um bom modelo
Um ambiente de IoT viável apresenta geralmente 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 de estilo web se apenas precisarem de publicar alterações de estado.
Segundo, o protocolo adequa-se ao ambiente. Espaços interiores densos, edifícios de betão e locais multi-inquilino penalizam designs que pareciam adequados em condições de laboratório.
Terceiro, o protocolo suporta o modelo de segurança de que necessita. Se a sua equipa não conseguir atribuir uma identidade única, revogar acessos de forma limpa e segmentar dispositivos por função, o protocolo criará problemas futuros, mesmo que o projeto-piloto funcione.
Esta é a perspetiva a reter em todas as decisões sobre protocolos.
As Quatro Camadas da Comunicação de IoT
Quando as equipas ouvem nomes como MQTT, CoAP, Thread, LoRaWAN, TCP, UDP e WiFi na mesma reunião, a conversa costuma tornar-se confusa porque estes protocolos não resolvem todos o mesmo problema. A forma mais clara de os compreender é separá-los em camadas.
Pense na comunicação de IoT como o envio de uma encomenda.
A analogia da encomenda que realmente ajuda
- Camada de aplicação. Este é o artigo dentro do pacote. É o significado dos dados. Uma leitura de temperatura, um comando para abrir uma porta, uma atualização do estado do dispositivo.
- Camada de transporte. É assim que o pacote é manuseado. Pretende uma entrega confirmada ou quer que seja enviado rapidamente com menos custos adicionais?
- Camada de rede. Este é o endereço e a lógica de encaminhamento que faz chegar o pacote ao destino correto através das redes.
- Camada de ligação. Este é o veículo de entrega e o caminho local. O WiFi, a Ethernet, o Zigbee, o Thread, a IoT celular e outros métodos de conectividade local residem aqui.
Este modelo mental evita muitos debates de design desnecessários. Comparar o MQTT com o WiFi é como comparar o artigo na caixa com a carrinha que o transporta. Pertencem a camadas diferentes.
Porque é que as equipas empresariais precisam desta visão em camadas
Assim que visualizar a pilha de tecnologia de forma clara, a seleção do protocolo torna-se muito menos emocional. Pode misturar e combinar com base nas restrições, em vez de escolher um nome familiar e tentar usá-lo em todo o lado.
Por exemplo, um sensor de edifício pode utilizar um protocolo de aplicação leve, uma escolha de transporte adequada a mensagens pequenas, um caminho de rede baseado em IP através de um gateway e uma camada de ligação de baixo consumo dentro do edifício. Um câmara, por outro lado, pode estar ligada a Ethernet com fios ou WiFi e utilizar um padrão de aplicação completamente diferente.
Um marco importante neste espaço foi a padronização do MQTT como um padrão OASIS e do CoAP conforme definido no RFC 7252. Isso foi importante porque o mercado empresarial precisava de formas comuns e interoperáveis para lidar com dispositivos limitados. O pano de fundo é uma adoção ampla. A TechAhead citou dados que mostram que os dispositivos IoT foram utilizados por 29% das empresas da UE em 2021 no contexto da adoção empresarial e da padronização de protocolos, o que é relevante para as equipas do Reino Unido que planeiam a interoperabilidade e a segurança em ambientes digitais semelhantes ( EMQX no MQTT, CoAP e LwM2M ).
Uma stack simples que pode utilizar em revisões de design
| Camada | Pergunta a fazer | Exemplos típicos |
|---|---|---|
| Aplicação | O que significam os dados e como são partilhados? | MQTT, CoAP, HTTP, LwM2M |
| Transporte | Como é gerida a entrega? | TCP, UDP |
| Rede | Como é o tráfego endereçado e encaminhado? | Rede baseada em IP |
| Ligação | Como é que o dispositivo se liga fisicamente? | Ethernet, WiFi, Zigbee, Thread, LoRaWAN, NB-IoT |
Se uma revisão de design ficar bloqueada, faça primeiro uma pergunta: “De que camada estamos realmente a falar?” Isso costuma esclarecer a confusão rapidamente.
Comparar os Principais Protocolos de Aplicação e Transporte
No topo da stack, a decisão fundamental gira frequentemente em torno de como os dispositivos trocam dados com aplicações, brokers ou plataformas de gestão. As equipas empresariais sentem este impacto de forma mais direta porque estes protocolos determinam o estilo de mensagens, o esforço de integração e a quantidade de tráfego desnecessário que acaba na rede.
O mercado tem evoluído para opções mais leves por uma razão. Espera-se que os protocolos de IoT concebidos especificamente para o efeito, como o MQTT e o CoAP, aumentem 11% ao longo de dois anos, com a facilidade de utilização e a fiabilidade identificadas como os requisitos mais importantes pelos programadores, de acordo com a IoT Analytics sobre protocolos de IoT . Isso alinha-se com o que a maioria das equipas empresariais vê na prática. Os dispositivos limitados não beneficiam de carregar uma grande sobrecarga de protocolo apenas para dizer “a temperatura continua normal”.
Comparação de Protocolos de Aplicação e Transporte
| Protocolo | Modelo | Transporte Subjacente | Sobrecarga | Ideal Para |
|---|---|---|---|---|
| MQTT | Publicar e subscrever | Tipicamente TCP | Baixa | Telemetria, monitorização remota, distribuição de dados de muitos para muitos |
| CoAP | Pedido e resposta | Tipicamente UDP | Muito baixa | Dispositivos limitados, mensagens pequenas, interações locais de baixa latência |
| HTTP(S) | Pedido e resposta | TCP | Mais alto | Integração web, APIs, fluxos de trabalho adequados para navegadores |
| LwM2M | Orientado para gestão de dispositivos | Comumente utilizado com transportes leves | Baixo a moderado | Aprovisionamento, gestão do ciclo de vida, configuração remota |
O MQTT funciona quando muitos sistemas precisam dos mesmos dados
O MQTT é frequentemente o padrão para IoT empresarial por ser eficiente e operacionalmente limpo. Os dispositivos publicam mensagens em tópicos. Os sistemas interessados subscrevem. Isto significa que um único sensor pode alimentar a monitorização de instalações, análises, alertas e fluxos de trabalho de manutenção sem que cada consumidor tenha de consultar o dispositivo separadamente.
Para os setores da hotelaria e do retalho, isto é fundamental. Um sensor de refrigeração, um sensor de ocupação ou um medidor de energia precisam frequentemente de servir várias funções de back-end ao mesmo tempo. O MQTT faz isso de forma limpa.
O CoAP adapta-se a dispositivos muito pequenos e muito limitados
O CoAP é normalmente a melhor opção quando a dimensão do dispositivo é minúscula, o tráfego é simples e as mensagens leves baseadas em UDP são aceitáveis. É útil quando a baixa latência e a sobrecarga mínima importam mais do que um modelo de mensagens mais rico.
Dito isto, as equipas por vezes subestimam a sobrecarga de integração em torno do CoAP. Pode ser elegante do lado do dispositivo e complexo do lado empresarial se as suas ferramentas, brokers, pilha de observabilidade e controlos de segurança forem construídos com base em pressupostos 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 o seu lugar, mas não em todo o lado
O HTTP e o HTTPS continuam a ser úteis porque todas as equipas de cloud, programadores e plataformas de integração já os compreendem. Se o dispositivo precisar de chamar uma API REST, carregar payloads maiores ocasionalmente ou integrar-se num fluxo de trabalho de aplicação web existente, o HTTP pode ser a resposta certa.
O problema é o uso indevido. Um sensor alimentado a bateria que envia pequenas atualizações de estado através de um padrão pesado de pedido e resposta cria habitualmente uma sobrecarga evitável. Funciona, mas "funciona" e "funciona bem à escala" não são a mesma coisa.
O LwM2M ajuda quando a gestão é a prioridade
O LwM2M merece atenção quando o maior desafio não é a telemetria, mas sim as operações de frota. O aprovisionamento, as configurações remotas, o estado do software e a gestão do ciclo de vida tornam-se mais estruturados com um protocolo concebido para a gestão de dispositivos. Na prática, muitas organizações utilizam um protocolo para a telemetria e outra camada de gestão para funções de controlo e ciclo de vida.
Um teste empresarial que simplifica a teoria
Pergunte o seguinte: O dispositivo precisa de 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 o mais adequado
- Pegadas muito pequenas e trocas leves: O CoAP costuma ser a escolha ideal
- Integração direta de API e compatibilidade com browser/cloud: O HTTP(S) é mais adequado
- Gestão de frotas e controlo estruturado de dispositivos: O LwM2M merece ser analisado
Se o seu ambiente incluir vídeo, não confunda o envio de mensagens gerais de IoT com protocolos de streaming. Para equipas que avaliam fluxos de trabalho de câmaras, este manual sobre fluxos RTSP é útil porque o transporte de vídeo tem prioridades de design muito diferentes da telemetria de sensores de baixo consumo.
Navegar Pelos Protocolos de Rede e de Ligação
Uma vez escolhido o protocolo de aplicação, a questão prática mais difícil é muitas vezes como o dispositivo se liga à rede. Este desafio leva frequentemente à falha de projetos em edifícios, propriedades e locais de utilização mista. A pilha de protocolos pode parecer perfeita na camada de aplicação e, ainda assim, ter um desempenho inferior porque as escolhas de ligação e de rede foram erradas para o ambiente.
Edifícios densos precisam de uma resposta diferente de locais abertos
Para ambientes industriais e campus, as opções de malha de baixo consumo, como Zigbee e Thread, são adequadas para nós alimentados por bateria em espaços interiores densos, enquanto o LoRaWAN e o NB-IoT são mais indicados para telemetria a vários quilómetros de distância. O compromisso é entre largura de banda, latência e duração da bateria, e a resposta certa depende do caso de utilização real no Reino Unido, como a localização de ativos em espaços interiores versus a monitorização remota de propriedades, conforme descrito em este guia sobre protocolos de comunicação de IoT industrial .
Esse compromisso importa mais do que a preferência de fornecedor.
Como agrupo as escolhas de ligação no design empresarial
Curto alcance e maior largura de banda
O WiFi e a Ethernet pertencem aqui. São a escolha óbvia para dispositivos com energia constante, volumes de dados maiores ou integração simples de TI. Câmaras, quiosques, leitores de multimédia e equipamentos fixos enquadram-se habitualmente nesta categoria.
A desvantagem é o consumo de energia e a contenção do tempo de antena. Se colocar demasiados dispositivos de baixo valor e muito comunicativos na mesma infraestrutura sem fios que o tráfego crítico, criará os seus próprios pedidos de suporte.
Curto alcance e malha de baixo consumo
O Zigbee e o Thread fazem mais sentido quando os dispositivos são pequenos, alimentados a bateria e distribuídos por um edifício denso. Salas inteligentes, sensores de prateleiras, dispositivos de ocupação e monitorização ambiental enquadram-se frequentemente neste padrão.
A rede em malha pode ser excelente em espaços interiores, mas apenas quando as equipas planeiam a colocação de gateways, o comportamento de roaming e a interferência do ambiente de rádio circundante.
Longo alcance e rede alargada de baixo consumo
O LoRaWAN e o NB-IoT são a melhor opção quando o local é disperso, os dados são escassos e a eficiência da bateria importa mais do que o rendimento. Serviços públicos, propriedades, monitorização de perímetro e telemetria remota são exemplos comuns.
O ponto cego da equipa de rede
Muitos engenheiros de rede conhecem bem o lado do IP, mas não passaram muito tempo com redes de dispositivos limitados ou não tradicionais. Se a sua equipa precisa de uma reciclagem sobre conceitos fundamentais de encaminhamento e comutação antes de adicionar a complexidade de IoT, uma sólida preparação para o exame Cisco CCNA pode ajudar, porque grande parte da resolução de problemas de IoT ainda depende de bases sólidas de rede.
Para parques de IoT baseados em IP, o planeamento de endereços também importa mais do que muitas equipas esperam. O crescimento misto de terminais, a segmentação e os longos ciclos de vida dos dispositivos são boas razões para rever a diferença entre IPv6 e IPv4 antes que a implementação se torne demasiado grande.
Em IoT, a escolha do rádio raramente tem a ver com o "melhor alcance". Tem a ver com a sobrevivência do sinal ao edifício real, à interferência real e ao modelo de suporte real.
O que costuma funcionar e o que costuma falhar
- Funciona bem: WiFi para dispositivos alimentados com padrões de tráfego mais ricos
- Funciona bem: Zigbee ou Thread para parques densos de baterias em interiores
- Funciona bem: LoRaWAN ou NB-IoT para telemetria dispersa e de longo alcance
- Costuma falhar: um único padrão de conectividade forçado em todas as classes de dispositivos
- Costuma falhar: escolher com base em mapas de cobertura de laboratório em vez das condições do local
Este último ponto causa dores de cabeça intermináveis. Os materiais interiores, a densidade de utilizadores e o ruído de RF alteram a resposta.
Como Escolher o Protocolo Certo para o Seu Negócio
A maioria dos compradores pergunta qual é o melhor protocolo. Essa é a pergunta errada. A pergunta útil é qual o protocolo que melhor se adapta ao dispositivo, ambiente, padrão de tráfego e modelo de segurança que precisa de operar.
No Reino Unido, isso é especialmente importante porque a seleção do protocolo é frequentemente moldada por condições de rádio reais e não pelo alcance teórico. Os dados da Ofcom mostram uma forte utilização de bandas isentas de licença, e os dados governamentais destacam pontos sem cobertura móvel em interiores, o que significa que a penetração nas paredes, a interferência e a fiabilidade do backhaul importam frequentemente mais do que o título da folha de especificações. A Kore Wireless resume bem esse desafio na sua discussão sobre as compensações dos protocolos de IoT no Reino Unido .
Comece com a realidade física
Um hotel de betão, uma unidade de retalho com estrutura de aço e um local de serviços públicos ao ar livre não se comportam da mesma forma. Comece com o local, não com o diapositivo do fornecedor.
Pergunte:
- Onde ficará o dispositivo? Sala de máquinas, quarto, corredor, parque de estacionamento, telhado, limite do campus.
- O que bloqueia o sinal? Betão, metal, elevadores, unidades de refrigeração, elevada densidade de ocupação.
- Quem é o proprietário do backhaul? A sua equipa, um fornecedor gerido, terceiros ou um operador móvel.
Um protocolo que parece ideal numa sala de testes vazia pode falhar num edifício real cheio de interferências e movimento.
Alinhar o protocolo ao comportamento do negócio
Uma abordagem de seleção útil consiste em mapear cada caso de utilização para o conjunto mais pequeno de requisitos reais.
Termóstatos de hotel e sensores ambientais
Estes dispositivos costumam enviar pequenas atualizações, frequentemente em intervalos fixos ou alterações de estado. Não precisam de comunicação estilo web, mas precisam de um funcionamento estável e de uma gestão eficiente de bateria ou energia. Mensagens leves e uma disciplina de gateway local costumam superar designs pesados centrados em APIs.
Beacons de retalho e dispositivos de fluxo de visitantes
A densidade interior é o que importa aqui. Deve focar-se na coexistência, na duração da bateria e no funcionamento previsível em condições de RF congestionadas. Se os dispositivos estiverem espalhados por uma loja ou centro comercial, as opções de curto alcance e baixo consumo costumam fazer mais sentido do que colocar tudo em WiFi padrão.
Rastreadores de ativos em hospitais ou campus
A cobertura torna-se a parte mais difícil. Pontos mortos, materiais de construção e padrões de movimento importam mais do que as promessas das brochuras. Protocolos de telemetria de longo alcance podem ajudar em propriedades distribuídas, mas podem não ser adequados para localização interior detalhada ou atualizações frequentes.
Uma lista de verificação prática para decisão
- Orçamento de energia primeiro: Se o dispositivo funciona a bateria, exclua opções pesadas ou de comunicação constante logo de início.
- Padrão de tráfego a seguir: Pequenas e frequentes alterações de estado favorecem mensagens leves.
- A tolerância à latência é importante: Alguma monitorização pode tolerar atrasos. A segurança e o controlo geralmente não podem.
- O esforço de integração conta: Um protocolo que a sua equipa de plataforma já consegue proteger e monitorizar pode valer mais do que uma alternativa ligeiramente mais eficiente.
- O modelo de suporte decide a escala: Se as equipas no terreno não conseguirem substituir, reiniciar ou aprovisionar dispositivos de forma simples, o seu custo operacional aumenta rapidamente.
Regra de seleção: Escolha o protocolo que lhe proporciona 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. Utilizam uma família de protocolos para telemetria restrita, outra para aplicações mais ricas e um plano de gestão separado para identidade e política.
Unificar a Segurança IoT com a Identidade do Dispositivo
A maioria das discussões sobre protocolos termina demasiado cedo. Comparam o tamanho da mensagem, o uso da bateria e o alcance, e assumem depois que o problema de segurança pode ser adicionado mais tarde. Em ambientes empresariais, isso é o inverso. O principal desafio é provar que cada dispositivo é legítimo, atribuir-lhe o acesso correto e revogar esse acesso de forma limpa quando algo muda.
É aí que muitas implementações de IoT ainda falham.
A conformidade mudou a conversa
O regime PSTI do Reino Unido e as orientações do NCSC exigem credenciais únicas por dispositivo e proíbem palavras-passe predefinidas. Isso empurra o planeamento de protocolos para além de uma simples discussão entre MQTT e CoAP, direcionando-o para uma questão mais difícil: quais os protocolos e plataformas que facilitam a aplicação da identidade do dispositivo, a gestão do ciclo de vida dos certificados e o acesso com o menor privilégio possível? Esse ângulo de conformidade é frequentemente esquecido nas análises gerais de protocolos, mas é central no contexto do Reino Unido discutido nesta análise de requisitos de política e segurança de IoT.
Credenciais predefinidas, chaves pré-partilhadas partilhadas e confiança de rede plana não escalam bem em locais multiutilizador. Também tornam a resposta a incidentes complexa. Se um instalador conhece uma chave comum, ou se um dispositivo controlado por um inquilino partilha um acesso amplo, a contenção torna-se mais difícil do que deveria ser.
Por que a identidade importa mais do que a pureza do protocolo
Um design de IoT seguro necessita que cada dispositivo responda de forma limpa a quatro perguntas:
- Quem é você?
- Como foi integrada a sua ativação?
- A que lhe é permitido aceder?
- Como posso revogar ou rodar a confiança sem interrupções?
É por isso que a autenticação baseada em certificados é geralmente mais defensável do que segredos partilhados para propriedades empresariais sérias. Suporta uma identidade única por dispositivo, uma revogação mais limpa e um alinhamento muito melhor com a política de zero-trust.
Para as equipas habituadas ao controlo de acesso WiFi tradicional, compreender o que é um servidor RADIUS ajuda porque o acesso baseado em identidade para dispositivos ainda depende de uma autenticação disciplinada e da aplicação de políticas, mesmo quando o endpoint não é uma pessoa com um portátil.
As credenciais partilhadas fazem com que a IoT pareça simples no momento da implementação e cara durante o resto da sua vida útil.
A questão sobre plataformas que as equipas empresariais devem fazer
Não pergunte apenas se um protocolo suporta encriptação. Pergunte se a sua plataforma consegue associar a identidade do dispositivo à política, lógica de diretório, segmentação e controlos de ciclo de vida.
Em ambientes mistos, isso pode envolver corretores, gateways, ferramentas NAC, PKI e sistemas de integração de WiFi a trabalhar em conjunto. Uma opção nessa camada de identidade mais ampla é a Purple, que suporta acesso sem palavra-passe, fluxos de integração baseados em certificados e integração com sistemas de identidade como 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 utilizadores diversos uma estrutura de confiança consistente.
Isso torna-se especialmente importante em setores onde a falha tem um custo operacional mais elevado. A saúde é um exemplo óbvio. Se quiser uma perspetiva mais ampla do setor, este artigo sobre IoT na área médica é útil porque os ambientes médicos mostram exatamente porque é que a identidade, a segmentação e o acesso controlado importam mais do que a conetividade pura.
Construir a Sua Estratégia de IoT Coesa
Não existe uma única resposta ideal em termos de protocolos para IoT. Existe um conjunto de compromissos, e uma boa arquitetura surge ao alinhar esses compromissos com a tarefa a realizar.
O padrão útil é simples. Utilize um modelo em camadas para que a sua equipa saiba se está a discutir comportamento de aplicação, transporte, endereçamento ou conetividade física. Escolha mensagens leves onde os dispositivos sejam limitados. Escolha a tecnologia de ligação correta para o edifício ou propriedade real, e não para o laboratório. Reserve os protocolos mais complexos para os dispositivos que realmente precisam deles.
Como se caracteriza uma abordagem empresarial madura
Uma estratégia de IoT sólida inclui geralmente:
- Diferentes protocolos para diferentes classes de dispositivos, em vez de um padrão forçado
- Um modelo comum de integração e políticas, para que as operações não se fragmentem
- Segmentação por função e risco, e não apenas por hábito de VLAN
- Segurança focada na identidade, para que cada dispositivo possa ser autenticado, autorizado e revogado de forma limpa
É isso que transforma uma coleção desorganizada de sensores e pontos finais inteligentes numa plataforma gerível.
A maior mudança é mental. Deixe de tratar a IoT como uma exceção de rede. Trate-a como parte do seu ecossistema de identidade e acesso. Quando as equipas fazem isso, a seleção de protocolos torna-se mais fácil, a integração torna-se mais segura e o suporte a longo prazo torna-se muito mais previsível.
Se está a avaliar como os dispositivos ligados se autenticam em ambientes de convidados, funcionários e IoT, a Purple merece ser considerada como parte da camada de identidade. Oferece às equipas empresariais uma forma de substituir palavras-passe partilhadas e um onboarding fragmentado por um acesso sem palavra-passe, baseado em políticas, em recintos multiutilizador e frotas de dispositivos mistos.
