Microsoft inicia contagem regressiva final para desativar o Exchange Web Services no Microsoft 365
A Microsoft oficializou o calendário que marca a aposentadoria definitiva do Exchange Web Services (EWS) no Microsoft 365 e no Exchange Online, decretando o fim de uma das APIs mais longevas e utilizadas no universo Exchange. A partir de agora, a transição deixa de ser uma recomendação e passa a ter data-limite rígida, com impacto direto em integrações, aplicações corporativas e soluções de terceiros espalhadas por inúmeros ambientes.
Segundo o cronograma divulgado, o EWS será desativado por padrão em 1º de outubro de 2026. A partir dessa data, novos tenants e ambientes que não fizerem ajustes específicos já não terão o serviço disponível automaticamente. As organizações que ainda dependem da API poderão mantê-la em funcionamento por um período adicional, configurando explicitamente o parâmetro `EWSEnabled = true` até agosto de 2026, como medida temporária de continuidade.
Esse respiro, porém, tem prazo bem definido. A Microsoft foi taxativa ao anunciar que o desligamento completo e irreversível do EWS no Microsoft 365 e no Exchange Online ocorrerá em 1º de abril de 2027. Depois dessa data, não haverá extensões, exceções ou adiamentos: qualquer dependência residual à API resultará, na prática, em quebra de funcionalidades e indisponibilidade de integrações.
O EWS não é uma tecnologia nova nem desconhecida do mercado. Introduzido originalmente com o Exchange Server 2007, ele foi projetado para permitir que aplicações acessassem caixas de correio, calendários, contatos e outros repositórios de dados tanto em Exchange Online como em Exchange Server. Com o passar dos anos, tornou-se peça central para integradores, provedores de soluções de e‑mail corporativo, ferramentas de arquivamento, sistemas de workflow, aplicações internas e até versões clássicas do Outlook.
Essa popularidade, porém, também teve um lado negativo: o EWS passou a ser alvo recorrente de cibercriminosos, que exploram a API como vetor de ataque para movimentação lateral, exfiltração de dados e espionagem direcionada. Em diversos incidentes, invasores usaram credenciais comprometidas ou tokens de acesso para abusar do EWS de forma furtiva, muitas vezes sem disparar alertas tradicionais.
A Microsoft declarou que o EWS está formalmente depreciado há anos, e sua aposentadoria já havia sido comunicada em 2023. Em 2025, a empresa endureceu ainda mais a transição ao anunciar que determinadas licenças, como F1 e F2, perderiam a permissão para uso da API, sinalizando com clareza que o fim era uma questão de tempo, não de “se”, mas de “quando”.
O ponto de virada em termos de urgência veio após o incidente de segurança envolvendo o grupo Midnight Blizzard. Depois desse episódio, a Microsoft afirmou ter elevado significativamente a prioridade de descontinuação do EWS, citando preocupações com a superfície de ataque e com a necessidade de reduzir pontos de exploração legados dentro da plataforma de e‑mail corporativo.
É importante destacar que as mudanças anunciadas atingem exclusivamente o Microsoft 365 e o Exchange Online. Ambientes com Exchange Server on‑premises não terão alteração imediata na forma como o EWS é suportado. Ou seja, a API continuará existindo e sendo suportada nas instalações locais, ainda que a tendência de médio e longo prazo seja a mesma: migração gradual para modelos mais modernos, centrados no Microsoft Graph.
Para as organizações que utilizam o Exchange Online, porém, o recado é claro: administradores que ainda não iniciaram ou não concluíram o processo de migração precisarão acelerar o planejamento. A orientação oficial da Microsoft é mover todas as integrações e aplicações dependentes de EWS para o Microsoft Graph, a API unificada que hoje dá acesso a dados do Microsoft 365 de forma mais moderna e segura.
A própria Microsoft admite, contudo, que o Microsoft Graph ainda está em “quase completa” paridade funcional com o EWS. Isso significa que, embora a maioria dos cenários já seja suportada, existem casos específicos em que recursos equivalentes ainda não foram plenamente implementados. A empresa reconhece, inclusive, que nem todas as suas aplicações internas finalizaram a transição, o que evidencia a complexidade do processo.
Para identificar dependências ocultas — aqueles sistemas legados, scripts ou serviços esquecidos que ainda usam EWS — a Microsoft informou que poderá realizar “scream tests” controlados. Em termos práticos, isso significa desligar e religar o EWS de forma temporária, justamente para fazer emergir falhas em aplicações que silenciosamente dependem da API. O problema é que a empresa não detalhou como os administradores poderão distinguir esses testes de falhas reais, algo sensível em um cenário em que interrupções em serviços online já são motivo constante de preocupação.
Diante desse panorama, a Microsoft reiterou que divulgará mais orientações técnicas nas próximas semanas, mas encerrou qualquer esperança de prorrogação: após abril de 2027, não haverá exceções. Organizações que ignorarem o cronograma correm o risco de descobrir, da pior forma possível, que processos críticos simplesmente deixaram de funcionar.
O que está em jogo para as empresas
Por trás do anúncio, há impactos práticos que vão muito além de uma simples troca de API. Muitas empresas construíram fluxos de negócio inteiros em torno do EWS: sistemas de help desk que leem e classificam e‑mails automaticamente, integrações com CRM, rotinas de auditoria e conformidade, ferramentas de backup e arquivamento, robôs que manipulam calendários de executivos, entre outros.
Se essas integrações não forem revisadas e migradas a tempo, a desativação do EWS pode resultar em:
– interrupção de automações de e‑mail e calendário;
– falhas em rotinas de compliance e retenção de dados;
– perda de funcionalidades em aplicações internas e legadas;
– impacto direto em operações críticas que dependem de notificações ou disparos via Exchange.
Por isso, mais do que um aviso técnico, o cronograma da Microsoft precisa ser tratado como um projeto de transformação, envolvendo não só a equipe de TI, mas também áreas de negócio que se apoiam em processos automatizados com e‑mail e agenda.
O que é o Microsoft Graph e por que ele substitui o EWS
O Microsoft Graph é hoje a principal porta de entrada programática para dados e serviços do Microsoft 365. Em vez de uma API isolada para e‑mail, ele oferece um modelo unificado para acessar mensagens, calendários, arquivos, usuários, grupos, dispositivos e muito mais, sob uma mesma arquitetura de autenticação, autorização e governança.
Do ponto de vista de segurança, o Graph foi desenhado para operar em alinhamento com conceitos modernos como:
– autenticação baseada em OAuth 2.0 e OpenID Connect;
– políticas de acesso condicional;
– logging e auditoria mais robustos;
– escopo granular de permissões, reduzindo privilégios desnecessários.
Em comparação, o EWS carrega características de uma geração anterior, em que muitos cenários foram construídos com permissões amplas e mecanismos de controle menos granulares, facilitando o abuso em caso de comprometimento de credenciais.
Como se preparar para a migração do EWS para o Graph
Para organizações que ainda não começaram a migração, alguns passos práticos podem ajudar a estruturar o trabalho:
1. Mapeamento de dependências
– Levantar todos os sistemas, scripts, serviços e integrações que utilizam EWS.
– Verificar logs, configurações de aplicações e credenciais de serviço para identificar chamadas à API.
2. Classificação por criticidade
– Separar integrações críticas (ligadas a processos essenciais de negócio) das rotinas acessórias ou de baixo impacto.
– Definir prioridades de migração de acordo com o risco operacional.
3. Avaliação de paridade funcional
– Verificar se cada funcionalidade usada atualmente no EWS já possui equivalente no Microsoft Graph.
– Onde ainda não houver paridade total, analisar workarounds temporários ou ajustes no processo de negócio.
4. Planejamento técnico e de segurança
– Revisar o modelo de autenticação e autorização, migrando para padrões modernos e evitando permissões excessivas.
– Aproveitar a migração para implementar boas práticas de segurança, como segregação de funções e rotação de credenciais.
5. Testes e validação gradual
– Criar ambientes de teste ou pilots para validar a migração em etapas, sem impactar imediatamente o ambiente de produção.
– Monitorar logs, performance e confiabilidade durante a transição.
6. Comunicação com as áreas de negócio
– Informar usuários-chave sobre possíveis mudanças de comportamento das aplicações.
– Alinhar janelas de manutenção e cronogramas para minimizar impacto.
Riscos de segurança de manter o EWS até o limite
Embora a Microsoft ainda permita manter o EWS ativo até 2027, isso não significa que seja uma boa prática estender essa dependência até o último momento. APIs legadas tendem a receber foco reduzido em termos de evolução e hardening, enquanto atacantes continuam pesquisando brechas e novas formas de exploração.
Adiar a migração significa:
– permanecer mais tempo exposto a um vetor de ataque conhecido;
– carregar complexidade técnica, com dois modelos coexistindo (EWS e Graph);
– aumentar a pressão sobre as equipes de TI no período final, quando a janela de reação for muito menor.
Do ponto de vista de gestão de risco, o ideal é encarar 2026/2027 como um prazo máximo, mas trabalhar com datas internas mais agressivas, antecipando a conversão dos principais workloads para o Graph.
Impacto em licenças de baixo custo e ambientes híbridos
A decisão de restringir o EWS em licenças como F1 e F2 já indicava uma diretriz clara: workloads de “frente de trabalho” e cenários simplificados deveriam abandonar o modelo legado mais cedo. Organizações que usaram essas licenças como base para integrações automatizadas precisam reavaliar não só a tecnologia, mas também a forma como estruturaram seus modelos de licença e de acesso.
Em ambientes híbridos — que combinam Exchange Server on‑premises com Exchange Online — a situação exige ainda mais cuidado. Embora o Exchange Server local continue suportando o EWS, o lado em nuvem deixará de fazê‑lo. Isso pode criar cenários em que uma mesma integração funciona parcialmente on‑premises e falha na nuvem, gerando comportamentos inconsistentes se a migração não for cuidadosamente planejada.
Oportunidade de modernização
Apesar do caráter de urgência, a aposentadoria do EWS também pode ser enxergada como uma oportunidade de modernização. Muitos sistemas construídos sobre essa API foram desenvolvidos em uma época em que:
– não se falava tanto em Zero Trust;
– a autenticação multifator não era amplamente difundida;
– integrações eram feitas com foco em “fazer funcionar”, e não em minimizar privilégios.
Ao migrar para o Microsoft Graph, organizações podem aproveitar para revisar arquitetura, limpar códigos antigos, reduzir dependências desnecessárias e implementar mecanismos de observabilidade mais avançados, como monitoramento de chamadas à API e alertas de uso anômalo.
Conclusão: ignorar o prazo não é opção
O recado da Microsoft é direto: o EWS no Microsoft 365 e no Exchange Online tem data de morte anunciada, e não haverá prorrogação além de abril de 2027. Mesmo que, no curto prazo, tudo continue funcionando aparentemente bem, a inércia pode se transformar em indisponibilidade repentina e em risco de segurança ampliado.
A melhor resposta para as organizações é encarar esse calendário como um gatilho para ação imediata: mapear dependências, priorizar sistemas críticos, planejar a migração para o Microsoft Graph e tratar o fim do EWS não apenas como uma imposição da Microsoft, mas como uma chance de fortalecer a segurança, a governança e a resiliência de todo o ecossistema de e‑mail e colaboração.