O Google Meet passou a usar criptografia pós-quântica (PQC) nas chamadas. A mudança foi anunciada em 12 de outubro de 2026 e começou pelos clientes web em laptops e pelo hardware de salas de reunião; o suporte no celular foi anunciado como “em breve”, sem data. Vale para todos os clientes do Google Workspace, para assinantes do Workspace Individual e para quem usa conta pessoal do Google. Não há nada para ativar: o Google aplica a atualização sozinho, e não existe controle no Admin console nem configuração para o usuário.
Para a empresa, o efeito prático é proteger o tráfego das reuniões de hoje contra um risco futuro: alguém gravar as chamadas cifradas agora e decifrá-las daqui a alguns anos, quando houver um computador quântico capaz disso.
Resumo rápido
- Desde 12 de outubro de 2026, chamadas do Meet em navegador de laptop e em hardware de sala usam criptografia pós-quântica, com liberação gradual de até 15 dias.
- Celular ainda não: o Google diz que o suporte móvel vem “em breve”, sem data confirmada.
- Administradores e usuários não precisam fazer nada, e não há chave para ligar ou desligar.
- O objetivo é neutralizar o ataque “colher agora, decifrar depois” (Store Now, Decrypt Later), em que dados interceptados hoje são guardados para quebra futura.
- A mudança protege o tráfego em trânsito. Gravações, links de convite, contas invadidas e dispositivos comprometidos continuam sendo responsabilidade da empresa.
O que o Google anunciou
O anúncio saiu no blog oficial de atualizações do Workspace. Segundo o Google, a expansão da PQC para todas as chamadas do Meet serve para proteger infraestrutura e serviços contra a ameaça potencial de um futuro computador quântico criptograficamente relevante. A própria empresa ressalta que esse computador não existe hoje. A mudança mira o tráfego atual, que poderia ser capturado e decifrado no futuro.
Os pontos confirmados no anúncio são estes:
- Onde começa: clientes web em laptops e hardware de salas de reunião.
- Celular: “em breve”, sem data.
- Ritmo: liberação gradual nos domínios Rapid Release e Scheduled Release a partir de 12 de outubro, com até 15 dias para a função aparecer.
- Quem recebe: todos os clientes do Google Workspace, assinantes do Workspace Individual e usuários com conta pessoal.
- Ação necessária: nenhuma. Não há controle de administrador nem configuração de usuário.
O post também lembra que o Meet já usava criptografia resistente a computação quântica nas chamadas com criptografia do lado do cliente (CSE). O que muda agora é a escala: a proteção deixa de ser exclusiva de quem configurou CSE e passa a valer para as chamadas comuns nos clientes cobertos.
Um detalhe que o anúncio não traz: qual algoritmo pós-quântico o Meet usa e em que camada do protocolo ele entra. O Google não detalhou isso no post. Em outros produtos, a empresa já usa o ML-KEM, padrão do NIST, em modo híbrido com o algoritmo clássico X25519, como no Chrome e nos endpoints google.com e googleapis.com. Pode ser o mesmo caminho no Meet, mas a empresa não confirmou.
“Colher agora, decifrar depois”: o risco por trás da mudança
A criptografia que protege a maior parte da internet hoje depende de problemas matemáticos que computadores comuns levariam tempo impraticável para resolver. Um computador quântico grande e estável o suficiente mudaria essa conta para parte desses algoritmos, principalmente os usados na troca de chaves e nas assinaturas digitais.
O ataque “colher agora, decifrar depois” (em inglês, Store Now, Decrypt Later ou Harvest Now, Decrypt Later) não espera essa máquina existir. A lógica é simples:
- Um atacante com acesso à rede (um provedor comprometido, um ponto de Wi-Fi malicioso, um agente estatal) grava o tráfego cifrado de hoje.
- Ele não consegue ler nada agora, então só armazena.
- Anos depois, com capacidade quântica suficiente, quebra a troca de chaves e recupera o conteúdo.
Por isso o risco vale hoje para quem lida com informação que precisa continuar sigilosa por muito tempo: estratégia de fusão e aquisição, segredos industriais, dados de saúde, processos judiciais, negociações de contrato.
O Google trata o tema com prazo. Em março de 2026, a empresa publicou um cronograma com meta de concluir a migração para criptografia pós-quântica até 2029, e afirmou que a ameaça à criptografia já é relevante hoje justamente por causa dos ataques de armazenar para decifrar depois. Em agosto de 2026, o Google Cloud detalhou o próprio roteiro, com meta de mitigar esse tipo de ataque até o fim de 2027.
Os padrões por trás da PQC
Criptografia pós-quântica não é criptografia quântica. São algoritmos que rodam em computadores comuns, mas se baseiam em problemas matemáticos para os quais não se conhece ataque eficiente nem por computador quântico. O NIST, órgão de padrões dos Estados Unidos, publicou os três primeiros padrões finalizados em 13 de agosto de 2024.
| Padrão | Algoritmo | Para que serve |
|---|---|---|
| FIPS 203 | ML-KEM (antigo CRYSTALS-Kyber) | Padrão principal para estabelecer chaves e cifrar comunicações |
| FIPS 204 | ML-DSA (antigo CRYSTALS-Dilithium) | Padrão principal para assinaturas digitais, que comprovam identidade |
| FIPS 205 | SLH-DSA (antigo SPHINCS+) | Assinaturas digitais com outra base matemática, como reserva caso o ML-DSA se mostre vulnerável |
Em março de 2025, o NIST escolheu o HQC como algoritmo reserva para cifragem, caso o ML-KEM venha a ser quebrado. O órgão deixou claro que ele não substitui o ML-KEM, que segue como recomendação principal, e previu o padrão final do HQC para 2027.
Na prática, o mercado adota o modo híbrido: combina o algoritmo clássico com o novo, e se um falhar o outro ainda protege a sessão. O Chrome faz isso desde a versão 131, com ML-KEM768 e X25519 na troca de chaves TLS.
O que muda (e o que não muda) na segurança do Meet
A PQC entra numa estrutura que já existia. Pela central de ajuda, as reuniões do Meet são cifradas por padrão em trânsito entre o dispositivo e os data centers do Google, seguindo os padrões IETF DTLS e SRTP, e as gravações são cifradas em repouso quando armazenadas no Google Drive. A tabela resume as camadas.
| Camada | O que faz | Quem tem | Ação da empresa |
|---|---|---|---|
| Criptografia em nuvem (padrão) | Cifra a chamada entre o dispositivo e o Google e os dados em repouso | Todos | Nenhuma |
| Criptografia pós-quântica (nova) | Protege o tráfego contra decifração futura por computador quântico | Todos, começando por web em laptop e hardware de sala | Nenhuma |
| Criptografia do lado do cliente (CSE) | O navegador de cada participante cifra a mídia com chaves que o Google não acessa | Enterprise Plus, Education Standard e Education Plus | Configurar provedor de identidade e serviço de chaves externos |
| Criptografia adicional de ponta a ponta | Opção de criptografia de ponta a ponta em chamadas | Contas pessoais, entre contas pessoais | Ativar manualmente |
O que a novidade não resolve:
- Gravações e transcrições: ficam no Drive, cifradas em repouso, mas acessíveis a quem tiver permissão no arquivo. Compartilhamento descuidado continua sendo o vazamento mais comum.
- Convidados indevidos: um link de reunião repassado por e-mail dá acesso à conversa, com ou sem PQC.
- Conta invadida: se alguém rouba a senha de um participante, entra na chamada como ele.
- Dispositivo comprometido: malware que captura tela e microfone lê a reunião antes de qualquer criptografia.
- Celular, por enquanto: participantes pelo app móvel ainda não estão cobertos pela PQC, segundo o anúncio.
O que o administrador precisa fazer
Para a PQC em si, nada. Mas a novidade é um bom gatilho para revisar o resto da segurança das reuniões. Uma lista enxuta:
- Navegadores atualizados: como a cobertura começou pelo cliente web, mantenha Chrome e demais navegadores na versão corrente por política de atualização automática.
- Hardware de sala: confira no Admin console se os dispositivos de sala recebem atualizações normalmente. Equipamento parado em versão antiga tende a ficar para trás em qualquer melhoria.
- Reuniões muito sensíveis no celular: até o suporte móvel chegar, considere orientar que conselhos, negociações e reuniões jurídicas sejam feitas pelo navegador do computador ou da sala.
- Verificação em duas etapas: exija 2FA, de preferência com chave de segurança ou passkey, para reduzir o risco de conta invadida.
- Gravações: defina quem pode gravar e onde as gravações ficam. Revise o compartilhamento das pastas de gravação.
- CSE para o topo da pirâmide: se a empresa tem edição elegível e um grupo que discute assuntos críticos, avalie a criptografia do lado do cliente. Ela tem custo operacional: exige convite para entrar, impede gravação, legendas, transcrição e vários recursos do Gemini, como as anotações automáticas.
Se a empresa usa os recursos de IA do Meet, como anotações e próximos passos gerados pelo Gemini, vale lembrar que esses resumos viram documentos no Drive e seguem as mesmas regras de permissão. O artigo sobre próximos passos no Google Meet mostra como esse fluxo funciona, e a página de integrações do Google Gemini reúne as demais conexões com o Workspace.
Relação com a LGPD
A LGPD não fala em criptografia pós-quântica, mas cria o dever que essa mudança ajuda a cumprir. O artigo 46 determina que os agentes de tratamento adotem “medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito”. O artigo 47 estende a obrigação de garantir a segurança da informação “mesmo após o seu término”, e o artigo 48 obriga a comunicar à ANPD e ao titular incidentes que possam causar risco ou dano relevante.
Três leituras práticas para o gestor:
- Documente: registre a mudança no inventário de controles de segurança e no relatório de impacto (RIPD), se a empresa trata dados sensíveis em reuniões, como saúde ou dados de menores.
- Não superestime: a PQC no Meet não cobre o celular ainda, nem gravações compartilhadas por engano. O argumento de “medida apta” vale para o que ela de fato protege.
- Pense em prazo de sigilo: a ideia de proteger dados “mesmo após o seu término” combina com o raciocínio do ataque de colher agora e decifrar depois. Dados com vida longa pedem proteção pensada para o longo prazo.
Para um panorama mais amplo, veja o guia de LGPD e IA na empresa e o resumo do que a ANPD já orientou sobre IA e dados pessoais.
Exemplo: escritório de advocacia em Belo Horizonte
Imagine um escritório de advocacia empresarial em Belo Horizonte, com 40 pessoas no Google Workspace, que faz reuniões semanais com clientes sobre operações de compra de empresas. Parte das conversas acontece no navegador do computador, parte na sala de reunião com hardware do Meet e parte no celular, quando o sócio está em trânsito.
Com a novidade, as reuniões pelo navegador e pela sala passam a ter proteção pós-quântica sem nenhuma configuração. O responsável de TI aproveita para fazer três ajustes: confirma que o hardware da sala está recebendo atualizações, envia um comunicado interno pedindo que reuniões de negociação sejam feitas pelo computador até o suporte móvel chegar, e revisa a pasta de gravações, restringindo o acesso a cada equipe de caso.
Como o escritório usa a edição Enterprise Plus, o comitê de sócios também avalia a CSE para as reuniões de due diligence mais delicadas, aceitando perder gravação e transcrição nessas sessões. O encarregado de dados registra as mudanças no inventário de controles.
Erros comuns
- Achar que a reunião virou “inviolável”: a PQC protege contra decifração futura do tráfego. Conta invadida, link vazado e gravação compartilhada continuam abertos.
- Esquecer o celular: o anúncio deixa claro que o suporte móvel ainda não chegou. Quem participa pelo app não tem a mesma proteção por enquanto.
- Procurar a opção no Admin console: não existe controle. Tempo gasto procurando a chave é tempo perdido.
- Confundir com criptografia de ponta a ponta: PQC e CSE são coisas diferentes. A PQC muda o tipo de algoritmo; a CSE muda quem tem as chaves.
- Afirmar que o Meet usa algoritmo X ou Y: o Google não detalhou o algoritmo no anúncio. Em documentos de compliance, cite o que foi publicado.
Perguntas frequentes
Preciso ativar a criptografia pós-quântica no Google Meet?
Não. O Google aplica a atualização automaticamente e informa que não há controle para administradores nem configuração para usuários finais.
A proteção já vale no aplicativo do celular?
Ainda não. O anúncio de 12 de outubro de 2026 cobre clientes web em laptops e hardware de salas de reunião, e diz que o suporte móvel vem “em breve”, sem data confirmada.
Contas gratuitas também recebem a novidade?
Sim. Segundo o Google, a mudança vale para todos os clientes do Google Workspace, assinantes do Workspace Individual e usuários com conta pessoal do Google.
Computadores quânticos já conseguem quebrar a criptografia atual?
Não. O próprio Google afirma que um computador quântico criptograficamente relevante não existe hoje. A mudança protege o tráfego atual contra quem o grave agora para tentar decifrar no futuro.
A PQC substitui a criptografia do lado do cliente?
Não. A CSE, disponível em edições como Enterprise Plus, mantém as chaves sob controle da empresa e impede que o Google leia a mídia. A PQC fortalece a criptografia padrão. São camadas complementares.
Isso ajuda a cumprir a LGPD?
Ajuda a sustentar o dever de adotar medidas de segurança técnicas do artigo 46, desde que documentado e sem exagerar o alcance. A lei não exige PQC especificamente, e a responsabilidade por permissões, gravações e contas continua com a empresa.
Fontes e leitura recomendada
- Google Workspace Updates: Google Meet now uses post-quantum cryptography
- Ajuda do Google Meet: criptografia de chamadas e reuniões
- Ajuda do Google Meet: criptografia do lado do cliente (CSE)
- Google: cronograma de migração para criptografia pós-quântica
- Google Cloud: PQC in Plaintext, roteiro pós-quântico
- Google Security Blog: A new path for Kyber on the web
- NIST: primeiros três padrões de criptografia pós-quântica
- NIST FIPS 203 (ML-KEM)
- NIST: seleção do HQC como algoritmo reserva
- Lei Geral de Proteção de Dados (Lei 13.709/2018)
