Si alguien en tu empresa (o tu proveedor de TI) programó tareas que entran solas a Microsoft 365 para dar de alta buzones, sacar reportes o ajustar permisos, es probable que lo haga con un usuario y una contraseña guardados en el servidor. Esa forma de conexión tiene fecha de salida.
Microsoft publicó el aviso MC1248389 el 10 de marzo de 2026 y lo actualizó el 15 de julio: las versiones del módulo de PowerShell de Exchange Online (ExchangeOnlineManagement) que salgan a partir de diciembre de 2026 ya no incluirán el parámetro -Credential en Connect-ExchangeOnline (correo) ni en Connect-IPPSSession (cumplimiento y seguridad). La fecha original era julio; Microsoft la recorrió a fin de año.
| Qué | Cuándo | Efecto |
|---|---|---|
Módulo con -Credential (3.10.1 y anteriores) | Hoy | Sigue funcionando |
| Primera versión del módulo de diciembre de 2026 | Diciembre de 2026 | El parámetro desaparece; el script falla al conectar |
| Retiro del lado del servidor | Fecha por anunciar | -Credential deja de funcionar con cualquier versión |
Fuentes: aviso MC1248389 (versión del 15 de julio de 2026, consultada en el espejo público mc.merill.net) y notas de versión del módulo en Microsoft Learn, consultadas el 19 de octubre de 2026.
Por qué Microsoft lo quita
-Credential usa un flujo de inicio de sesión llamado ROPC: el script entrega usuario y contraseña directamente, sin pantalla de Microsoft de por medio. Ese flujo no puede pedir MFA. Por eso, para que esos scripts funcionen, muchas empresas dejaron una cuenta de administrador excluida de la MFA y del acceso condicional, con la contraseña escrita en un archivo o en el propio script.
Es justo la cuenta que buscan los atacantes: permisos altos, nadie la usa a mano y su contraseña casi nunca cambia. El aviso de Microsoft lo dice de forma directa: al retirar este flujo, el acceso condicional y la MFA pueden aplicarse a todas las conexiones de PowerShell de Exchange Online.
Update-Module instala la versión más reciente. En cuanto esa versión sea de diciembre o posterior, el script que ayer funcionaba amanece con error; nadie lo nota hasta que falta un reporte o no se crea el buzón de un empleado nuevo.Qué tareas suelen romperse en una PyME
- Altas y bajas de personal: scripts que crean el buzón, lo agregan a listas de distribución o lo convierten en buzón compartido cuando alguien se va.
- Reportes programados: tamaño de buzones, reenvíos a cuentas externas, licencias asignadas.
- Permisos y calendarios: dar acceso a un buzón de ventas o de facturación, cambiar permisos de calendario de salas.
- Herramientas de terceros: algunos programas de firmas, archivado o respaldo se conectan con una cuenta y contraseña que tú les diste. Pregunta al fabricante qué método usan.
Qué hacer antes de diciembre
- Busca los scripts. En cada servidor o equipo donde corran tareas programadas, busca archivos
.ps1que contenganConnect-ExchangeOnlineoConnect-IPPSSessionjunto con-Credential. UnGet-ChildItem -Recurse -Filter *.ps1 | Select-String "Credential"en las carpetas de scripts da una primera lista. Revisa también el Programador de tareas. - Identifica las cuentas. Anota qué usuario usa cada script, qué rol tiene y si está excluido de la MFA o del acceso condicional. Si la contraseña está en texto plano, considérala expuesta: cámbiala hoy y guárdala en un gestor de contraseñas empresarial mientras migras.
- Pasa cada script a autenticación con certificado. El procedimiento oficial de Microsoft Learn es:
- Registrar una aplicación en Microsoft Entra ID (de un solo inquilino).
- Darle el permiso de aplicación Exchange.ManageAsApp (Office 365 Exchange Online para correo; Microsoft Exchange Online Protection para cumplimiento) y otorgar el consentimiento de administrador.
- Crear un certificado (puede ser autofirmado; Microsoft aclara que debe ser de proveedor CSP, no CNG) y subir la parte pública a la aplicación.
- Asignarle el rol más limitado que alcance: para altas de buzones basta Exchange Recipient Administrator; Global Reader sirve para reportes. Evita Administrador global.
- Cambiar la línea de conexión a
Connect-ExchangeOnline -CertificateThumbPrint ... -AppID ... -Organization tuempresa.onmicrosoft.com.
- Si el script corre en Azure Automation, usa identidad administrada: no hay contraseña ni certificado que custodiar.
- Para el trabajo manual de los administradores, inicio de sesión interactivo con MFA. Nadie debería escribir su contraseña en un script "para no estar tecleando".
- Cierra las excepciones. Cuando el último script esté migrado, deshabilita la cuenta de servicio o quítale el rol, y elimina su exclusión de las políticas de MFA y acceso condicional.
- Mientras tanto, fija la versión. Si no alcanzas a migrar todo, instala explícitamente la 3.10.1 (
Install-Module ExchangeOnlineManagement -RequiredVersion 3.10.1) en los servidores de tareas y quita cualquier actualización automática del módulo. Es un parche temporal: el retiro del lado del servidor no depende de tu versión.
.pfx con su clave privada puede actuar como la aplicación. Guárdalo en el almacén de certificados del usuario que ejecuta la tarea, no en una carpeta compartida, ponle vigencia (un año es razonable) y agenda su renovación antes de que venza.Contexto: Microsoft cierra las puertas con contraseña una por una
Este cambio se suma a una serie de fechas que caen en el mismo trimestre: el apagado por defecto de SMTP AUTH básico a fin de diciembre, el cambio en los métodos de SMS y voz de Entra y el ajuste en el restablecimiento de contraseñas por autoservicio. La dirección es la misma: ningún acceso a Microsoft 365 sin un factor que no sea solo la contraseña.
Y las cuentas técnicas se olvidan: este mismo mes vimos inquilinos de Microsoft 365 comprometidos a través de un proveedor de respaldos, por una conexión automática con permisos amplios.
En ciberseguridad y cloud hacemos ese inventario de scripts y cuentas de servicio, migramos las conexiones a certificado con el mínimo permiso y documentamos quién renueva cada certificado.
