A Microsoft atribuiu a interrupção generalizada dos serviços Microsoft 365 de 23 de julho de 2026 a um erro numa automação de manutenção de rede, que removeu por engano rotas de IP essenciais na região West US da Azure. O incidente afetou sobretudo utilizadores na América do Norte, mas o efeito de cascata atingiu serviços usados em todo o mundo, como o Teams, o SharePoint, o OneDrive, o Outlook e o Copilot. A empresa reverteu a alteração de rede e deu o problema como resolvido no mesmo dia, prometendo publicar uma análise pós-incidente completa.
Resposta rápida: Um erro num sistema automatizado de manutenção da Azure isolou mais dispositivos de rede do que o previsto, removendo rotas de IP na região West US e cortando tráfego que entrava e saía dessa zona. A avaria propagou-se ao Microsoft 365, degradando serviços como Teams, SharePoint, OneDrive e Copilot durante várias horas. A Microsoft reverteu a alteração e restabeleceu o serviço no próprio dia. Para as organizações, o caso reforça a necessidade de planos de continuidade que não dependam de um único fornecedor de nuvem.
O que aconteceu a 23 de julho
Segundo os avisos oficiais da Microsoft, a perturbação teve início às 14:44 UTC de 23 de julho de 2026, quando começaram a surgir falhas de conectividade associadas à região West US da Azure. O incidente foi registado sob o identificador de rastreio ZJV6-SGG e, entre as 14:40 UTC e as 18:26 UTC, os clientes podem ter sofrido falhas de conectividade intermitentes, latência acrescida ou dificuldades em aceder a serviços Azure e a outros serviços de nuvem da Microsoft associados à região West US.
Do lado do Microsoft 365, o problema foi acompanhado no centro de administração sob o identificador MO1437424. A interrupção começou às 10:44 ET de quinta-feira, 23 de julho, e afetou sobretudo os clientes que acedem aos serviços Microsoft 365 através da infraestrutura de rede ligada à região West US da Azure; às 11:11 ET, o Downdetector tinha registado 2.403 relatos de avaria, muito acima da linha de base normal de 29, com o SharePoint a representar 78% das queixas, seguido do Excel com 11% e do centro de administração com 6%.
O leque de serviços atingidos foi amplo. A disrupção afetou o acesso à Azure e a múltiplos serviços Microsoft 365, com milhares de utilizadores a reportar problemas no Outlook, Teams, SharePoint, OneDrive, Copilot, Azure, Xbox Live e Microsoft Store, e alguns utilizadores relataram ainda dificuldades a transferir atualizações do Windows e a instalar aplicações do Microsoft Office. A Microsoft detalhou impactos concretos: acesso intermitente ao OneDrive, erros “Something went wrong” no SharePoint Online, funcionalidade de conversação degradada no Teams (incluindo imagens que não carregavam), o centro de administração a abrir lentamente ou de todo, e fluxos do Power Automate que não carregavam.
A causa: uma automação de manutenção que isolou dispositivos a mais
Na revisão pós-incidente preliminar (Preliminary Post Incident Review) publicada para o incidente da Azure, a Microsoft explicou a mecânica da falha. A empresa referiu que a interrupção foi desencadeada durante manutenção de rotina a dispositivos na região West US, onde caminhos de rede específicos estavam a ser isolados, e que o seu processo de manutenção converte estes pedidos em instruções legíveis pelo sistema e verifica que pelo menos um de dois caminhos redundantes se mantém saudável antes de o trabalho começar.
O problema surgiu nessa conversão. Um erro no sistema de conversão de pedidos marcou incorretamente dispositivos de rede adicionais como parte do evento de manutenção, pelo que foram removidas rotas de IP de mais dispositivos do que o pretendido entre o datacenter West US da Microsoft e a sua rede de longa distância (WAN), o que perturbou o tráfego de rede que entrava ou saía da região West US.
Por outras palavras, uma verificação de segurança pensada para garantir redundância foi contornada por um bug na fase de tradução automática do pedido. O problema foi causado quando um conjunto de rotas de IP foi removido por erro ao isolar um dispositivo para manutenção de rotina: antes de iniciar os trabalhos, a Microsoft confirmou que pelo menos um dos dois caminhos redundantes para a instalação permanecia operacional, mas, na altura de começar, sistemas automatizados incluíram dispositivos adicionais no perímetro a isolar, removendo rotas de IP que não constavam da avaliação inicial.
Cronologia do incidente
| Hora (UTC) | Acontecimento |
|---|---|
| 14:44 | Início da manutenção a dispositivos; começam as falhas de conectividade na região West US |
| 14:45 | Equipas de rede e resposta a incidentes começam a investigar anomalias de tráfego e degradação de serviço |
| ~14:44–19:41 | Janela de impacto do incidente da Azure (ZJV6-SGG) |
| 18:47 (aprox.) | Reversão da alteração de rede concluída; telemetria indica recuperação |
| 18:26 / 19:41 | Fim da janela de impacto conforme diferentes avisos da Azure |
Os avisos da Azure e a análise técnica convergem na duração aproximada. A Microsoft publicou uma revisão pós-incidente preliminar a indicar que a conectividade esteve perdida durante cinco horas, entre as 14:44 UTC (7:44 da manhã, hora do Pacífico) e as 19:41 UTC de 23 de julho. Um outro aviso da Azure situa a recuperação já a partir das 18:26 UTC, o que reflete a natureza faseada do restabelecimento à medida que diferentes serviços dependentes se recuperavam.
Do lado do Microsoft 365, a sequência de comunicação foi acompanhada pela conta oficial de estado. A empresa indicou que estava a executar ações direcionadas de reencaminhamento de tráfego enquanto revertia a alteração de rede, que o reencaminhamento tinha aliviado parte do impacto e, mais tarde, confirmou ter concluído a reversão da atualização de rede e validado, através de telemetria de serviço e relatos de clientes, que o problema estava resolvido. A Microsoft concluiu a reversão às 2:26 PM ET e confirmou através de telemetria de serviço e relatos de clientes que o incidente do Microsoft 365 tinha sido resolvido.
O que a Microsoft diz que vai fazer
A empresa comprometeu-se a rever os mecanismos que falharam. A Microsoft afirmou que vai realizar uma análise completa centrada nas verificações de segurança e no processo automatizado de alteração de pedidos de manutenção, e que publicará uma revisão pós-incidente final após concluir a investigação, normalmente num prazo de 14 dias. Note-se que, por se tratar de uma análise preliminar, alguns detalhes — incluindo horas exatas de recuperação e a lista completa de serviços afetados — poderão ser ajustados no relatório final.
Este incidente insere-se num padrão de perturbações que marcou os serviços de nuvem da Microsoft em 2026. Em janeiro, uma única falha multisserviço deixou em baixo em simultâneo o Exchange Online, o SharePoint, o Teams, o Microsoft Defender e o OneDrive para clientes empresariais na América do Norte, com relatos a atingirem picos de mais de 30.000 utilizadores incapazes de aceder a serviços críticos durante nove horas de disrupção. A recorrência destas falhas — várias delas ligadas a alterações de rede ou de manutenção — reforça a discussão sobre a concentração de risco em infraestruturas partilhadas.
Porque é que isto importa em Portugal
Para cidadãos, PME e organizações em Portugal que dependem do Microsoft 365 e da Azure, um incidente deste tipo não é uma vulnerabilidade de segurança nem um ciberataque, mas afeta diretamente a disponibilidade — um dos pilares da segurança da informação, a par da confidencialidade e da integridade. Correio eletrónico, colaboração no Teams, acesso a documentos no SharePoint e automatizações do Power Automate podem parar por várias horas por motivos que estão inteiramente fora do controlo do cliente.
No plano regulatório, o novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2 para a ordem jurídica portuguesa) coloca a ênfase na gestão de risco, na continuidade de atividade e na segurança da cadeia de fornecimento, incluindo a dependência de fornecedores de serviços digitais e de nuvem. Para entidades abrangidas, a dependência de um único fornecedor crítico deve constar da análise de risco e dos planos de continuidade de negócio. O Centro Nacional de Cibersegurança (CNCS) e o CERT.PT recomendam habitualmente estratégias de resiliência que contemplem cenários de indisponibilidade prolongada de serviços cloud.
Na prática, há medidas concretas que as organizações podem adotar para reduzir o impacto de interrupções semelhantes:
- Manter cópias de segurança independentes de correio e documentos, com um fornecedor ou tecnologia distintos do serviço principal.
- Definir canais de comunicação alternativos (por exemplo, telefone, SMS ou uma plataforma de mensagens de outro fornecedor) para coordenação de equipas durante uma falha.
- Monitorizar de forma proativa o
status.cloud.microsofte oazure.status.microsoft, além do centro de administração Microsoft 365, para obter atualizações oficiais. - Incluir cenários de indisponibilidade de nuvem nos planos de continuidade de negócio e testá-los periodicamente.
- Garantir que os sistemas de monitorização e alerta não dependem exclusivamente do serviço que pretendem vigiar.
Em matéria de proteção de dados, uma indisponibilidade temporária não constitui, por si só, uma violação de dados pessoais nos termos do RGPD, desde que não haja acesso não autorizado, perda ou destruição de informação. Ainda assim, organizações que tratam dados pessoais devem avaliar se a interrupção compromete a disponibilidade dos dados de forma relevante e documentar a ocorrência no âmbito das suas obrigações de responsabilização (accountability).
A lição central deste incidente é conhecida, mas continua atual: a robustez de uma nuvem hiperescalar não elimina o risco de erro operacional, e a resiliência de cada organização depende tanto do fornecedor como dos seus próprios planos de contingência.
Perguntas frequentes
O que causou a falha do Microsoft 365 de 23 de julho de 2026?
Um erro num sistema automatizado de manutenção de rede da Azure marcou dispositivos adicionais como parte de um evento de manutenção de rotina, removendo rotas de IP de mais equipamentos do que o previsto na região West US e cortando tráfego de e para essa zona.
Esta falha foi um ciberataque?
Não. A Microsoft atribuiu o incidente a um erro interno num processo de automação de manutenção, sem indícios de intrusão ou ataque externo.
Uma indisponibilidade deste tipo obriga a notificar a CNPD?
Não necessariamente. Uma interrupção temporária não constitui, por si só, uma violação de dados pessoais nos termos do RGPD, desde que não haja acesso não autorizado, perda ou destruição de informação — mas a ocorrência deve ser documentada por questões de responsabilização.
Que obrigações têm as empresas portuguesas relativamente à continuidade de serviços cloud?
O Regime Jurídico da Cibersegurança, que transpõe a NIS2, exige gestão de risco e planos de continuidade de negócio que contemplem cenários de indisponibilidade de fornecedores cloud, incluindo testes periódicos desses planos.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft (avisos da Azure e do Microsoft 365), bem como em relatos de meios especializados. Os detalhes podem ser atualizados na revisão pós-incidente final da empresa.