Exchange Online PowerShell vai remover o parâmetro -Credential: veja como isso impacta seus scripts

A Microsoft confirmou uma mudança importante para quem administra o Exchange Online por PowerShell: o parâmetro -Credential será removido das novas versões do módulo Exchange Online PowerShell lançadas a partir de julho de 2026.

À primeira vista, pode parecer apenas mais uma alteração técnica. Mas, na prática, isso impacta diretamente administradores, scripts legados e rotinas de automação que ainda dependem de autenticação baseada em usuário e senha.

O ponto principal é simples: quem ainda utiliza -Credential precisa começar a revisar seus scripts desde já.

O que a Microsoft está descontinuando

A remoção do parâmetro -Credential afetará os cmdlets:

Connect-ExchangeOnline

Connect-IppsSession

Segundo a Microsoft, essa mudança acontece como parte do fortalecimento da segurança no Exchange Online e da transição definitiva para métodos de autenticação modernos, compatíveis com MFA e Acesso Condicional.

O parâmetro -Credential depende do fluxo ROPC, conhecido como Resource Owner Password Credentials. Esse modelo é considerado legado e não atende aos requisitos atuais de segurança da Microsoft, principalmente porque não oferece suporte adequado para autenticação multifator.

Além disso, a própria biblioteca MSAL, utilizada nos fluxos modernos de autenticação da Microsoft, já descontinuou o suporte ao ROPC a partir da versão 4.74.0.

O que isso significa na prática

Na prática, seus scripts não vão parar de funcionar imediatamente hoje. A própria Microsoft informou que o parâmetro continuará funcionando nas versões do módulo lançadas até o final de junho de 2026.

O problema começa quando a organização atualizar para uma versão do módulo Exchange Online PowerShell lançada a partir de julho de 2026. Nessas versões, o suporte ao -Credential não existirá mais.

Ou seja, existe um detalhe importante aqui: essa mudança, inicialmente, acontece do lado do cliente.

Isso significa que se você continuar usando uma versão antiga do módulo, o script ainda pode funcionar por algum tempo.

Se você atualizar o módulo após julho de 2026, o script que depende de -Credential deixará de funcionar.

A Microsoft também informou que existe um encerramento futuro planejado no lado do servidor para esse fluxo de autenticação. Quando isso acontecer, até mesmo versões antigas do módulo poderão deixar de funcionar. Esse cronograma ainda será comunicado separadamente.

Por que essa mudança merece atenção agora

Muita gente pode olhar para julho de 2026 e pensar que ainda está longe. Só que esse tipo de mudança costuma gerar impacto justamente porque muitos ambientes ainda carregam scripts antigos em produção, muitas vezes sem documentação, sem revisão periódica e sem dono claro.

É comum encontrar cenários como:

1. Scripts agendados em servidores locais
   

2. Rotinas de compliance usando Connect-IppsSession
   

3. Automação de relatórios baseada em conta administrativa com senha salva
   

4. Tarefas operacionais criadas há anos e que continuam funcionando “porque ninguém mexeu”
   

O risco não está apenas na remoção do parâmetro. O risco está em descobrir tarde demais que uma rotina crítica do ambiente dependia de um método legado de autenticação.

Quais cenários são afetados

O impacto é direto para:

1. Administradores do Microsoft 365 que se conectam ao Exchange Online ou ao PowerShell de Segurança e Conformidade

2. Organizações com scripts de automação que usam -Credential

3. Equipes que ainda utilizam autenticação baseada em usuário e senha em rotinas não interativas
   

Se a sua organização não usa esse parâmetro, não há ação imediata necessária. Mas, sendo bem realista, vale revisar o ambiente antes de assumir que está tudo certo.

Quais são as alternativas recomendadas

A Microsoft já deixou claro quais caminhos devem ser adotados, de acordo com cada cenário.

1. Acesso administrativo interativo

Para administradores que executam comandos manualmente, a recomendação é usar autenticação moderna com MFA.

Esse é o caminho mais adequado para conexões humanas, principalmente em ambientes com políticas de Acesso Condicional e exigência de autenticação multifator.

2. Automação executada fora do Azure

Para scripts não interativos executados fora de serviços do Azure, a recomendação é usar autenticação somente por aplicativo.

Nesse modelo, a autenticação pode ser feita com certificado ou segredo de aplicativo, evitando o uso de credenciais de usuário.

Esse cenário faz bastante sentido para:

1. Servidores on premises

2. Agendadores de tarefas

3. Ferramentas de automação externas

4. Scripts rodando em infraestrutura própria

3. Automação executada dentro do Azure

Se a automação roda em serviços nativos do Azure, como Azure Automation ou Functions, a recomendação é usar identidade gerenciada.

Esse é provavelmente o modelo mais elegante do ponto de vista de segurança, porque elimina a necessidade de armazenar segredo ou senha.

O ganho real de segurança

Essa mudança não é apenas uma troca de parâmetro. Ela reforça uma direção muito clara da Microsoft: reduzir ao máximo a dependência de autenticação legada e ampliar o uso de mecanismos compatíveis com MFA, Acesso Condicional e princípios modernos de Zero Trust.

Do ponto de vista de conformidade, isso é relevante porque a remoção do -Credential também reduz o uso de fluxos que contornavam controles modernos de segurança.

Em outras palavras, não é só uma alteração técnica no PowerShell. É uma mudança de postura na forma como o acesso administrativo e a automação devem acontecer no Microsoft 365.

O que eu recomendo fazer desde já

Se você administra Exchange Online, o melhor caminho é tratar esse tema como uma revisão preventiva. Não vale esperar chegar perto do prazo para então descobrir quais scripts dependem de -Credential.

Um plano simples e eficiente pode começar assim:

1. Mapear scripts que usam Connect-ExchangeOnline e Connect-IppsSession

2. Identificar quais deles utilizam o parâmetro -Credential

3. Separar o que é uso humano do que é automação

4. Definir o novo método de autenticação adequado para cada caso

5. Testar a migração antes de atualizar o módulo em produção

6. Atualizar a documentação interna e orientar a equipe responsável
   

Esse é o tipo de ajuste que parece pequeno, mas que pode evitar incidentes, falhas em rotinas críticas e correria desnecessária no futuro.

Conclusão

A descontinuação do parâmetro -Credential no Exchange Online PowerShell é mais uma evidência de que a Microsoft está apertando o cerco contra métodos legados de autenticação.

Embora o prazo oficial esteja ligado às versões do módulo lançadas a partir de julho de 2026, a recomendação mais segura é não tratar isso como um problema futuro.

Se a sua operação ainda depende desse parâmetro, o melhor momento para revisar seus scripts é agora.

Quem se antecipar terá uma transição muito mais tranquila. Quem deixar para depois corre o risco de descobrir a dependência apenas quando uma automação parar de funcionar.