Resumo Executivo:

Entre quinta-feira, 12 de novembro, e sexta, 14, o Microsoft 365 sofreu a interrupção mais longa da sua história. Em Portugal, o próprio Governo reconheceu que a falha condicionou a generalidade dos serviços da Administração Pública. A CpC estima que, só no período entre as 18h00 de quinta-feira e as 14h00 de sexta-feira, a perda de produção para a economia portuguesa se situe entre 25 e 180 milhões de euros, com um cenário central na ordem dos 75 milhões de euros, dos quais apenas, uma parte será recuperada nos dias seguintes. O valor não é dramático face ao PIB anual, é certo, mas o este episódio revela sobre a dependência do Estado e de muitas autarquias portuguesa que a dependência de um único fornecedo é um risco grave que deve ser devidamente ponderado e mitigado.

O que aconteceu:

Segundo a Microsoft, o problema começou às 16h17 de quinta-feira (hora de Lisboa) no Exchange Online, a plataforma que gere o correio eletrónico e os calendários na nuvem. A partir das 18h00 o impacto tornou-se generalizado na Europa e foi nessa altura que a maioria dos utilizadores portugueses deu pelo problema: Foram afetados o Outlook, o Exchange Online, o SharePoint, o Copilot e várias ferramentas de segurança e administração. As mensagens e chamadas do Teams funcionaram em grande parte, mas os calendários e o agendamento deixaram de funcionar porque dependem do Outlook.

A multinacional explicou que um grande número de servidores começou a falhar as verificações automáticas de saúde e foi retirado de serviço, sobrecarregando os restantes. Os servidores que regressavam ao serviço voltavam a deixar de responder assim que recebiam tráfego. Na manhã de sexta-feira, a Microsoft alargou para 48 horas o prazo de retenção do correio em fila, para evitar a perda de mensagens. Na tarde de sexta-feira, num comunicado em que pediu desculpa, afirmou que se tratou de um problema técnico e não de um ciberataque nem um produto de inteligência artificial ou de agentes de IA descontolados mas que fora provocado por uma falha introduzida numa atualização anterior da capacidade de rede, que se manifestou depois de uma alteração de rede recente. A reposição completa só foi concluída na madrugada de sábado. O relatório pós-incidente, com a causa raiz detalhada, a 13.11.2026 não tinha sido publicado.

A escala foi global: o Downdetector registou mais de 7,4 milhões de queixas em 74 países e territórios. A Reuters noticiou perturbações em organismos públicos dos Estados Unidos, da Austrália e do Japão. No Reino Unido, o Serviço Nacional de Saúde recorreu a sistemas alternativos e a registos em papel. A Euronext, que gere a bolsa de Lisboa, teve perturbações no correio eletrónico. A agência de notação Morningstar DBRS estima que os pagamentos de seguros a nível mundial fiquem entre 300 e 500 milhões de dólares.

Em Portugal

Em comunicado, a Secretaria-Geral do Governo confirmou que, desde quinta-feira, a utilização das ferramentas Microsoft 365, “utilizada pela generalidade dos serviços da Administração Pública e do próprio Governo”, estava condicionada. Membros do Governo ficaram sem acesso ao Outlook e foram afetadas entidades sob tutela do Ministério da Saúde. Foi noticiado que a falha não teve impacto na atividade assistencial dos hospitais. Num levantamento anterior com 250 contratos públicos e 206 entidades, a CpC identificou exposição direta ou provável ao Microsoft 365 em 91% delas, incluindo 17 entidades de saúde e o serviço de proteção civil de uma região autónoma.

O que aconteceu com a Microsoft?

Nas últimas horas circularam dois tipos de informação sobre as causas da falha do Microsoft 365:

1. Uma publicação anónima na plataforma Blind, atribuída a um trabalhador da Microsoft na Índia, que afirma que os engenheiros seniores que conheciam os sistemas antigos saíram da empresa depois de vagas de despedimentos e saídas voluntárias, que uma reversão que antes demorava 45 minutos passou a demorar cinco horas e que até as ferramentas internas de gestão de incidentes deixaram de funcionar.

2. O segundo é uma reflexão de um profissional do setor sobre a acumulação de código gerado por inteligência artificial que ninguém lê por inteiro, sobre equipas avaliadas pela velocidade e não pela qualidade do código gerado e sobre a perda de intenção quando várias pessoas alteram, com o apoio de assistentes de IA, um sistema desenhado por outras. É uma opinião, não uma prova, e a Microsoft afirma expressamente que a IA não teve papel neste incidente. Mas a preocupação de fundo é legítima e acompanha um debate real na engenharia de software: quanto do código de infraestruturas críticas é hoje produzido ou alterado com ferramentas de IA, como é revisto, e quem guarda o conhecimento de como os sistemas foram concebidos.

Também o artigo da Ars Technica que circulou com este material contém elementos que a CpC só conseguiu confirmar por via indireta. A perturbação de serviços públicos no Japão é confirmada pela Reuters. Já a afirmação de Ciaran Martin, antigo responsável do National Cyber Security Centre britânico, de que este seria um dos maiores apagões de sempre, as dificuldades do Supremo Tribunal das Filipinas e de um gabinete do xerife no Colorado, bem como os médicos que não conseguiram enviar atualizações de medicação aos doentes, são relatados pela NBC News e citados pela Ars Technica, sem outra fonte que a CpC tenha podido consultar. Quanto ao número de utilizadores, a Ars Technica refere mais de 450 milhões de subscrições comerciais pagas, segundo estimativa da Microsoft de janeiro, e a Euronews refere mais de 430 milhões de pessoas que usam as aplicações 365. Ambos os números apontam assim para a mesma ordem de grandeza.

A posição da CpC é a seguinte. Atribuir o apagão aos despedimentos ou ao código gerado por IA seria, neste momento, uma afirmação sem suporte. Mas estas são perguntas que o relatório pós-incidente deve responder e que os reguladores europeus têm meios para exigir.

Quanto custou esta paragem à economia portuguesa: estimativa da CpC

A CpC estimou o impacto económico no período entre as 18h00 de quinta-feira, 12, e as 14h00 de sexta-feira, 13 de novembro. Trata-se de uma estimativa própria, por ordem de grandeza, baseada em pressupostos explícitos que qualquer pessoa pode rever. Não é um número oficial.

O ponto de partida é o PIB de 2025, que segundo o INE foi de 308,5 mil milhões de euros. Distribuindo este valor por cerca de 250 dias úteis, cada dia útil corresponde a cerca de 1.234 milhões de euros de produção, ou 154 milhões por hora num dia de oito horas. Esta simplificação sobrestima ligeiramente o valor horário, porque parte da produção ocorre ao fim de semana e fora do horário normal.

Dentro da janela considerada, o tempo de trabalho afetado é menor do que as 20 horas totais. Contámos a última hora de quinta-feira, das 18h00 às 19h00, a meia intensidade, e a manhã de sexta-feira, das 9h00 às 14h00. São 5,5 horas úteis equivalentes, que correspondem a cerca de 848 milhões de euros de PIB gerado nesse período.

Nem toda essa produção depende do Microsoft 365, e nem toda a que depende ficou parada. Por isso aplicámos dois fatores. O primeiro é a exposição, ou seja, a parte da produção gerada por organizações que dependem do correio e dos calendários do Microsoft 365. Estimámo-la entre 30% e 60%, com 45% no cenário central. Esta estimativa tem em conta que o Governo afirma que a plataforma é usada pela generalidade da Administração Pública, que segundo a Comissão Europeia cerca de 45% das empresas portuguesas compram serviços na nuvem, que as grandes empresas, responsáveis por grande parte do valor acrescentado, os usam com muito mais frequência, e que nem toda a nuvem é da Microsoft. O segundo fator é a perda efetiva de produtividade nas organizações expostas, que estimámos entre 10% e 35%, com 20% no cenário central. Ficou indisponível o correio, os calendários e parte dos ficheiros partilhados, mas as aplicações do Office instaladas nos computadores e grande parte das mensagens do Teams continuaram a funcionar, e a corretora de seguros Marsh observa que a perda de correio eletrónico tem normalmente um impacto financeiro limitado.

O resultado desta arimética é o seguinte:

Cenário baixo (exposição de 30%, perda de 10%): cerca de 25 milhões de euros, ou 0,008% do PIB anual.

Cenário central (exposição de 45%, perda de 20%): cerca de 76 milhões de euros, ou 0,025% do PIB anual.

Cenário alto (exposição de 60%, perda de 35%): cerca de 178 milhões de euros, ou 0,058% do PIB anual.

Estes valores medem a produção perdida ou adiada. Parte dela será recuperada nos dias seguintes, com trabalho adicional, pelo que a perda definitiva para o PIB será menor. Admitindo que entre um quarto e metade do trabalho atrasado é recuperado, a perda definitiva no cenário central rondará os 45 milhões de euros, num intervalo de 13 a 134 milhões.

A estimativa deixa de fora vários custos e é, por isso, conservadora. Não inclui o período entre as 16h17 e as 18h00 de quinta-feira, que no cenário central acrescentaria cerca de 24 milhões de euros. Também não inclui as perturbações que continuaram na tarde de sexta-feira, enquanto se escoavam as filas de correio. Ficam ainda de fora as horas extraordinárias das equipas de informática, os prazos falhados, as decisões adiadas, os custos de eventuais burlas aproveitando a confusão e o impacto não mercantil em serviços como a saúde, a justiça e a proteção civil, que o PIB não com precisão.

A conclusão que importa retirar não está no número em si. Um único fornecedor estrangeiro, por um erro técnico interno, conseguiu condicionar durante um dia útil a generalidade da Administração Pública portuguesa sem que o Estado tivesse alternativa operacional, poder contratual para exigir uma reparação ou sequer informação própria sobre o que estava a acontecer. A CpC convida o INE, o Gabinete de Estratégia e Estudos do Ministério da Economia e o Banco de Portugal a produzirem uma estimativa com dados próprios, que será sempre melhor do que a nossa e a exigirem – todos – a aplicação da reparação de danos prevista no contrato de serviço com a Microsoft.

Impacto em Portugal: Estado, Autarquias e Hospitais

Usando os dados públicos (registo MX dos DNS domains) a CpC apurou que, atualmente, de 308 municípios portugueses 187 usam Microsoft 365 (60.3%)
Organismos do Estado (Ministérios e outros), em 201, 156 ousam (77.6%)
e que hospitais, dos 95 analisados, 86 dependiam do Microsoft 365 (90.5%)

Propostas CpC ao Governo

1. Realizar, no prazo de 90 dias, um inventário público das dependências críticas da Administração Pública central de fornecedores únicos de serviços digitais, começando pelo correio eletrónico, pelas comunicações internas, pela gestão de identidades e dispositivos e pela proteção contra ameaças. Para cada função crítica, o inventário deve identificar o fornecedor, a localização dos dados, o tempo máximo de indisponibilidade tolerável e a alternativa disponível, se existir.

2. Criar um canal mínimo de comunicação de contingência do Estado, independente do Microsoft 365 e de qualquer outro fornecedor principal, testado regularmente e com listas de contactos guardadas fora da plataforma principal, que permita ao Governo, aos serviços e às autarquias comunicarem entre si quando o sistema principal falha. Comunicar que o correio não funciona através do próprio correio não é um plano.

3. Rever os modelos de contratação pública de software e serviços na nuvem, nomeadamente nos acordos-quadro de compras centralizadas, para exigir planos de continuidade testados, relatório pós-incidente obrigatório e entregue ao contratante, créditos de serviço atribuídos automaticamente e não apenas a pedido, penalizações proporcionais ao impacto real, direito de auditoria e portabilidade efetiva dos dados em formatos abertos, como previsto na Lei n.º 36/2011, que adota as normas abertas nos sistemas informáticos do Estado.

4. Lançar projetos-piloto de diversificação para funções críticas, incluindo soluções europeias e de código aberto, a exemplo de administrações que já iniciaram esse caminho, como o estado alemão de Schleswig-Holstein e o Ministério dos Assuntos Digitais da Dinamarca. O objetivo não é substituir um fornecedor por outro, mas garantir que existe uma alternativa operacional real para o essencial.

5. Emitir uma orientação uniforme aos serviços sobre os prazos administrativos que terminaram durante a indisponibilidade, à luz da alínea f) do artigo 87.º do Código do Procedimento Administrativo, para que os cidadãos e as empresas não sejam prejudicados por uma falha que não lhes é imputável.

6. Exigir formalmente à Microsoft o relatório pós-incidente e a atribuição automática de créditos de serviço a todas as entidades públicas afetadas, e levar ao Conselho da União Europeia a necessidade de uma supervisão dos fornecedores críticos de serviços na nuvem que não se limite ao setor financeiro, como sucede hoje ao abrigo do Regulamento DORA.

Propostas às câmaras municipais

1. Avaliar, com o Centro Nacional de Cibersegurança, se o incidente deve ser notificado ao abrigo do Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025), tendo em conta que as autarquias com mais de 75 trabalhadores serão provavelmente abrangidas como entidades públicas relevantes. Os prazos de notificação de incidentes significativos são curtos.

2. Garantir que os serviços municipais de proteção civil e os canais de alerta à população não dependem, em caso algum, do Microsoft 365 ou de outro fornecedor único. Os contactos de emergência e os procedimentos de ativação devem existir também em papel e em canais alternativos, como telefone, SMS e rádio.

3. Preparar procedimentos de atendimento ao munícipe em modo degradado, com registo manual dos pedidos, informação ao público através de um sítio na internet alojado fora da plataforma principal e regras claras sobre prazos.

4. Documentar as horas de impacto, os serviços afetados e os custos, e apresentar os pedidos de crédito de serviço dentro do prazo contratual, que no caso da Microsoft termina no final do mês seguinte ao do incidente, ou seja, a 31 de dezembro de 2026.

5. Aproveitar as comunidades intermunicipais e as áreas metropolitanas para partilhar soluções de contingência e negociar em conjunto melhores condições contratuais. Nenhuma autarquia isolada tem peso negocial perante um fornecedor global, mas o conjunto dos municípios tem.

6. Fazer, pelo menos uma vez por ano, um exercício em que se simula a indisponibilidade total do fornecedor principal durante um dia útil, e apresentar os resultados à assembleia municipal.

Nota final

A CpC não defende o abandono de qualquer fornecedor em particular. Defende que nenhuma função essencial do Estado fique sem alternativa quando um fornecedor falha. Este incidente foi um erro técnico e não um ataque. Mas o efeito prático de um ataque bem-sucedido, ou de uma decisão política tomada fora da União Europeia, seria muito semelhante. Desta vez, o Estado esteve um dia útil condicionado sem plano B. A pergunta que o Governo e as autarquias devem responder é se, da próxima vez, o terão.

Nota prática: pedir o crédito SLA à Microsoft pela falha de 12–13 de novembro

Em resumo

As entidades públicas afetadas pela falha global do Microsoft 365 de 12–13 de novembro de 2026 podem pedir um crédito ao abrigo do acordo de nível de serviço (SLA) da Microsoft, mas só se o pedirem, e o prazo deverá terminar a 31 de dezembro de 2026.

O crédito não é automático nem é pago em dinheiro: é abatido em faturas futuras e cobre apenas o serviço afetado. Mesmo assim, deixar passar o prazo é abdicar de um direito contratual e de um registo formal do incumprimento.

O que fazer já: confirmar como as licenças foram compradas, recolher as provas do impacto e submeter o pedido (diretamente ou através do parceiro) antes do Natal, para ter margem.

Quem faz o pedido

O caminho depende de como a entidade comprou as licenças. Confirme-o primeiro com o serviço de informática ou no contrato.

Se a entidade comprou as licenças através de um revendedor ou parceiro Microsoft (o chamado modelo CSP), não pode pedir o crédito diretamente: é o parceiro que o submete, no Partner Center da Microsoft, a pedido da entidade.

Se a entidade comprou diretamente à Microsoft, por contrato Enterprise ou compra direta, o pedido é feito pelo administrador do tenant da entidade, através de um pedido de suporte no centro de administração do Microsoft 365.

Se a entidade comprou através de um parceiro, deve enviar-lhe por escrito, a partir de um endereço do domínio da entidade, o pedido expresso de crédito e as provas listadas abaixo.

Passo a passo:

1.  Confirmar a forma de compra (parceiro CSP ou contrato direto) e quem tem acesso de administrador ao tenant.

2.  Abrir o Service Health no centro de administração do Microsoft 365 e anotar os identificadores dos incidentes de 12–13 de novembro (por exemplo, códigos do tipo EX… para o Exchange Online e TM… para o Teams).

3.  Reunir as provas de impacto (secção seguinte), incluindo registos internos de chamadas ao suporte e mensagens enviadas aos trabalhadores.

4.  Submeter o pedido: diretamente, através de um pedido de suporte no centro de administração; ou através do parceiro, por escrito e a partir de um endereço do domínio da entidade.

5.  Guardar o número do pedido e a resposta da Microsoft ou do parceiro.

6.  Fazer o pedido até 31 de dezembro de 2026. A regra é um mês após o fim do mês de faturação do incidente; em compras via parceiro, o mês de faturação pode não coincidir com o mês civil, por isso confirme a data exata com o parceiro.

7.  Registar o resultado (aprovado, valor, recusa e motivo), para memória futura e para eventual reporte ao CNCS ou à tutela.

Informação a reunir:

A Microsoft exige elementos concretos; o nome da entidade e o número de um pedido de suporte não chegam.

[ ] Identificador do tenant (GUID)

[ ] Identificador(es) do incidente, retirados do Service Health

[ ] Hora de início e de fim do impacto sentido pela entidade

[ ] Serviços afetados (Exchange Online, Teams, SharePoint, OneDrive, Intune…)

[ ] Número e localização dos utilizadores afetados

[ ] Descrição do que foi tentado para resolver ou contornar o problema

[ ] Pedido expresso de crédito, enviado de um endereço do domínio da entidade (endereços pessoais não são aceites)

[ ] Indicação de se as subscrições foram compradas via parceiro (CSP)

Convém guardar também, para uso interno, uma estimativa das perdas operacionais: atendimentos não realizados, prazos administrativos afetados, horas de trabalho perdidas. Não aumentam o crédito, mas fundamentam o reporte de incidente e a revisão do plano de continuidade.

O SLA garante 99,9% de disponibilidade mensal para serviços como o Exchange Online, o Teams e o SharePoint. Abaixo desse limiar, há direito a crédito.

Se a disponibilidade mensal ficar abaixo de 99,9%, o crédito é de 25% da mensalidade do serviço afetado; abaixo de 99%, sobe para 50%; e abaixo de 95%, chega a 100%.

Um mês tem cerca de 720 horas; 99,9% admite cerca de 43 minutos de falha. Um dia de indisponibilidade fica abaixo de 99%, o que, se reconhecido, dá 50% da mensalidade do serviço afetado.

Limites: o crédito aplica-se só ao serviço que falhou, não à subscrição inteira; é abatido em faturas futuras e o SLA define o crédito como o único remédio contratual pelo incumprimento do nível de serviço. Não compensa os custos reais da paragem.
Foram 20 horas de falha. Como novembro tem 30 dias, ou seja 720 horas, a disponibilidade do mês fica em 720 − 20 / 720 = 97,2%

Abaixo de 99% mas acima de 95%, o que corresponde ao escalão de 50% de crédito sobre a mensalidade do serviço afetado.

O cálculo da Microsoft é por utilizador. O SLA mede a disponibilidade em “minutos de utilizador” afetados, não em horas.