Durante quase dois dias, milhares de organizações em todo o mundo descobriram da pior maneira que o Microsoft 365 não falha apenas quando o correio eletrónico deixa de funcionar: falha quando a camada invisível que autentica cada pedido entre serviços deixa de responder. O incidente começou a 31 de agosto de 2026 com relatos de problemas no Exchange Online e rapidamente se estendeu ao Teams, SharePoint Online, OneDrive for Business, Microsoft Purview, Defender XDR, Microsoft Graph, ao centro de administração e até ao Copilot. Não houve indícios de ataque informático — a origem foi apontada pela própria Microsoft a uma configuração central de autenticação. Mas o efeito prático, para quem tenta trabalhar, é indistinguível de uma indisponibilidade provocada por um incidente de segurança.
Resposta rápida: A Microsoft reconheceu a 31 de agosto de 2026 um incidente de autenticação que bloqueou ou degradou o acesso a vários serviços do Microsoft 365, seguido sob os identificadores EX1464935 e MO1465074. A empresa atribuiu a falha a uma configuração central de autenticação partilhada por vários serviços internos e só a 2 de setembro declarou a maioria dos utilizadores sem impacto. Não há qualquer indicação de ataque. A ação recomendada para organizações é simples e urgente: documentar canais de comunicação alternativos, garantir contas de administração de emergência e testar o plano de continuidade para uma paragem do fornecedor de identidade.
O que falhou: não foi o correio, foi a confiança entre serviços
O ponto central deste incidente é técnico, mas tem consequências de gestão. Os serviços de nuvem da Microsoft não se limitam a autenticar pessoas: autenticam-se também uns aos outros, através de tokens, certificados e componentes de configuração que garantem que o Teams pode ler um ficheiro do SharePoint ou que o Purview pode indexar uma caixa de correio. Nas atualizações públicas, a Microsoft atribuiu a avaria a problemas de configuração central de autenticação «utilizada por múltiplos serviços internos dentro da infraestrutura do Exchange Online».
Foi essa dependência comum que transformou um problema de correio eletrónico num incidente transversal. A Microsoft abriu um segundo registo de incidente (MO1465074) ao confirmar que o impacto ia além do Exchange Online e atingia também o Microsoft Teams, o Microsoft Graph, o Microsoft Purview, o OneDrive for Business e o SharePoint Online, o centro de administração do Microsoft 365, o Microsoft 365 Copilot, o Universal Print e o Microsoft Defender XDR. A manutenção dos dois identificadores em paralelo teve uma lógica: o registo do Exchange concentrava a informação específica desse serviço, enquanto o registo mais amplo cobria todos os serviços afetados através da dependência de autenticação comum.
Cronologia do incidente
| Momento | Desenvolvimento |
|---|---|
| 31 ago. 2026, 17:30 UTC | A Microsoft reconhece o incidente EX1464935 após relatos de utilizadores sobre falhas no Exchange Online. |
| 31 ago. 2026 (tarde) | A causa é associada a problemas numa configuração central de autenticação usada por vários serviços internos. |
| 31 ago. 2026 (tarde) | É aberto o registo MO1465074, alargando o alcance confirmado a Teams, Purview, OneDrive, SharePoint e Defender XDR. |
| 31 ago. 2026 (noite) | A Microsoft testa uma estratégia de remediação numa parte da infraestrutura antes de a alargar. |
| 1 set. 2026 | Conectividade às caixas de correio restabelecida; telemetria com «tendências positivas de recuperação» cerca de 22 horas após o reconhecimento. |
| 2 set. 2026 | A Microsoft indica disponibilidade «estável acima de 99 por cento» e que a maioria dos utilizadores já não deveria sentir impacto. |
A sequência está documentada nas atualizações sucessivas da Microsoft: o incidente foi reconhecido às 17:30 UTC, quando a empresa começou a investigar um fluxo de relatos nas redes sociais sobre múltiplos problemas no Exchange Online. Na mesma noite, a Microsoft afirmou ter desenvolvido uma estratégia de remediação e estar a aplicá-la a uma parte da infraestrutura para testar a sua eficácia, ao mesmo tempo que confirmava que o problema do componente de autenticação afetava serviços para além do Exchange Online. Já a 1 de setembro a empresa referia «tendências positivas de recuperação» cerca de 22 horas depois do reconhecimento inicial e, a 2 de setembro, que a disponibilidade se mantinha estável acima de 99 por cento e que a maioria dos utilizadores já não deveria estar a sentir impacto.
A causa: o que está confirmado e o que não está
Este é o ponto onde convém separar factos de especulação. Circularam desde o primeiro dia teorias sobre um certificado expirado, alimentadas por capturas de erro partilhadas por administradores. A análise disponível é clara quanto ao alcance do que foi assumido publicamente: a Microsoft identificou uma causa preliminar numa configuração central de autenticação usada em vários serviços e não confirmou publicamente que um certificado expirado tenha estado na origem da avaria, pelo que essa explicação não deve ser tratada como facto. A mitigação consistiu em reaplicar os componentes de autenticação afetados e reiniciar a infraestrutura correlacionada para que essas alterações produzissem efeito de forma consistente.
Análises posteriores de empresas do setor apontam para um mecanismo mais específico, ainda assim compatível com a formulação oficial: a implementação de uma atualização de código no sistema de gestão de certificados digitais teria deixado de distribuir um subconjunto de novos certificados de autenticação, num problema que permaneceu latente até os certificados em vigor começarem a expirar. Enquanto não existir uma revisão pós-incidente pública e detalhada, a leitura prudente é a de uma falha de configuração na camada de identidade, sem envolvimento de terceiros maliciosos.
Como distinguir uma avaria do fornecedor de um ataque real
Para uma equipa de TI de uma PME, os sintomas de um incidente como este — falhas de autenticação, pedidos repetidos de credenciais, sessões que terminam, erros de conectividade — são exatamente os mesmos que se observam num comprometimento de identidades. Uma falha de autenticação pode, de facto, produzir sintomas muito semelhantes aos de um incidente de segurança, o que gera horas perdidas em diagnósticos internos e, pior, risco de decisões erradas em pânico (como reposições massivas de palavras-passe ou desativação de políticas de acesso condicional).
- Verificar primeiro o Service Health no centro de administração e o painel público de estado, procurando o identificador do incidente (por exemplo,
MO1465074) antes de iniciar qualquer remediação interna. - Confirmar se o problema é transversal a aplicações não relacionadas: problemas na camada de identidade manifestam-se habitualmente como falhas de autenticação generalizadas em várias aplicações, enquanto o falhanço de uma única aplicação aponta mais para a sua própria configuração ou cache de tokens.
- Não desligar controlos de segurança como reação à indisponibilidade. Desativar MFA ou políticas de acesso condicional durante uma avaria cria uma janela de exposição que sobrevive ao incidente.
- Registar tudo: horas, sintomas, identificadores de incidente e comunicações. Esse registo é a base de qualquer reclamação contratual e de eventual reporte regulatório.
Medidas concretas de resiliência que deveriam estar já em prática
A recomendação estrutural que emerge deste tipo de eventos é conhecida, mas continua mal implementada. As organizações devem ter procedimentos documentados para paragens da nuvem, canais de comunicação alternativos, cópias de segurança independentes, procedimentos de acesso administrativo e um método para determinar rapidamente se um problema tem origem interna ou no fornecedor. Saber que o fornecedor está em incidente pode poupar horas de diagnóstico desnecessário e permitir que a equipa se concentre em comunicar com os colaboradores e manter a operação.
Na prática, isso traduz-se em: contas de administração de emergência excluídas de dependências frágeis e com credenciais guardadas em cofre físico ou offline; uma lista de contactos e um canal de comunicação fora do Microsoft 365 (telefone, SMS ou uma plataforma de outro fornecedor); cópias de segurança de correio e ficheiros independentes do inquilino; e exercícios periódicos que simulem precisamente o cenário «o fornecedor de identidade está em baixo». Vale também revisitar a configuração do acesso condicional: as políticas aplicadas a grupos ou funções não podem ser avaliadas em tempo real durante uma interrupção, pelo que utilizadores que nem pertencem ao grupo indicado na política podem ver o acesso à aplicação negado.
Porque é que isto importa em Portugal
Em Portugal, a disponibilidade dos serviços deixou de ser apenas um tema de produtividade e passou a ser matéria de conformidade. Com a entrada em vigor do Regime Jurídico da Ciberseguraça aprovado pelo Decreto-Lei n.º 125/2025, que transpõe a Diretiva NIS2, as entidades abrangidas têm de demonstrar medidas de gestão de risco que incluem continuidade de atividade, gestão de cópias de segurança, recuperação em caso de desastre e segurança da cadeia de fornecimento — e um fornecedor de nuvem que concentra identidade, correio, ficheiros e segurança é, por definição, cadeia de fornecimento crítica. O CNCS e o CERT.PT são os pontos de contacto nacionais para notificação e apoio em incidentes de cibersegurança; ainda que uma avaria do fornecedor não seja um ataque, o exercício de decidir se o evento é reportável deve estar previsto no procedimento interno, e não improvisado no dia.
Há ainda a dimensão de proteção de dados. O RGPD não trata apenas de confidencialidade: a disponibilidade e a resiliência dos sistemas e serviços de tratamento fazem parte das medidas de segurança exigidas ao responsável pelo tratamento e ao subcontratante. Uma indisponibilidade prolongada que impeça o acesso a dados pessoais pode, em função da gravidade e da duração, constituir uma violação de dados pessoais com obrigações associadas perante a CNPD. Para cidadãos e microempresas a lição é mais simples: manter um endereço de correio alternativo e não depender de um único ecossistema para autenticar tudo o resto.
Perguntas frequentes
Este incidente do Microsoft 365 foi um ciberataque?
Não há qualquer indicação nesse sentido. A Microsoft atribuiu a avaria a uma configuração central de autenticação usada por vários serviços internos, um problema operacional interno. Os sintomas, contudo, assemelham-se aos de um incidente de segurança, o que reforça a importância de consultar o estado do serviço antes de iniciar remediações internas.
Que serviços foram afetados e durante quanto tempo?
Além do Exchange Online, a Microsoft confirmou impacto no Teams, Microsoft Graph, Purview, OneDrive for Business, SharePoint Online, centro de administração do Microsoft 365, Copilot, Universal Print e Defender XDR. O incidente foi reconhecido a 31 de agosto de 2026 e só a 2 de setembro a empresa indicou que a maioria dos utilizadores já não sentia impacto.
O que deve uma PME fazer durante uma paragem destas?
Confirmar o incidente no Service Health, comunicar internamente por um canal alternativo, registar horas e sintomas, evitar reposições massivas de credenciais e nunca desativar MFA ou acesso condicional como forma de contornar a indisponibilidade. Depois do incidente, revisitar o plano de continuidade e as cópias de segurança independentes.
Uma indisponibilidade da nuvem tem implicações legais em Portugal?
Pode ter. O Decreto-Lei n.º 125/2025 exige às entidades abrangidas medidas de continuidade, recuperação e segurança da cadeia de fornecimento. No plano da proteção de dados, a disponibilidade integra as medidas de segurança do RGPD e uma indisponibilidade grave e prolongada pode configurar uma violação de dados pessoais, com deveres de avaliação e eventual notificação à CNPD.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft nos seus registos de incidente e canais de estado de serviço, bem como em análises de empresas do setor e em documentação técnica oficial.