Nunca vi uma PME arrepender-se de ter ativado MFA. Já vi várias arrependerem-se de como o ativaram: o administrador que ligou tudo numa sexta-feira e passou a segunda a destrancar contas, o software de faturação que deixou de enviar emails porque ninguém sabia que autenticava com SMTP AUTH básico, o dono da empresa em viagem sem conseguir entrar — e, no caso que mais se repete, o projeto de MFA adiado meses «para não incomodar as pessoas», que é como quem diz: a porta ficou aberta enquanto se discutia o aviso de fecho.
O receio de bloquear a equipa é legítimo — mas resolve-se com faseamento, não com adiamento. Neste artigo reúno o plano que uso: escolher a abordagem certa para a licença que tem, inventariar o que pode partir antes de partir, criar as saídas de emergência, e expandir por vagas com os registos de início de sessão a dizer-lhe a verdade em cada passo. Os factos estão validados na documentação oficial (data no fim); as observações de terreno estão assinaladas como tal.
Em resumo: há três formas de exigir MFA no Microsoft 365 — predefinições de segurança (gratuitas, tudo-ou-nada), Acesso Condicional (recomendado, exige Entra ID P1, incluído no Business Premium) e o MFA por utilizador (legado, último recurso). Seja qual for a escolha, a sequência que evita bloqueios é a mesma: inventário, contas de emergência, comunicação, piloto, vagas, monitorização — e a saída dos métodos fracos já tem calendário marcado pela própria Microsoft. O erro caro não é técnico: é saltar passos.
As três abordagens — e como escolher
O Microsoft 365 tem três mecanismos para exigir MFA, e não são equivalentes:
- Predefinições de segurança (security defaults) — gratuitas, disponíveis em qualquer tenant. Obrigam ao registo de MFA de todos os utilizadores, exigem MFA aos administradores em cada sessão e aos restantes quando o risco o justifica, bloqueiam a autenticação legada e bloqueiam também o fluxo de código de dispositivo (device code flow) — este último não por ser legado, mas pelo risco de phishing que representa. O preço da simplicidade: são tudo-ou-nada — sem exclusões, sem faseamento por grupos, sem exceções para a aplicação antiga
- Acesso Condicional — o caminho recomendado quando há licença: exige Microsoft Entra ID P1, que vem incluído no Microsoft 365 Business Premium. Dá-lhe políticas por grupo, o modo só de relatório (report-only) para medir o impacto antes de impor, exclusões controladas e «forças de autenticação» — incluindo a exigência de métodos resistentes a phishing onde importa
- MFA por utilizador (per-user) — o mecanismo antigo, de estados Enabled/Enforced por conta. A documentação da Microsoft é direta: só o recomenda quando não há Acesso Condicional nem se querem as predefinições — e avisa explicitamente para não o misturar com Acesso Condicional, porque os estados não se sincronizam e o resultado é confusão (utilizadores que parecem «Disabled» mas estão protegidos por política, e vice-versa)
A leitura de terreno: para uma PME com Business Premium, a escolha está feita à partida — Acesso Condicional, sem hesitação, porque o faseamento deste artigo depende das ferramentas que só ele tem (report-only, grupos, exclusões temporárias). Para quem está no Business Basic ou Standard sem planos de subir, as predefinições de segurança são uma proteção honesta — mas o faseamento passa a ser social (comunicação e preparação), porque tecnicamente é um interruptor. E um aviso a quem herda tenants antigos: procure utilizadores com per-user MFA ativo antes de desenhar políticas novas — encontrá-los a meio do projeto é retrabalho garantido.
O inventário: descobrir o que pode partir antes de partir
É o passo que separa os projetos calmos dos fins de semana perdidos, e é sempre o mais apressado. Antes de impor seja o que for, responda com listas, não com impressões:
- Administradores — quantos são, e porquê? O projeto de MFA é a melhor desculpa para reduzir os Administradores Globais ao mínimo; menos contas privilegiadas, menos superfície e menos gente para bloquear
- Utilizadores e convidados — os convidados (B2B) são abrangidos quando estão no âmbito da política; em determinados cenários, o MFA feito no tenant de origem pode ser aceite, conforme as definições de acesso entre tenants e a relação de confiança de MFA. Verifique essas definições e inclua convidados e parceiros externos no piloto — é mais barato do que descobrir a resposta na primeira reunião com um parceiro depois da ativação
- Contas de serviço — a multifunções que digitaliza para email, o software de faturação que envia com SMTP AUTH básico, o script que lê uma caixa de correio. O Acesso Condicional aplica-se a utilizadores; estas contas «utilizador» que não têm humano atrás são o principal gerador de surpresas — identifique cada uma, o que autentica e como, e migre o que puder para alternativas modernas antes da ativação global
- Contas partilhadas — a «geral@» com a password escrita no post-it e usada por três pessoas é o teste decisivo do MFA: no dia em que a política chegar, o telemóvel de quem aprova? O projeto obriga a arrumar o que devia estar arrumado — converter em caixa partilhada sem início de sessão direto, ou atribuir um dono com conta própria. Nas empresas por onde passo, há sempre pelo menos uma; encontre-a antes que ela o encontre a si
- Autenticação legada — nos registos de início de sessão do Entra, filtre por aplicações cliente legadas e distinga tentativas bem-sucedidas de tentativas que já estão a ser recusadas. A autenticação básica para POP, IMAP e Exchange ActiveSync já está desativada no Exchange Online; o SMTP AUTH é a exceção transitória — mantém o comportamento atual até ao final de dezembro de 2026, altura em que passa a estar desativado por predefinição nos tenants existentes (os administradores ainda poderão reativá-lo temporariamente; a remoção definitiva será anunciada pela Microsoft durante o segundo semestre de 2027). Nota importante: o problema é a autenticação básica através de SMTP AUTH, não o protocolo SMTP em si — migre estes emissores para OAuth ou para uma alternativa moderna antes de se tornarem uma dependência urgente, porque as predefinições de segurança ou uma política de Acesso Condicional podem bloqueá-los antes destas datas
- Métodos já registados — quantos utilizadores já têm o Authenticator ou outro método? O relatório de registo diz-lhe quanta «vaga zero» já está feita e onde vai doer
- Dispositivos com introdução limitada — equipamentos e aplicações que iniciam sessão por fluxo de código de dispositivo (device code flow), como certos ecrãs de sala de reuniões ou aplicações em dispositivos sem teclado. As predefinições de segurança bloqueiam este fluxo (pelo risco de phishing, não por ser legado) — identifique-os antes da ativação, ou deixarão de iniciar sessão sem aviso
As contas de emergência primeiro — não como nota de rodapé
Antes de qualquer política que restrinja acesso, crie as saídas de emergência. A orientação atual da Microsoft, que sigo à letra porque já precisei dela uma vez e cumpriu a função:
- Duas contas, cloud-only (domínio .onmicrosoft.com), sem federação nem sincronização — para sobreviverem a falhas do que quer que esteja no meio
- Global Administrator permanente (atribuição ativa, não elegível) — numa emergência não se quer depender de fluxos de elevação
- Métodos resistentes a phishing — passkeys (FIDO2) ou certificados, e deliberadamente diferentes dos métodos dos administradores normais: se o Authenticator estiver em baixo ou comprometido, as chaves físicas continuam a funcionar. A recomendação já não é «excluir de MFA e proteger só com password comprida» — é MFA forte, doutro tipo
- Excluídas das políticas de Acesso Condicional que bloqueiam ou restringem (via grupo dedicado); as políticas em report-only não precisam de exclusão
- Credenciais guardadas fora do digital de todos os dias — em locais seguros separados, acessíveis a mais do que uma pessoa; nunca associadas ao telemóvel de alguém
- Alerta a cada início de sessão destas contas (gravidade máxima) — o uso legítimo é raríssimo, por isso qualquer uso merece um alerta e uma revisão posterior
- Teste trimestral — pelo menos a cada 90 dias, alguém entra com cada conta e confirma que funciona com as políticas atuais. Uma conta de emergência não testada é decoração
Uma distinção que importa entre as duas abordagens: as exclusões descritas acima aplicam-se apenas às políticas de Acesso Condicional. Com as predefinições de segurança não existem exclusões por utilizador — nem para contas de emergência. Nesse cenário, registe e teste as passkeys ou chaves FIDO2 destas contas antes da ativação, porque elas passarão pelos mesmos requisitos que toda a gente.
O nosso guia de segurança dos primeiros 30 dias trata estas contas no primeiro dia do plano — não é coincidência: tudo o que este artigo faz a seguir assenta na existência delas.
Comunicação e apoio: metade do projeto
A parte técnica do MFA raramente falha; a adoção é que decide se o projeto foi um sucesso ou uma guerra. Três peças que preparo sempre antes da primeira vaga:
O aviso prévio — curto, com data, e com o porquê. Um modelo que pode adaptar:
A partir de [data], entrar na conta da empresa passa a pedir uma confirmação no telemóvel — o mesmo tipo de proteção que o seu banco já usa. Antes disso, precisamos que instale a aplicação Microsoft Authenticator e registe o seu método: demora menos de cinco minutos, e o passo a passo segue em anexo. No dia [data de sessão], estamos disponíveis para ajudar quem preferir fazê-lo acompanhado.
Um pormenor que muda a taxa de adesão mais do que qualquer texto: quem assina. O mesmo aviso enviado «pela informática» gera adiamentos; enviado pela gerência, gera registos. Não é vaidade — é a diferença entre «coisa do IT» e «decisão da empresa», e vale a pena negociar essa assinatura antes da primeira vaga.
O registo antecipado — a pior experiência de MFA é registar o método no próprio dia, à pressa, com uma fila de trabalho atrás. Abra uma janela de registo de uma a duas semanas antes de impor, acompanhe o relatório de registo, e acompanhe individualmente os utilizadores que ainda não concluíram o registo — são sempre os mesmos, são poucos, e quem chega ao dia da imposição sem método registado é exatamente quem vai abrir o pedido de apoio às 9h02.
O guião do apoio — quem atende os pedidos precisa de três respostas prontas: «não recebo o pedido no telemóvel» (verificar conectividade da app, reenviar, método alternativo), «troquei de telemóvel» (o processo de re-registo, com verificação de identidade digna desse nome — a troca de telemóvel é o momento favorito dos atacantes para pedir «reset do MFA»), e «estou bloqueado e é urgente» (quem pode validar a identidade e como; nunca por aprovação cega). Escreva-o antes da primeira vaga, não depois do primeiro incidente.
Piloto e vagas: a expansão sem sustos
Com inventário, contas de emergência e comunicação prontos, a ativação é uma sequência controlada — quatro vagas, cada uma a validar a seguinte:
- Vaga 0 — administradores — começa por quem tem mais privilégio e mais tolerância técnica. Depois de testar as contas de emergência, aplique primeiro a política a um ou dois administradores-piloto; reveja os registos de início de sessão e o resultado em modo só de relatório, e só depois a imponha às restantes funções administrativas. A política geral dos utilizadores permanece em modo só de relatório nesta fase
- Vaga 1 — piloto — 5 a 10 pessoas que representem a empresa real: alguém da contabilidade, alguém que viaja, alguém pouco à vontade com o telemóvel — não a equipa de TI, que passa qualquer piloto. Uma a duas semanas, com os registos de início de sessão abertos e o guião de apoio à prova
- Vaga 2 — a maioria — com as lições do piloto incorporadas (há sempre duas ou três), expanda por departamentos. O modo report-only já lhe disse, entretanto, quem seria bloqueado e porquê — e a lista tem sempre os mesmos suspeitos: o tablet antigo da sala de reuniões, o email configurado à moda antiga no telemóvel pessoal de alguém da direção, a aplicação que ninguém sabia que existia. Resolva essas exceções antes de impor, não depois — cada uma resolvida em report-only é um telefonema irritado que não acontece
- Vaga 3 — os difíceis — as contas de serviço que ainda autenticam à moda antiga, os convidados, os casos especiais que foram ficando. Cada exceção que sobrar precisa de três coisas: justificação escrita, âmbito mínimo e data de revisão — uma exclusão permanente sem dono é um buraco com assinatura
Durante toda a expansão, os registos de início de sessão são o instrumento de voo: falhas de MFA por utilizador, aplicações a autenticar por protocolos legados, países improváveis. Quinze minutos por dia nas primeiras semanas poupam as conversas de corredor sobre «o MFA que anda a bloquear tudo» — normalmente anda a bloquear exatamente o que devia, e os registos deixam-no demonstrar isso com dados.
Fechar bem: recuperação, métodos fracos e estado final
O projeto não acaba quando a última vaga entra — acaba quando três coisas estão verdadeiras:
- A recuperação está validada — o processo de «perdi o telemóvel» foi testado com uma pessoa real, o guião de apoio resiste a um atacante razoável, e as contas de emergência passaram o teste trimestral com as políticas finais ativas
- Os métodos baseados em SMS e chamadas têm agora um prazo de saída — desde 1 de setembro de 2026, os utilizadores com estes métodos ativos começaram a ser encaminhados para o registo de passkeys, e a entrega nativa de SMS e chamadas pela Microsoft termina em 1 de fevereiro de 2027. Identifique já quem depende deles e migre-os, por vagas, para passkeys, Windows Hello for Business ou chaves FIDO2; o Microsoft Authenticator continua a ser uma alternativa útil, mas as notificações push e os códigos TOTP não são resistentes a phishing — para administradores, pondere exigir desde já métodos resistentes a phishing via força de autenticação. E não deixe a migração para a véspera: em todas as empresas há alguém que só tem SMS — um telemóvel sem espaço para mais uma aplicação, ou sem paciência para ela — e essa pessoa merece uma conversa e ajuda no registo, não um bloqueio surpresa em fevereiro
- O estado final está documentado — que políticas existem e porquê, que exceções sobraram com que justificação e que data de revisão, onde estão as credenciais de emergência e quem sabe usá-las. O documento de uma página que responde a isto vale ouro na próxima auditoria, no próximo técnico novo, e no próximo incidente — a checklist de segurança serve de verificação periódica a partir daqui
Se está a montar o ambiente de raiz, o guia de implementação do Microsoft 365 posiciona este trabalho no sítio certo da sequência — o MFA entra muito antes dos dados e dos utilizadores todos, precisamente para nunca ter de ser «o projeto assustador» que ficou para depois.
E antes de carregar no botão para todos: percorra o inventário da segunda secção como checklist. Se não sobrar nenhuma dependência por validar — contas de serviço, autenticação legada, processos automatizados — ative com confiança; o faseamento fará o resto. Se sobrar alguma difícil de validar sozinho, é aí que vale a pena pedir apoio: uma tarde de análise das exceções certas custa menos do que uma segunda-feira de contas bloqueadas.
Fontes e validação
Este artigo baseia-se na documentação oficial da Microsoft, em particular:
- Security defaults no Microsoft Entra ID
- Acesso Condicional: exigir MFA para todos os utilizadores (authentication strengths)
- Manage emergency access accounts (contas de acesso de emergência)
- Per-user MFA (estados por utilizador e recomendação de migração)
- Retirada de SMS e voz no Microsoft Entra ID (transição para passkeys)
- Depreciação da autenticação básica no Exchange Online
- Cronologia atualizada da depreciação do SMTP AUTH (Exchange Team)
