O que é Sovereign UEM?

Em janeiro de 2026, o Gartner renomeou formalmente seu tradicional Magic Quadrant 'Unified Endpoint Management Tools' para 'Endpoint Management Tools'. O novo modelo divide a categoria em quatro casos de uso principais: gerenciamento de aparelhos corporativos, BYOD, aparelhos de trabalhadores da linha de frente e segurança física de endpoints. A mudança de nome importa menos do que a admissão que ela representa: a premissa de que um único stack de fornecedor — normalmente construído sobre os serviços Android Enterprise do Google ou sobre um SaaS de MDM de terceiros para Apple — poderia atender de forma uniforme a todos os cenários de endpoints corporativos ruiu silenciosamente.

O mercado amadureceu, mas as premissas arquiteturais por baixo dele, não. Todos os grandes fornecedores de UEM da categoria renomeada — Microsoft Intune, Jamf, VMware Workspace ONE, IBM MaaS360, ManageEngine — operam como uma camada SaaS de terceiros entre o cliente e sua frota. No Android, isso significa rotear cada comando pela Android Management API (AMAPI) do Google e aceitar o controle do Google sobre quais aparelhos, OEMs e padrões de política são permitidos. Na Apple, significa entregar os dados dos aparelhos do cliente ao MDM em nuvem de um fornecedor que faz a intermediação entre o tenant do Apple Business Manager do cliente e os aparelhos em campo.

Essa não foi uma escolha arquitetural que alguém projetou deliberadamente. Foi o caminho mais fácil para fornecedores que queriam lançar produto rápido. Mas, para um conjunto crescente de compradores corporativos — setores regulados, compras do setor público, operadores de mercados emergentes, contratos de residência de dados atentos à soberania —, esse caminho já não é aceitável.

O que o substitui não é outro fornecedor de UEM. É uma categoria diferente. Nós a chamamos de Sovereign UEM: Gerenciamento Unificado de Endpoints que roda sobre APIs públicas, e não sobre programas de parceiros de fornecedores, e que coloca o cliente — e não um provedor SaaS terceirizado — no caminho dos dados entre a intenção do comando e a execução no aparelho.

Este artigo é a referência definitiva sobre o que é Sovereign UEM, por que essa categoria importa agora mais do que em qualquer momento anterior da história do mercado de UEM e como a Lockia a implementa em frotas de aparelhos Android e Apple.

Para entender por que Sovereign UEM é uma categoria coerente, e não apenas um reposicionamento de marketing, é preciso ser específico sobre quais dependências os fornecedores tradicionais de UEM carregam — e quanto essas dependências custam ao cliente.

Dependência do Google AMAPI no Android. A maior parte do gerenciamento corporativo de aparelhos Android hoje passa pela Android Management API, a alternativa moderna do Google ao antigo framework Device Policy Controller. A AMAPI é tecnicamente excelente. Ela também exige que o fornecedor de UEM seja parceiro Android Enterprise certificado pelo Google e roteia cada comando pelo Firebase Cloud Messaging (FCM) e pela camada de aplicação de políticas do Google. O processo de certificação é controlado pelo Google. O roadmap é controlado pelo Google. O conjunto de recursos de hardware de OEM que a API expõe é controlado pelo Google. Quando um fornecedor de UEM vende a você "gerenciamento de aparelhos Android", o que ele vende é o relacionamento com você, como cliente, somado à licença dele para operar dentro do programa de parceiros do Google. Se o Google descontinuar uma parte da API, todo UEM construído sobre AMAPI perde essa capacidade ao mesmo tempo.

Para a maioria das empresas, essa dependência é invisível e aceitável. Em contextos de compra com requisitos de residência de dados no país, aceitar que cada comando enviado a um aparelho seja autenticado pela infraestrutura americana do Google não é um inconveniente arquitetural — é um motivo de desclassificação. Para operadores multinacionais da América Latina que gerenciam portfólios de programas de aparelhos em diferentes moedas e sob diferentes reguladores bancários, aceitar que o Google possa arbitrar quais aparelhos recebem políticas e em que prazo é um risco estratégico de concentração. A dependência é invisível até o dia em que deixa de ser.

Dependência de SaaS de MDM para Apple no iOS. A Apple publica abertamente o protocolo Mobile Device Management. Qualquer organização pode ler a especificação e implementar um servidor MDM. Na prática, pouquíssimas fazem isso — porque construir, escalar e operar um servidor MDM de produção é um trabalho de infraestrutura pouco glamoroso, e a maioria dos clientes corporativos prefere consumir MDM como SaaS. Então, eles assinam com Jamf, Intune, Mosyle, Workspace ONE ou um dos vários provedores menores de MDM SaaS. Cada um desses fornecedores opera seu próprio servidor MDM em sua própria nuvem, entre o tenant do Apple Business Manager do cliente e os aparelhos nas mãos do cliente.

A dependência é real, mas sutilmente diferente da do Google. O Apple Push Notification service (APNs — a infraestrutura obrigatória da Apple para qualquer MDM de iOS) está no centro do caminho de comando do iOS — todo comando MDM para um aparelho iOS passa pelo APNs, ponto, sem alternativa arquitetural. Essa parte é inegociável e vale para qualquer servidor MDM, inclusive o nosso. O que é negociável é se um provedor SaaS terceirizado também fica nesse caminho. A maioria das empresas hoje responde a essa pergunta por padrão: sim, meu fornecedor de MDM opera o servidor. O resultado é que a telemetria dos aparelhos do cliente, o histórico de comandos, os metadados de registro e o estado das políticas passam todos pela nuvem do fornecedor SaaS, na jurisdição do fornecedor SaaS, sob os termos de tratamento de dados do fornecedor SaaS.

Para uma empresa americana sem preocupações específicas, tudo bem. Para redes de saúde reguladas pela LGPD ou pela HIPAA, compradores do setor público com requisitos de soberania ou qualquer organização cujos contratos de tratamento de dados não possam incluir um SaaS americano na cadeia de custódia, isso inviabiliza o negócio.

O problema da dependência não é teórico. É o motivo pelo qual um número crescente de empresas reguladas e de mercados emergentes vem buscando, discretamente, arquiteturas de gerenciamento de endpoints que contornem o SaaS de terceiros — e descobrindo que a lista dos principais fornecedores de UEM não traz uma resposta.

Sovereign UEM é uma postura arquitetural específica, não um enquadramento de marketing. Para se qualificar como Sovereign UEM, uma plataforma precisa atender a três requisitos concretos:

1. Caminho de dados controlado pelo cliente. Nenhum provedor SaaS terceirizado fica entre o cliente e seus aparelhos para comandos, telemetria ou políticas. O fornecedor de Sovereign UEM opera a plataforma, mas os dados dos aparelhos do cliente passam por infraestrutura implantada em jurisdições e sob termos que os contratos de compra do cliente podem governar — normalmente uma implantação em nuvem soberana ou em tenant dedicado na região exigida pelo cliente.

2. Camada independente de identidade e políticas. A autenticação e a aplicação de políticas não exigem participação no programa de parceiros certificados de um fornecedor. No Android, isso significa que a plataforma é construída sobre APIs públicas do AOSP, e não sobre a Android Management API do Google. Na Apple, significa que o fornecedor da plataforma implementa diretamente o protocolo MDM publicado e opera o servidor MDM — e não atua como uma camada de revenda sobre o MDM SaaS de outro fornecedor.

3. Infraestrutura com hospedagem soberana e região de implantação alinhada ao cliente. O cliente pode escolher a região de implantação e a jurisdição regulatória. Isso não é "hospedamos na AWS em Frankfurt" — isso é uma escolha de hospedagem, não uma escolha de soberania. Sovereign UEM significa que o fornecedor da plataforma opera infraestrutura na jurisdição exigida pelo cliente, sob termos de implantação que os contratos do cliente podem governar, e não apenas na região de nuvem que o SaaS do fornecedor por acaso utiliza.

Sovereign UEM é uma categoria emergente. Duas organizações são exemplos iniciais confiáveis. A Applivery, na UE, construiu uma plataforma MDM com posicionamento explícito de soberania para o setor público europeu. A Lockia, nas Américas, construiu a arquitetura descrita neste artigo. Ambas compartilham a convicção de que o stack de UEM predominante confia demais nos hyperscalers americanos e de menos na infraestrutura controlada pelo cliente.

A categoria vai crescer. À medida que empresas de mercados emergentes, setores regulados e setores públicos atentos à soberania continuarem contratando gerenciamento de endpoints em escala, a lista de fornecedores vai incluir — e exigir cada vez mais — plataformas Sovereign UEM. Este artigo é uma das primeiras vozes a articular o que a categoria exige.

A implementação de Sovereign UEM da Lockia abrange quatro camadas arquiteturais: um componente no aparelho Android, uma integração no aparelho Apple, um protocolo ancorado em hardware e uma camada agêntica de políticas. Cada camada é soberana de forma independente, no sentido definido acima; a integração das quatro é o que torna a plataforma da Lockia unificada.

Android: Lockia Cipher DPC. O Lockia Cipher DPC é um Device Policy Controller construído diretamente sobre as APIs públicas do AOSP. Ele não exige certificação do Google como parceiro Android Enterprise, porque não usa AMAPI. O DPC é registrado como Device Owner na primeira inicialização, comunica-se com o backend da Lockia por um transporte de push independente e aplica políticas sem depender dos serviços do Google como transporte.

Na maioria dos aparelhos Android em campo, o Google Play Services continua instalado e os aplicativos voltados ao usuário funcionam normalmente. Mas o caminho de aplicação de políticas é independente. O canal de comando e a aplicação central de políticas da Lockia continuam operando de forma independente dos serviços do Google. Alguns recursos do aparelho que dependem do Play Services (em especial as atestações do Play Integrity) exigem que o Play Services esteja presente, mas o registro central, os comandos e o bloqueio da restauração de fábrica não. Essa é a diferença arquitetural entre os UEMs construídos sobre AMAPI e o Sovereign UEM: neste último, a infraestrutura do Google não é um ponto único de falha para o comando da frota.

Apple: Lockia Cipher MDM. A Lockia opera o Cipher MDM na sua região de implantação — sem SaaS de MDM de terceiros no seu caminho de dados. Seu tenant do Apple Business Manager é federado com o MDM operado pela Lockia. O fluxo de comando de um aparelho iOS sob gerenciamento da Lockia é: aparelho Apple → APNs → servidor MDM operado pela Lockia → camada de políticas do cliente no backend da Lockia.

O APNs da Apple é, como mencionado antes, uma infraestrutura inegociável para qualquer MDM. O que a arquitetura da Lockia elimina é a camada adicional de MDM SaaS de terceiros que os clientes de Jamf, Intune ou fornecedores comparáveis precisam aceitar. Não há nuvem da Mosyle entre o tenant ABM do cliente e a frota de aparelhos. Não há SaaS multi-tenant do Workspace ONE armazenando os metadados de registro do cliente. O servidor MDM é operado pela Lockia, em regiões que o cliente pode especificar, sob termos que os contratos de compra do cliente podem governar.

Âncora de hardware: Cipher Protocol. As integrações com Android e Apple ficam sobre o Cipher Protocol, a arquitetura com patente pendente da Lockia para identidade de aparelho ancorada em hardware e bloqueio da restauração de fábrica. Os caminhos padrão de burla — modo de recuperação, restauração de fábrica — são bloqueados na camada de atestação de hardware. A patente — pedido provisório USPTO 63/940,826, "Bypass-Resistant Device Locking" — descreve a abordagem em múltiplas camadas de bloqueio da restauração de fábrica que diferencia o Cipher do controle de aparelhos apenas por software.

Camada agêntica: Guardian AI. Acima das camadas de comando e de aplicação de políticas, a Lockia opera o Guardian AI: um sistema de detecção comportamental de ameaças que analisa a telemetria da frota do cliente, na região de implantação do cliente, sem exigir o envio de dados do cliente a provedores externos de ML.

Presença de infraestrutura. Infraestrutura multirregião em operação em Miami, México, Brasil e Colômbia, com novas regiões sendo adicionadas. A Lockia opera a plataforma; a implantação na região do cliente está disponível para contratos de compra sujeitos a soberania. A Lockia opera como uma Florida LLC; a conversão para Delaware C-Corp está em andamento.

Tenant em cinco minutos. Não uma implementação de 90 dias. A Lockia provisiona um tenant funcional em cinco minutos. Sem instalação de servidor local. Sem taxa de implantação de milhares de dólares. Sem ciclo de integração de 90 dias. O operador se integra às APIs da Lockia; a Lockia opera a plataforma por baixo.

Essa é a consequência arquitetural de a Lockia ser operada pela Lockia, e não instalada nas dependências do cliente. Os fornecedores convencionais de MDM exigem que o cliente monte um servidor, negocie ciclos de compra que levam de semanas a meses, pague taxas de implantação que criam barreiras de investimento de capital que operadores menores não conseguem absorver e mantenha o servidor durante toda a vigência do contrato. A arquitetura da Lockia inverte isso: a plataforma é uma infraestrutura multi-tenant operada pela Lockia; o operador se integra via API; o único custo de infraestrutura do lado do operador é o tempo dos desenvolvedores para conectar as integrações.

Essas camadas — Cipher DPC, Cipher MDM, Cipher Protocol, Guardian AI — formam juntas a implementação de Sovereign UEM da Lockia. Cada uma é independente; integradas, elas entregam a plataforma.

A mesma infraestrutura da Lockia atende varejistas, bancos, operadores de e-commerce e revendedores que mantêm programas de aparelhos, e foi projetada para verticais adicionais — incluindo operadoras, saúde e setor público — com os quais há conversas em andamento. Uma plataforma é uma capacidade horizontal; verticais são os contextos contratuais que essa capacidade atende. A plataforma Sovereign UEM da Lockia é o mesmo software, qualquer que seja o vertical. O que muda por vertical é a configuração de políticas, o sistema de faturamento ou de operações com o qual a plataforma se integra e as ações de aplicação específicas que os clientes conectam aos seus fluxos de trabalho.

Financiamento de aparelhos. Vendas de celulares parceladas, contratos BNPL de aparelhos e leasing de aparelhos em mercados emergentes compartilham um requisito comum: um controle de aparelhos que bloqueia as tentativas óbvias de burla (restauração de fábrica, modo de recuperação, troca de SIM) e se integra a um sistema de faturamento ou de cobrança. A camada de aplicação da Lockia vincula o status de pagamento a um estado de bloqueio gradual. Saiba mais sobre soluções de financiamento de aparelhos.

Proteção de subsídios de operadoras. A arquitetura da Lockia foi projetada para contextos de proteção de subsídios de MNOs e MVNOs. A recuperação de subsídios, o controle de bloqueio de SIM nas transições entre operadoras e a integração com sistemas de faturamento e CRM são questões específicas do vertical que a plataforma trata. Veja proteção de subsídios de operadoras.

Setor público e setores regulados. Redes de saúde sujeitas à HIPAA ou à LGPD, instituições financeiras com requisitos de residência de dados do regulador bancário, órgãos governamentais com mandatos de soberania e sistemas de ensino que distribuem aparelhos 1:1 para estudantes compartilham restrições de compra que os fornecedores tradicionais de UEM SaaS americanos não conseguem atender. Para esse segmento, o Sovereign UEM costuma ser a única arquitetura contratualmente viável.

Esses verticais não são produtos separados. São configurações da mesma plataforma, vendidas diante de diferentes objeções de compra e diferentes fluxos operacionais. A implicação econômica para a Lockia é significativa: uma equipe de engenharia, um produto, uma plataforma, vários segmentos de clientes de alto valor.

Para evitar que o termo "Sovereign UEM" seja adotado como fachada de marketing por fornecedores que não construíram de fato a arquitetura, vale ser explícito sobre o que não se qualifica.

Não é "hospedamos na AWS em vez do GCP". Soberania é uma propriedade arquitetural — sobre quem está no caminho dos dados —, não uma escolha de provedor de nuvem. Um UEM que roda na AWS em Frankfurt, mas ainda roteia os comandos do Android pelo Google AMAPI, não é Sovereign UEM. É um UEM hospedado na AWS.

Não é revenda de Knox, wrapper de AMAPI nem integração com Intune. Se o controle subjacente dos aparelhos depende do Samsung Knox, do Google AMAPI ou do Microsoft Intune como base, o fornecedor está revendendo os programas de parceiros dessas bases — e não construindo um gerenciamento de endpoints independente.

Não é "soberania só no MDM, Google AMAPI no Android". Meia soberania não é soberania. Uma plataforma que opera o servidor MDM de forma independente para Apple, mas ainda roteia o Android pelo programa de parceiros do Google, herda todos os riscos de dependência do Google que a arquitetura deveria eliminar. Os dois lados do parque de aparelhos importam.

Não é uma ferramenta de bloqueio exclusiva para financiamento. Sovereign UEM é a plataforma; o financiamento de aparelhos é um dos verticais que a plataforma atende. Fornecedores que se posicionam como "soluções de financiamento de aparelhos" sem articular uma plataforma horizontal são ferramentas de escopo vertical, não plataformas Sovereign UEM.

Não é código fechado nem mágica. A implementação da Lockia é construída sobre APIs públicas que a Apple e o Google publicam. A diferenciação está na arquitetura, na integração e no modelo de implantação controlado pelo cliente — e não em protocolos proprietários que os clientes não possam inspecionar ou auditar.

Operado pela Lockia, não pelo cliente. Sovereign UEM é operado pelo fornecedor da plataforma — no nosso caso, a Lockia — em jurisdições e sob termos contratuais que o cliente governa. Os clientes não operam a plataforma por conta própria. A soberania diz respeito a quem está no caminho dos dados e onde a infraestrutura fica, não a transferir a responsabilidade operacional para o cliente.

O gerenciamento corporativo de endpoints não precisa ser uma relação com um porteiro SaaS do Google ou da Apple. As alternativas arquiteturais existem; a única limitação tem sido a disposição dos fornecedores em investir para construí-las. A plataforma Sovereign UEM da Lockia é uma implementação confiável, projetada para os segmentos de clientes que os fornecedores tradicionais de UEM não conseguem atender.

Para empresas que avaliam o gerenciamento de endpoints em escala — principalmente em setores regulados, compras do setor público, mercados emergentes ou qualquer contexto em que a soberania sobre o caminho dos dados seja um requisito de compra —, Sovereign UEM já não é uma categoria teórica. É uma arquitetura implantável por contrato.

Se você atua em um desses contextos, o próximo passo é uma revisão de arquitetura com a Lockia. Vamos analisar o seu parque específico de aparelhos Android e Apple, os seus requisitos de residência de dados e como as opções de implantação da Lockia se alinham às suas restrições de compra.