{"id":2357,"date":"2026-08-20T17:17:32","date_gmt":"2026-08-20T20:17:32","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/08\/20\/cloudflare-access-atualizacao-oauth-workers-e-zero-trust\/"},"modified":"2026-08-20T17:17:32","modified_gmt":"2026-08-20T20:17:32","slug":"cloudflare-access-atualizacao-oauth-workers-e-zero-trust","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/08\/20\/cloudflare-access-atualizacao-oauth-workers-e-zero-trust\/","title":{"rendered":"Cloudflare Access atualiza\u00e7\u00e3o: OAuth, Workers e Zero Trust"},"content":{"rendered":"

A Cloudflare Access atualiza\u00e7\u00e3o<\/strong> de agosto de 2026 chega em um momento decisivo para a consolida\u00e7\u00e3o do modelo Zero Trust no mercado de CDN, edge computing e seguran\u00e7a web. Com uma rede que ultrapassa 300 cidades em mais de 100 pa\u00edses<\/strong> e responde por aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP da internet<\/strong>, a Cloudflare deixou de ser apenas uma provedora de cache e mitiga\u00e7\u00e3o de DDoS para se tornar uma plataforma de conectividade segura de ponta a ponta. O Cloudflare Access<\/strong>, carro-chefe da su\u00edte Cloudflare One, \u00e9 hoje um dos substitutos de VPN mais adotados por empresas que precisam proteger aplica\u00e7\u00f5es internas, ambientes de desenvolvimento e workloads distribu\u00eddos sem expor portas de origem. As atualiza\u00e7\u00f5es divulgadas em agosto de 2026 \u2014 com destaque para OAuth com escopos opcionais em disponibilidade geral<\/strong>, Access for Workers<\/strong> e melhorias no Cloudflare One Client<\/strong> \u2014 redefinem como administradores de TI aplicam least-privilege, protegem aplica\u00e7\u00f5es serverless e gerenciam a experi\u00eancia de autentica\u00e7\u00e3o em endpoints corporativos.<\/p>\n

Historicamente, o Access evoluiu de uma ferramenta de prote\u00e7\u00e3o de aplica\u00e7\u00f5es internas via identidade para um componente central da estrat\u00e9gia SASE da Cloudflare. Em 2020, a integra\u00e7\u00e3o com provedores como Okta, Google Workspace e Azure AD<\/strong> eliminou a necessidade de VPNs tradicionais para acesso a ferramentas administrativas. Nos anos seguintes, a Cloudflare adicionou suporte a pol\u00edticas baseadas em dispositivo, isolamento de navegador e prote\u00e7\u00e3o de t\u00faneis com WARP<\/strong>. A atualiza\u00e7\u00e3o de 2026 aprofunda esse legado ao atacar dois gargalos persistentes: a granularidade do consentimento OAuth e a prote\u00e7\u00e3o de aplica\u00e7\u00f5es criadas com c\u00f3digo r\u00e1pido \u2014 as chamadas vibe-coded applications<\/em> \u2014 que muitas vezes ficam fora do per\u00edmetro de seguran\u00e7a corporativo. Para o leitor t\u00e9cnico brasileiro, essas mudan\u00e7as t\u00eam implica\u00e7\u00f5es diretas em conformidade com a LGPD<\/strong>, redu\u00e7\u00e3o de superf\u00edcie de ataque e simplifica\u00e7\u00e3o operacional em ambientes multinuvem.<\/p>\n

Neste post, voc\u00ea vai entender o que mudou no Cloudflare Access<\/strong>, como funcionam os novos escopos opcionais de OAuth, por que o Access for Workers<\/strong> elimina a fric\u00e7\u00e3o de proteger serverless functions, e como as vers\u00f5es est\u00e1veis do Cloudflare One Client para Windows, macOS e Linux<\/strong> melhoram a resili\u00eancia de autentica\u00e7\u00e3o e conectividade. Tamb\u00e9m analisamos o impacto do hardening do WAF na detec\u00e7\u00e3o de credenciais vazadas em cabe\u00e7alhos Authorization<\/code>, as janelas de manuten\u00e7\u00e3o programada de IAM e data centers, e o posicionamento da Cloudflare diante de concorrentes como Akamai, Fastly e AWS CloudFront<\/strong>. Ao final, apresentamos recomenda\u00e7\u00f5es pr\u00e1ticas para administradores e desenvolvedores que operam infraestrutura no Brasil.<\/p>\n

O ecossistema de edge computing em 2026 est\u00e1 cada vez mais pressionado por tr\u00eas vetores: lat\u00eancia<\/strong>, seguran\u00e7a de identidade<\/strong> e conformidade regulat\u00f3ria<\/strong>. A Cloudflare responde a esses vetores com uma abordagem integrada que combina CDN, WAF, Zero Trust e plataforma de desenvolvimento na borda. As atualiza\u00e7\u00f5es do Access n\u00e3o s\u00e3o isoladas: elas se conectam ao Workers runtime<\/strong>, ao Gateway<\/strong> e ao WARP<\/strong>, criando um tecido de seguran\u00e7a que acompanha a aplica\u00e7\u00e3o desde o c\u00f3digo at\u00e9 o dispositivo do usu\u00e1rio. Para empresas brasileiras que precisam escalar opera\u00e7\u00f5es sem multiplicar ferramentas, entender essas integra\u00e7\u00f5es \u00e9 essencial para reduzir custos operacionais e evitar configura\u00e7\u00f5es fr\u00e1geis que exp\u00f5em dados sens\u00edveis.<\/p>\n

A seguir, detalhamos o changelog completo, os impactos pr\u00e1ticos e as recomenda\u00e7\u00f5es da JRT Technology Solutions<\/strong>, que implementa e gerencia Cloudflare para clientes corporativos no Brasil, cobrindo CDN, WAF, Zero Trust e Workers.<\/p>\n

O que aconteceu com o Cloudflare Access atualiza\u00e7\u00e3o em agosto de 2026<\/h3>\n

O m\u00eas de agosto de 2026 trouxe uma s\u00e9rie de an\u00fancios e changelogs que, juntos, comp\u00f5em a Cloudflare Access atualiza\u00e7\u00e3o<\/strong> mais significativa do ano. O destaque principal \u00e9 a disponibilidade geral dos Optional OAuth Scopes<\/strong>, anunciada no Cloudflare Blog e detalhada no changelog de Cloudflare Fundamentals. Com essa novidade, desenvolvedores de clientes OAuth podem classificar escopos configurados como obrigat\u00f3rios<\/strong> ou opcionais<\/strong> diretamente no dashboard da Cloudflare. Na tela de consentimento, o usu\u00e1rio final passa a ter controle granular: escopos obrigat\u00f3rios devem ser concedidos, enquanto escopos opcionais podem ser recusados sem bloquear o fluxo de autoriza\u00e7\u00e3o. Essa mudan\u00e7a alinha a Cloudflare \u00e0s melhores pr\u00e1ticas de least-privilege access<\/strong> e simplifica a experi\u00eancia de consentimento em aplica\u00e7\u00f5es, CLIs e workloads.<\/p>\n

Outro an\u00fancio relevante \u00e9 o Cloudflare Access for Workers<\/strong>, que permite anexar uma pol\u00edtica do Access diretamente a um Worker e aplic\u00e1-la automaticamente em todos os pontos de execu\u00e7\u00e3o: rotas, dom\u00ednios personalizados, workers.dev e previews<\/strong>. Antes, proteger um Worker com Access exigia configurar rotas ou dom\u00ednios manualmente e garantir que cada caminho estivesse coberto por uma pol\u00edtica de identidade. Agora, a prote\u00e7\u00e3o \u00e9 inerente ao pr\u00f3prio Worker, eliminando brechas comuns em deployments acelerados. A Cloudflare descreve o recurso como uma forma de proteger todas as suas aplica\u00e7\u00f5es internas criadas com vibe coding<\/em> \u2014 um reconhecimento de que muitas equipes est\u00e3o gerando c\u00f3digo rapidamente com assist\u00eancia de IA e nem sempre seguem checklists de seguran\u00e7a.<\/p>\n

Al\u00e9m disso, o Cloudflare One Client<\/strong> recebeu novas vers\u00f5es est\u00e1veis para Windows, macOS e Linux<\/strong> (vers\u00e3o 2026.7.1343.0<\/strong>). As mudan\u00e7as incluem reautentica\u00e7\u00e3o mais clara com redirecionamento para o navegador quando necess\u00e1rio, adapta\u00e7\u00e3o autom\u00e1tica de fallback quando a rede bloqueia HTTP\/3, e corre\u00e7\u00f5es importantes em vazamentos de processo, troca de organiza\u00e7\u00e3o e exibi\u00e7\u00e3o de status de conex\u00e3o. Para administradores do Access, essas melhorias reduzem o volume de tickets relacionados a falhas de autentica\u00e7\u00e3o e conectividade em redes legadas ou altamente filtradas.<\/p>\n

O changelog de WAF tamb\u00e9m trouxe uma atualiza\u00e7\u00e3o de seguran\u00e7a que afeta indiretamente o Access: a detec\u00e7\u00e3o de credenciais vazadas<\/strong> agora escaneia cabe\u00e7alhos Authorization<\/code> com credenciais Basic Authentication<\/strong>. Antes, a inspe\u00e7\u00e3o cobria apenas corpos de requisi\u00e7\u00e3o, query strings e cabe\u00e7alhos de aplica\u00e7\u00f5es web conhecidas. Com a mudan\u00e7a, credenciais enviadas via HTTP Basic Auth s\u00e3o decodificadas e comparadas com a base de credenciais vazadas da Cloudflare. Isso fortalece a prote\u00e7\u00e3o de aplica\u00e7\u00f5es legadas que ainda dependem de Basic Auth atr\u00e1s de pol\u00edticas do Access, permitindo reutilizar regras customizadas e regras de rate limit sem altera\u00e7\u00f5es.<\/p>\n

Por fim, a Cloudflare Status anunciou manuten\u00e7\u00f5es programadas que merecem aten\u00e7\u00e3o de quem opera infraestrutura com Cloudflare: janelas de manuten\u00e7\u00e3o nos data centers de EWR (Newark)<\/strong> em 1 e 2 de setembro, em SJC (San Jose)<\/strong> em 26 de agosto, e uma manuten\u00e7\u00e3o de core backend databases (cfdb)<\/strong> em 29 de agosto de 2026, das 09:00 \u00e0s 11:00 UTC. Durante essa \u00faltima, opera\u00e7\u00f5es de escrita na configura\u00e7\u00e3o de zonas e contas podem sofrer atrasos ou falhas tempor\u00e1rias por at\u00e9 3 minutos, incluindo gerenciamento de IAM, OAuth, SSO e provisionamento SCIM. As configura\u00e7\u00f5es existentes e o acesso permanecem ativos, mas administradores devem evitar realizar mudan\u00e7as cr\u00edticas nessas janelas.<\/p>\n

Cloudflare Access atualiza\u00e7\u00e3o: OAuth com escopos opcionais em GA<\/h3>\n

O suporte a escopos opcionais de OAuth<\/strong> \u00e9, na pr\u00e1tica, uma corre\u00e7\u00e3o de um ponto de fric\u00e7\u00e3o que afetava tanto usu\u00e1rios quanto desenvolvedores de integra\u00e7\u00f5es OAuth na Cloudflare. No modelo anterior, todos os escopos configurados em um cliente OAuth eram obrigat\u00f3rios<\/strong>: ou o usu\u00e1rio aprovava todas as permiss\u00f5es solicitadas, ou o fluxo de autoriza\u00e7\u00e3o falhava. Isso criava situa\u00e7\u00f5es de all-or-nothing consent<\/em>, nas quais aplica\u00e7\u00f5es que precisavam de apenas uma permiss\u00e3o b\u00e1sica acabavam solicitando um conjunto amplo de acessos, reduzindo a confian\u00e7a do usu\u00e1rio e aumentando o risco de exposi\u00e7\u00e3o desnecess\u00e1ria. Com a mudan\u00e7a, cada escopo pode ser classificado como required<\/strong> ou optional<\/strong> no dashboard. Na tela de consentimento, os escopos opcionais aparecem selecionados por padr\u00e3o<\/strong>, mas o usu\u00e1rio pode desmarc\u00e1-los. Os escopos obrigat\u00f3rios permanecem bloqueados para sele\u00e7\u00e3o.<\/p>\n

Do ponto de vista t\u00e9cnico, a implementa\u00e7\u00e3o segue o fluxo padr\u00e3o OAuth 2.0, mas com uma camada de metadados que permite ao servidor de autoriza\u00e7\u00e3o distinguir entre permiss\u00f5es essenciais e permiss\u00f5es complementares. Quando o usu\u00e1rio recusa um escopo opcional, o token de acesso emitido cont\u00e9m apenas os escopos efetivamente concedidos \u2014 n\u00e3o h\u00e1 fallback silencioso nem eleva\u00e7\u00e3o de privil\u00e9gios. Isso \u00e9 particularmente importante para aplica\u00e7\u00f5es, CLIs e workloads<\/strong> que precisam se autenticar programaticamente: agora \u00e9 poss\u00edvel solicitar apenas o escopo m\u00ednimo necess\u00e1rio para a tarefa em quest\u00e3o, sem expor o usu\u00e1rio a uma lista assustadora de permiss\u00f5es.<\/p>\n

A tela de consentimento tamb\u00e9m foi redesenhada para acelerar a decis\u00e3o do usu\u00e1rio. Dois templates foram introduzidos: Read Only<\/strong> e Full Access<\/strong>. O template Read Only seleciona automaticamente apenas os escopos de leitura dispon\u00edveis, enquanto o Full Access seleciona todos os escopos configurados. Al\u00e9m disso, a tela ganhou busca de escopos<\/strong>, permitindo que usu\u00e1rios localizem rapidamente uma permiss\u00e3o espec\u00edfica em clientes com muitos escopos. Para administradores de grandes organiza\u00e7\u00f5es, isso reduz o atrito de ado\u00e7\u00e3o de novas ferramentas e melhora a transpar\u00eancia do consentimento \u2014 um requisito cada vez mais cobrado por auditorias de conformidade.<\/p>\n

Para desenvolvedores de clientes OAuth, a mudan\u00e7a exige revisar as configura\u00e7\u00f5es existentes. Por padr\u00e3o, todos os escopos configurados permanecem obrigat\u00f3rios<\/strong> ap\u00f3s a atualiza\u00e7\u00e3o. Ou seja, n\u00e3o h\u00e1 breaking change autom\u00e1tico: clientes que n\u00e3o forem editados continuam funcionando como antes. O caminho de migra\u00e7\u00e3o recomendado \u00e9 simples: acessar o dashboard da Cloudflare, revisar os escopos de cada cliente OAuth e marcar como opcionais aqueles que n\u00e3o s\u00e3o estritamente necess\u00e1rios para o fluxo de autoriza\u00e7\u00e3o inicial. Em seguida, atualizar a documenta\u00e7\u00e3o interna e os fluxos de onboarding para refletir o novo comportamento de consentimento.<\/p>\n\n\n\n\n\n\n\n\n
Recurso<\/th>\nAntes<\/th>\nDepois<\/th>\nImpacto<\/th>\n<\/tr>\n<\/thead>\n
Classifica\u00e7\u00e3o de escopos OAuth<\/td>\nTodos os escopos eram obrigat\u00f3rios por padr\u00e3o<\/td>\nEscopos podem ser marcados como required<\/strong> ou optional<\/strong><\/td>\nAplica\u00e7\u00f5es solicitam apenas o m\u00ednimo necess\u00e1rio; usu\u00e1rios podem recusar escopos opcionais sem travar o fluxo<\/td>\n<\/tr>\n
Tela de consentimento<\/td>\nSem sele\u00e7\u00e3o granular; usu\u00e1rio aprovava tudo ou nada<\/td>\nTemplates Read Only<\/strong> e Full Access<\/strong>, busca de escopos, sele\u00e7\u00e3o padr\u00e3o de opcionais<\/td>\nDecis\u00e3o mais r\u00e1pida e transparente; melhor UX para usu\u00e1rios finais<\/td>\n<\/tr>\n
Migra\u00e7\u00e3o de clientes existentes<\/td>\nN\/A<\/td>\nEscopos existentes permanecem required<\/strong> at\u00e9 edi\u00e7\u00e3o manual<\/td>\nSem breaking change autom\u00e1tico; administradores devem revisar e ajustar<\/td>\n<\/tr>\n
Seguran\u00e7a e least-privilege<\/td>\nApps frequentemente solicitavam permiss\u00f5es excessivas<\/td>\nTokens refletem apenas escopos concedidos efetivamente<\/td>\nRedu\u00e7\u00e3o da superf\u00edcie de exposi\u00e7\u00e3o; conformidade mais simples com LGPD e auditorias<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A relev\u00e2ncia dessa mudan\u00e7a para o Cloudflare Access<\/strong> \u00e9 direta. Muitas integra\u00e7\u00f5es que protegem recursos via Access utilizam OAuth para autenticar servi\u00e7os e ferramentas administrativas. Com escopos opcionais, equipes de seguran\u00e7a podem reduzir o escopo de tokens emitidos para CLIs e pipelines de CI\/CD, limitando o impacto de um token vazado. Na JRT Technology Solutions<\/strong>, configuramos o Cloudflare para clientes corporativos com pol\u00edticas de least-privilege estritas, e essa funcionalidade elimina a necessidade de criar m\u00faltiplos clientes OAuth apenas para variar permiss\u00f5es entre ambientes.<\/p>\n

Cloudflare Access atualiza\u00e7\u00e3o para Workers: prote\u00e7\u00e3o em um clique<\/h3>\n

O an\u00fancio do Cloudflare Access for Workers<\/strong> resolve uma lacuna cr\u00edtica no ciclo de vida de aplica\u00e7\u00f5es serverless. Workers s\u00e3o executados no runtime da Cloudflare em mais de 275 pontos de presen\u00e7a<\/strong>, com cold start inferior a 1 ms<\/strong>. Essa velocidade e distribui\u00e7\u00e3o tornam o Workers uma escolha natural para APIs internas, ferramentas administrativas, webhooks e pain\u00e9is de controle. Contudo, proteger esses endpoints com Access tradicionalmente exigia configurar rotas ou dom\u00ednios personalizados e garantir que cada caminho estivesse associado a uma pol\u00edtica de identidade. Em ambientes com dezenas ou centenas de Workers, esse processo manual gerava inconsist\u00eancias e brechas \u2014 especialmente quando previews e dom\u00ednios workers.dev<\/code> ficavam esquecidos.<\/p>\n

Com a atualiza\u00e7\u00e3o, basta anexar uma pol\u00edtica do Access diretamente ao Worker, e ela passa a valer em todos os lugares onde aquele Worker \u00e9 executado<\/strong>. Isso inclui rotas customizadas, dom\u00ednios pr\u00f3prios, .workers.dev<\/code> e at\u00e9 mesmo previews de desenvolvimento. A implica\u00e7\u00e3o \u00e9 profunda: o desenvolvedor n\u00e3o precisa mais lembrar de proteger cada endpoint individualmente. O default-deny<\/em> se torna uma propriedade do c\u00f3digo, n\u00e3o da configura\u00e7\u00e3o de rede. Para equipes que praticam vibe coding<\/em> \u2014 gerando aplica\u00e7\u00f5es rapidamente com aux\u00edlio de IA \u2014 essa prote\u00e7\u00e3o autom\u00e1tica reduz drasticamente o risco de expor ferramentas internas \u00e0 internet p\u00fablica.<\/p>\n

Do ponto de vista de arquitetura, o Access for Workers funciona como uma camada de autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o na borda, integrada ao fluxo de execu\u00e7\u00e3o do Worker. Quando uma requisi\u00e7\u00e3o chega, a pol\u00edtica do Access \u00e9 avaliada antes que o c\u00f3digo do Worker execute. Se o usu\u00e1rio n\u00e3o estiver autenticado ou n\u00e3o possuir a permiss\u00e3o necess\u00e1ria, a requisi\u00e7\u00e3o \u00e9 bloqueada e redirecionada para o fluxo de login configurado \u2014 como Okta, Google Workspace ou Azure AD<\/strong>. Se a pol\u00edtica permitir, o Worker executa normalmente, com o contexto de identidade dispon\u00edvel para o c\u00f3digo. Essa integra\u00e7\u00e3o elimina a necessidade de implementar autentica\u00e7\u00e3o dentro do pr\u00f3prio Worker, reduzindo o c\u00f3digo de seguran\u00e7a duplicado e a chance de erros de implementa\u00e7\u00e3o.<\/p>\n

Para administradores, a configura\u00e7\u00e3o \u00e9 simples, mas exige aten\u00e7\u00e3o a alguns detalhes. Primeiro, \u00e9 preciso garantir que o Worker esteja vinculado a uma pol\u00edtica do Access com o provedor de identidade correto. Em seguida, revisar as regras de acesso para refletir quem deve acessar aquele Worker \u2014 por exemplo, apenas funcion\u00e1rios com email corporativo ou grupos espec\u00edficos do IdP. Tamb\u00e9m \u00e9 recomend\u00e1vel testar o comportamento em previews, pois agora esses ambientes herdam a prote\u00e7\u00e3o automaticamente, o que pode surpreender desenvolvedores que usavam previews para testes p\u00fablicos. A Cloudflare documenta o recurso em Cloudflare Fundamentals, e a JRT Technology Solutions<\/strong> recomenda que clientes com pipelines de CI\/CD ativos revisem seus fluxos de deploy para garantir que a prote\u00e7\u00e3o n\u00e3o quebre integra\u00e7\u00f5es leg\u00edtimas automatizadas.<\/p>\n

O impacto dessa atualiza\u00e7\u00e3o se estende \u00e0 estrat\u00e9gia de Zero Trust. Ao proteger Worker em n\u00edvel de c\u00f3digo, a Cloudflare aproxima o Access do modelo de identity-aware proxy<\/em> para cargas de trabalho serverless, competindo diretamente com solu\u00e7\u00f5es como AWS Verified Access<\/strong> e Google Identity-Aware Proxy<\/strong>. A diferen\u00e7a \u00e9 que a Cloudflare aplica a prote\u00e7\u00e3o na borda, sem exigir que a aplica\u00e7\u00e3o esteja em uma VPC ou regi\u00e3o espec\u00edfica. Para empresas brasileiras com times distribu\u00eddos e uso intensivo de Workers para APIs internas, isso significa menos fric\u00e7\u00e3o e mais consist\u00eancia de seguran\u00e7a.<\/p>\n

Cloudflare One Client: a atualiza\u00e7\u00e3o do cliente Zero Trust que impacta o Access<\/h3>\n

O Cloudflare One Client<\/strong> nas vers\u00f5es 2026.7.1343.0<\/strong> para Windows, macOS e Linux trouxe melhorias que, embora n\u00e3o sejam exclusivas do Access, afetam diretamente a experi\u00eancia de autentica\u00e7\u00e3o e conectividade dos usu\u00e1rios finais. A mudan\u00e7a mais vis\u00edvel \u00e9 na reautentica\u00e7\u00e3o<\/strong>: quando o cliente detecta que uma nova autentica\u00e7\u00e3o \u00e9 necess\u00e1ria \u2014 por exemplo, ap\u00f3s expira\u00e7\u00e3o de sess\u00e3o ou mudan\u00e7a de pol\u00edtica \u2014 as notifica\u00e7\u00f5es agora s\u00e3o mais claras e o fluxo redireciona para o navegador quando apropriado, em vez de for\u00e7ar a intera\u00e7\u00e3o na janela do aplicativo. Isso reduz o n\u00famero de a\u00e7\u00f5es necess\u00e1rias para retomar o trabalho e elimina confus\u00f5es comuns em ambientes corporativos onde o navegador \u00e9 o padr\u00e3o para login.<\/p>\n

Outra melhoria t\u00e9cnica relevante \u00e9 a adapta\u00e7\u00e3o autom\u00e1tica de fallback HTTP\/3<\/strong>. Quando o cliente detecta que a rede est\u00e1 bloqueando ou n\u00e3o suportando HTTP\/3, ele aprende o padr\u00e3o e passa a iniciar conex\u00f5es com HTTP\/2 primeiro<\/strong>, tentando HTTP\/3 apenas se necess\u00e1rio. Em redes legadas ou altamente filtradas \u2014 cen\u00e1rio comum em empresas brasileiras que operam com proxies e firewalls de gera\u00e7\u00e3o anterior \u2014 essa mudan\u00e7a reduz o tempo de conex\u00e3o e evita falhas intermitentes ao ingressar na rede Zero Trust da Cloudflare. Para administradores do Access, isso significa menos tickets de “n\u00e3o consigo conectar” relacionados a negocia\u00e7\u00e3o de protocolo.<\/p>\n

O changelog tamb\u00e9m corrige uma s\u00e9rie de bugs importantes. No Windows, foi corrigido um vazamento de processo na GUI<\/strong> que poderia esgotar recursos do sistema durante falhas de cria\u00e7\u00e3o de IPC, al\u00e9m de um falso positivo do Microsoft Defender<\/strong> ao instalar com Intune. A troca de organiza\u00e7\u00e3o quando o cliente estava preso no estado “Device not in organization” tamb\u00e9m foi corrigida. No macOS e Linux, corre\u00e7\u00f5es semelhantes incluem a exibi\u00e7\u00e3o correta do \u00edcone de nuvem (que antes podia mostrar desconectado mesmo com conex\u00e3o ativa), a corre\u00e7\u00e3o de erro de exibi\u00e7\u00e3o de certificado devido a condi\u00e7\u00e3o de corrida e a tela preta ao alternar entre monitores docked e undocked. No Linux, um item conhecido permanece: no modo DNS Only, consultas para nomes configurados em Local Domain Fallback podem ser enviadas ao servidor DNS criptografado em vez de cair para a configura\u00e7\u00e3o do sistema.<\/p>\n