O Apagão de Novembro 2026 do Microsoft 365: o risco de depender de um único fornecedor: Perguntas, Hipóteses e Propostas

Nota: Texto redigido na manhã de 13 de novembro, com o incidente ainda em curso. Os factos aqui descritos correspondem às comunicações públicas da Microsoft e à imprensa internacional até cerca das 05h00 (hora de Lisboa) e podem ser alterados por informação posterior.

O que sabemos:

12 de novembro, por volta das 1800, a Microsoft começou a registar uma interrupção de grande escala no Microsoft 365. Ficaram indisponíveis ou degradados, em várias regiões do mundo, o Exchange Online, o Teams, o SharePoint Online, o Copilot 365 e o Defender para Office 365. Ficaram também indisponíveis ferramentas de administração como o Intune e o centro de administração do Microsoft 365: em suma, os próprios técnicos responsáveis por diagnosticar o problema nas organizações ficaram sem acesso às consolas de que precisavam para trabalhar. O incidente está registado com a referência MO1550821 (e EX1550543 para o Exchange) em https://status.cloud.microsoft/m365/referrer=serviceStatusRedirect.

Segundo as atualizações publicadas pela própria Microsoft, a sequência dos eventos foi:

1. um número elevado de servidores começou a falhar as verificações automáticas de saúde (health checks) e foi retirado de serviço.

2. O tráfego passou a concentrar-se nos servidores restantes, que ficaram sobrecarregados. A Microsoft identificou depois como provável origem um componente dos próprios servidores responsável por processar essas verificações. 3. Pelas 2100, a Microsoft testou um método alternativo de verificação de saúde, que permitiu devolver ao serviço uma parte dos servidores afetados. Posteriormente, admitiu que as medidas tomadas não tinham produzido o alívio esperado: um processo (“component”) central dos servidores (descrito, numa atualização posterior, como o processo responsável por estabelecer ligações seguras) ficava sobrecarregado e deixava de processar mais pedidos.

4. Já na madrugada de 13 de novembro, a Microsoft informou que os servidores repostos em serviço pareciam inicialmente saudáveis, mas voltavam a deixar de responder assim que recebiam tráfego. A empresa passou a limitar temporariamente certos tipos de tráfego em algumas localizações (não sabemos quais), a reconstruir um grupo de servidores com uma configuração de software anterior e a reverter uma alteração recente de configuração de rede.

5. Na atualização mais recente que conseguimos confirmar, a Microsoft referia um aumento súbito do volume de chamadas dos serviços de encaminhamento para os servidores de backend, cuja causa ainda estava a investigar, e servidores “presos” num estado anómalo. Na manhã de 13 de novembro ão havia data prevista para a recuperação total dos sistemas afetados.

A pergunta do dia: Foi um ciberataque?

Na verdade, até ao momento, nada o indica. Um porta-voz da Microsoft afirmou à imprensa que não há qualquer indicação de que se trate de um ciberataque, e uma atualização oficial posterior repetiu que não há indício de atividade maliciosa. Nenhum grupo reivindicou o incidente.

A CpC regista, no entanto, uma evolução nas explicações. Numa fase inicial, a Microsoft afirmou não ter identificado alterações recentes que coincidissem com o início do problema; horas depois, estava a avaliar e, finalmente, a reverter alterações de configuração identificadas como possíveis causas da anomalia. A causa raiz não está – portanto – confirmada e a Microsoft ainda não explicou por que razão o processo de ligações seguras fica sobrecarregado. Até à publicação de um relatório pós-incidente, qualquer atribuição — seja a um erro interno, a uma alteração de configuração ou a um fator externo — é prematura e especulativa. A hipótese mais consistente com os dados conhecidos deste incidente é a de uma falha interna em cascata, em que mecanismos automáticos concebidos para proteger o serviço acabaram por amplificar a perda de capacidade.

Uma lição técnica: o sinal estava errado, a reação também

Neste incidente há duas falhas distintas que convém separar:

1. A primeira é que o sinal (a verificação de saúde) terá produzidp uma leitura errada, ou pelo menos incompleta, sobre o estado dos servidores.

2. A segunda é que o sistema agiu sobre esse sinal de forma automática e em massa, retirando capacidade de produção precisamente quando esta era mais necessária. A recuperação parcial só começou quando se recorreu a um método de verificação diferente.

A pergunta que deve ficar documentada, na Microsoft e em qualquer organização que opere infraestruturas críticas, é esta: quando dois sinais de saúde discordam, qual prevalece, e se existe um limite a partir do qual um sistema automático deixa de poder retirar servidores de serviço sem intervenção humana? Aparentemente, a resposta era negativa na Microsoft.

O risco de uma Europa assente num único ponto de falha

Este apagão não é um caso isolado. Em 2026 a Microsoft já tinha registado outras interrupções relevantes do Microsoft 365, incluindo uma de quase 10 horas em janeiro. Mas o problema de fundo não é a Microsoft em particular: é a concentração.

Segundo a Synergy Research Group, a Amazon, a Microsoft e a Google detêm em conjunto cerca de 70% do mercado europeu de infraestrutura cloud, enquanto os fornecedores europeus se ficam por cerca de 15% (era 29% em 2017). No software de produtividade e comunicação a concentração é ainda mais evidente: em muitas organizações portuguesas, públicas e privadas, o correio eletrónico, as reuniões, os documentos partilhados, a gestão de dispositivos e a proteção contra ameaças dependem do mesmo fornecedor e, em grande medida, da mesma infraestrutura.

Quando tudo está no mesmo sítio, uma única falha (acidental ou provocada) desliga em simultâneo as comunicações internas, com clientes e cidadãos e as ferramentas de segurança que deveriam ajudar a gerir a crise. Ontem foi um componente de verificação de saúde. Mas amanhã pode ser uma alteração de configuração mal testada, uma decisão política tomada fora da União Europeia ou um ataque deliberado contra um alvo que, pela sua concentração, se tornou extraordinariamente valioso.

A própria União Europeia reconheceu este risco no setor financeiro: ao abrigo do Regulamento DORA (Regulamento (UE) 2022/2554), as Autoridades Europeias de Supervisão designaram em novembro de 2025 a Microsoft Ireland Operations Limited como um dos 19 prestadores terceiros críticos de serviços de TIC, sujeitos a supervisão direta europeia. Esse reconhecimento existe para bancos e seguradoras, mas a mesma dependência atravessa administrações públicas, escolas, hospitais, autarquias e PME, sem equivalente de supervisão.

A CpC entende que a resiliência digital europeia não se resolve apenas com cláusulas contratuais. Exige diversidade real de fornecedores para funções críticas, planos de continuidade testados que pressuponham a indisponibilidade total do fornecedor principal, e uma política pública que dê prioridade, nas compras públicas, a soluções interoperáveis e a fornecedores alternativos (incluindo europeus) para que a substituição seja possível na prática e não apenas no papel.

Os cortes de pessoal da Microsoft: o que é facto e o que é pergunta

Circulou a ideia de que a Microsoft estaria a despedir um terço dos seus trabalhadores, cerca de 60 mil pessoas. A afirmação não está correta e importa corrigi-la.

O que se sabe: a 26 de outubro de 2026, a Microsoft anunciou uma oferta de saída voluntária (Voluntary Exit Offer) dirigida a cerca de 60 mil trabalhadores elegíveis nos Estados Unidos, Canadá, Reino Unido e Índia, o que corresponde a aproximadamente 27% de uma força de trabalho de cerca de 223 mil pessoas. Não se trata de despedimentos, mas de uma oferta de rescisão voluntária, e a Microsoft declarou esperar uma adesão inferior a 5% dos elegíveis. As saídas aceites produzirão efeitos a 31 de dezembro. Esta oferta soma-se a cerca de 4800 despedimentos anunciados em julho de 2026, a um programa de reforma voluntária em abril e a cerca de 15 mil despedimentos em 2025. Em 30 de junho de 2026, o número de trabalhadores da Microsoft registou a primeira descida anual numa década.

O que não se sabe: não existe, até ao momento, qualquer evidência pública de que este incidente esteja relacionado com os processos de redução de pessoal. Apresentar o apagão como consequência direta dos cortes seria uma afirmação sem suporte.

O que é legítimo perguntar: a literatura sobre fiabilidade de sistemas reconhece que a perda de conhecimento operacional, a incerteza sobre o futuro profissional e a sobrecarga das equipas que ficam são fatores de risco. Um programa que torna elegível para saída mais de um quarto dos trabalhadores cria, durante semanas, um período em que pessoas com responsabilidade na manutenção de sistemas críticos estão a ponderar se ficam ou se saem. A CpC considera que a Microsoft deve esclarecer, no relatório pós-incidente, se as equipas responsáveis pelos componentes envolvidos foram afetadas por estes programas e que medidas de retenção de conhecimento e de continuidade operacional adotou. O mesmo se deve perguntar a qualquer fornecedor crítico que reduza pessoal: os reguladores europeus, nomeadamente no âmbito da supervisão DORA, têm instrumentos para o fazer.

O que a Microsoft poderia ter feito melhor

Sem prejuízo das conclusões do relatório pós-incidente, as informações públicas permitem identificar várias fragilidades evidentes:

1. A contenção do raio de impacto: O facto de a Microsoft ter ponderado, a meio do incidente, isolar o tráfego dentro de cada região para permitir recuperações independentes sugere que essa compartimentação não estava a funcionar por omissão.

2. A prudência dos mecanismos automáticos: Sistemas que retiram servidores de serviço devem ter limites: quando uma fração anormalmente elevada da frota falha ao mesmo tempo, é mais provável que o problema esteja no mecanismo de verificação do que em todos os servidores. Nesse cenário, o comportamento seguro é travar a remoção automática e alertar antes operadores humanos.

3. A gestão de novas tentativas: Quando um serviço falha, milhões de clientes Outlook, Teams e aplicações integradas repetem automaticamente os pedidos. Sem mecanismos robustos de recuo progressivo (backoff) e de limitação de pedidos, os servidores que regressam ao serviço são imediatamente submersos.

4. A independência das ferramentas de gestão e comunicação: Os administradores ficaram sem acesso ao centro de administração e a ferramentas de gestão de dispositivos durante o incidente, e grande parte da comunicação pública foi feita através de uma rede social de terceiros.

5. A transparência.: A comunicação foi frequente, o que se reconhece, mas houve afirmações iniciais sobre alterações recentes que foram depois revistas.

O que devem fazer as equipas de IT em Portugal para comunicar com os utilizadores

A primeira regra é não depender do sistema que falhou para avisar que este falhou. Se o correio e o Teams estão em baixo, a comunicação tem de chegar por outro canal: SMS, uma lista de difusão por mensagem preparada com antecedência, uma página de estado alojada fora do Microsoft 365, a intranet se estiver noutra infraestrutura, ou mesmo cartazes e chefias diretas nas instalações. Estes canais e as listas de contactos devem estar preparados e guardados fora da plataforma principal antes de serem necessários.

A primeira mensagem deve sair cedo e ser simples: há uma falha global da Microsoft, não é um problema do computador de cada um, não é um ataque à organização, a equipa de IT está a acompanhar e haverá nova informação a uma hora definida. Cumprir essa hora, mesmo sem novidades, é o que mantém a confiança.

Convém dar instruções práticas para evitar danos colaterais: não reinstalar aplicações, não reiniciar repetidamente nem alterar configurações; verificar a pasta de itens enviados antes de reenviar mensagens, porque o primeiro envio pode ter passado; continuar a trabalhar com cópias locais e sincronizar depois; e indicar alternativas aprovadas para reuniões e contactos urgentes, evitando que cada pessoa improvise com ferramentas não autorizadas.

Deve também sair, no próprio dia, um aviso de segurança. Incidentes desta dimensão são sistematicamente aproveitados para campanhas de phishing — mensagens falsas para “restaurar a caixa de correio” ou “revalidar a conta” e telefonemas de alegados técnicos de IT. Dizer de forma clara que a equipa de IT nunca pedirá palavras-passe nem códigos de autenticação multifator, nem durante a falha nem depois dela, previne a maior parte destes ataques.

Por fim, documentar. As equipas devem registar a hora de início e de fim do impacto, os serviços e utilizadores afetados e as perdas operacionais. Esse registo serve para três fins: apresentar o pedido de crédito ao abrigo do acordo de nível de serviço, cumprir eventuais obrigações de notificação de incidentes (no regime jurídico da cibersegurança ou, no setor financeiro, no DORA) e fundamentar a revisão do plano de continuidade de negócio. Também os clientes e cidadãos que dependem da organização devem ser informados se o serviço que lhes é prestado foi afetado.

Seremos compensados? E é legal não sermos?

A resposta curta é: muito pouco, e mesmo assim só se o pedirmos…

Para clientes empresariais, o acordo de nível de serviço da Microsoft (SLA for Microsoft Online Services) garante uma disponibilidade mensal de 99,9% para serviços como o Exchange Online, o Teams e o SharePoint. Abaixo desse limiar, o cliente pode receber um crédito de 25% da mensalidade do serviço afetado, de 50% abaixo de 99% e de 100% abaixo de 95%. Mas o crédito não é automático: tem de ser pedido pelo administrador, com a informação exigida, até ao fim do mês seguinte ao do incidente. É abatido em faturas futuras, não é reembolso em dinheiro, e o SLA define-o como o único remédio contratual para o incumprimento do nível de serviço. Um dia inteiro sem correio e sem reuniões pode custar a uma organização muito mais do que o valor de uma mensalidade.

Para consumidores com subscrições Microsoft 365 Personal ou Family, a situação é diferente. Em Portugal, o Decreto-Lei n.º 84/2021, que transpôs a Diretiva (UE) 2019/770 sobre conteúdos e serviços digitais, reconhece ao consumidor, em caso de falta de conformidade de um serviço digital pago, direitos que podem incluir a redução proporcional do preço correspondente ao período em que o serviço não esteve conforme, ou a resolução do contrato, nos termos e condições aí previstos. Estes direitos não podem ser afastados por cláusulas contratuais.

A questão da legalidade merece, por isso, ser colocada com precisão. A CpC não afirma que os termos da Microsoft sejam ilegais, mas considera que há perguntas legítimas para os reguladores e para os tribunais. No caso dos consumidores, os termos de serviço e a prática de não compensação devem ser confrontados com o Decreto-Lei n.º 84/2021 e com o regime das cláusulas abusivas. No caso das empresas, o regime português das cláusulas contratuais gerais (Decreto-Lei n.º 446/85) proíbe cláusulas que excluam ou limitem a responsabilidade por danos causados com dolo ou culpa grave; resta saber se um crédito limitado definido como “único remédio” é compatível com essa regra quando a falha resulte de negligência grave — tendo em conta que a lei aplicável e o foro fixados nos contratos da Microsoft para clientes europeus podem não ser os portugueses, o que deve ser verificado caso a caso. E, num plano mais amplo, importa perguntar se é aceitável que um prestador designado como crítico para o sistema financeiro europeu, e abrangido como prestador de computação em nuvem pela Diretiva NIS2, possa transferir para os clientes praticamente todo o custo das suas próprias falhas.

Perguntas e recomendações CpC

1. Ao Centro Nacional de Cibersegurança, a CpC pergunta se recebeu informação sobre o impacto deste incidente em entidades essenciais e importantes em Portugal, e se foi informado pela autoridade competente do Estado-Membro do estabelecimento principal da Microsoft na União, nos termos da Diretiva NIS2 e do Decreto-Lei n.º 125/2025.

2. Ao Banco de Portugal, à ASF e à CMVM, a CpC pergunta que impacto teve o incidente nas entidades financeiras supervisionadas e se a questão será levada à supervisão europeia dos prestadores críticos ao abrigo do DORA.

3. À Direção-Geral do Consumidor, a CpC pergunta se os termos de serviço do Microsoft 365 para consumidores respeitam os direitos de redução de preço previstos no Decreto-Lei n.º 84/2021.

4. Ao Governo e à Assembleia da República, a CpC recomenda que a dependência da Administração Pública de um único fornecedor para funções críticas seja avaliada e que se inclua, nas regras de contratação pública, a exigência de planos de continuidade testados e de interoperabilidade efetiva.

5. Às organizações portuguesas afetadas, a CpC recomenda que tratem este incidente como um teste real: verifiquem se conseguiram comunicar com os seus trabalhadores e clientes sem o Microsoft 365, documentem os prejuízos, apresentem os pedidos de crédito dentro do prazo e revejam os seus planos de continuidade pressupondo que o fornecedor principal pode ficar indisponível durante um dia inteiro.

Algumas fontes:

https://www.theregister.com/saas/2026/11/12/microsoft-struggling-to-fix-massive-cloud-outage-thats-taken-down-email-and-intune/5309531
https://www.abc.net.au/news/2026-11-13/microsoft-outage-affects-users-worldwide/107381050

https://azureblog.co.uk/posts/microsoft-365-outage-12-november-2026/ https://x.com/MSFT365Status/status/2121045804852945188 https://www.bloomberg.com/news/articles/2026-10-26/microsoft-to-offer-buyouts-to-60-000-workers-in-latest-cost-cut https://fortune.com/2026/10/30/microsoft-voluntary-exit-offer-buyout-60000-employees/
https://www.pcgamer.com/gaming-industry/microsoft-is-looking-to-cut-more-than-25-percent-of-its-workforce/ https://www.ksl.com/article/51594425/microsoft-joins-aidriven-tech-layoff-wave-with-4800-job-cuts
https://srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15
https://www.dudkowiak.com/blog/esas-publish-the-first-list-of-critical-ict-third-party-providers-under-dora https://learn.microsoft.com/training/modules/describe-support-offerings-for-microsoft-365-services/3-explain-service-level-agreements