El vencimiento de credenciales es un problema operativo
Por qué un MSP con muchos tenants de Microsoft Entra necesita inventario, dueños, margen de tiempo y avisos por correo que se puedan accionar.
Un client secret o un certificado no vencen por sorpresa. Su fecha de vencimiento se conoce en el momento en que la credencial se crea. Y aun así, las credenciales vencidas de App Registrations de Microsoft Entra ID siguen causando caídas, porque conocer una fecha no es lo mismo que operarla.
El evento técnico es simple: a partir de un instante concreto, una aplicación deja de poder autenticarse con esa credencial. El sistema operativo que rodea al evento es más difícil. Alguien tiene que saber que la credencial existe, entender qué depende de ella, ser dueño de la renovación, empezar con tiempo suficiente y verificar que el reemplazo funciona.
Para un MSP que gestiona entre 20 y 60 tenants de Entra, esto no es un problema de calendario repetido unas cuantas veces. Es un problema distribuido de inventario y coordinación. Cada tenant suma aplicaciones, credenciales, dueños, restricciones de cambio y rutas de fallo independientes.
El inventario es el primer control
No se puede gestionar una fecha de vencimiento que no está en el inventario de trabajo.
Un inventario útil necesita algo más que el nombre visible de la credencial. Como mínimo, un operador necesita el tenant, la App Registration, el tipo de credencial, su identificador y la fecha de vencimiento. El inventario también debería hacer visibles los duplicados y las credenciales solapadas. Una lista con cinco entradas llamadas client-secret es técnicamente correcta y operativamente inútil.
Los límites entre tenants importan. El mismo nombre de aplicación puede aparecer en varios tenants gestionados, mientras que las credenciales de una sola integración pueden estar repartidas entre registros distintos. Una exportación plana, sin contexto estable de tenant y aplicación, crea otra tarea de reconciliación antes de siquiera poder empezar la renovación.
El inventario también tiene que estar al día. Una planilla generada durante el onboarding pierde confiabilidad cada vez que alguien crea, reemplaza o elimina una credencial. El problema no es que una planilla no pueda guardar fechas. Es que una copia mantenida a mano no tiene ninguna relación fiable con el sistema de origen.
La pregunta operativa, entonces, no es "¿tenemos una lista?". Es "¿puede el equipo usar esta lista para decir qué vence primero en todos los tenants que administra?".
La propiedad tiene que ser explícita
Un aviso sin dueño es apenas una difusión.
El owner que figura en la App Registration de Entra puede servir, pero no siempre identifica a quien es responsable de la integración en producción. La gente cambia de rol. Las aplicaciones gestionadas por terceros sobreviven a los proyectos de implementación. Las cuentas de automatización compartidas tapan al equipo que realmente entiende la dependencia.
La propiedad debería responder una pregunta práctica: quién puede coordinar la renovación desde que se detecta hasta que se verifica. En eso puede intervenir un operador del MSP, un responsable de la aplicación del lado del cliente y un proveedor. No hace falta que una sola persona ejecute cada paso, pero sí que una cola o un rol sea responsable de que el trabajo avance.
Esta distinción se vuelve importante a escala. Si un correo llega a diez personas y cada una asume que otro destinatario es el dueño, la notificación funcionó y la operación falló. El enrutamiento necesita un destino por defecto, una ruta de escalado y contexto suficiente para que quien recibe pueda asignar el trabajo sin abrir cada tenant primero.
Los datos de propiedad nunca van a ser perfectos. El sistema debería exponer la falta de dueño temprano, en vez de esconderla hasta que la credencial entra en una ventana crítica. "Dueño desconocido, vence en 60 días" es accionable. "Falló la autenticación" es tarde.
El margen es una propiedad del cambio
Los días que faltan no son los días disponibles.
Crear una credencial puede llevar minutos, pero el cambio completo puede requerir una ventana de mantenimiento, aprobación del cliente, coordinación con el proveedor, distribución del secret, despliegue y verificación posterior. Los certificados además pueden requerir generación y manipulación fuera de Entra. La ventana de aviso correcta depende de ese proceso, no de lo rápido que sea el clic en el portal.
Usá ventanas de vencimiento para convertir fechas en una cola de trabajo. Una función pequeña y pura alcanza para clasificar las fechas; la política decide qué significa cada ventana:
type ExpiryWindow = "expired" | "0-14 days" | "15-45 days" | "later";
function classifyExpiry(expiresAtMs: number, nowMs: number): ExpiryWindow {
const remainingMs = expiresAtMs - nowMs;
if (remainingMs <= 0) return "expired";
const days = Math.ceil(remainingMs / 86_400_000);
if (days <= 14) return "0-14 days";
if (days <= 45) return "15-45 days";
return "later";
}Los umbrales de arriba son un ejemplo, no una política universal. Una integración interna de bajo impacto puede necesitar menos tiempo. Una credencial atada a un sistema de producción de un cliente o a un proveedor externo puede necesitar bastante más.
Lo que importa es la consistencia. Si el equipo considera urgente algo a 14 días, esa regla debería aplicarse en todo el inventario gestionado. Los operadores no deberían tener que recordar qué tenant revisaron hace poco ni calcular la urgencia de forma distinta en cada sesión del portal.
El margen también tiene que contemplar que el aviso falle. Un único mensaje un día antes del vencimiento asume entrega inmediata, atención inmediata, propiedad clara y un primer cambio exitoso. Las operaciones rara vez ofrecen las cuatro cosas. Avisar antes deja lugar para recordatorios, reasignaciones y recuperarse de una renovación fallida.
Los avisos por correo necesitan contexto operativo
El correo sirve porque los equipos de un MSP ya hacen pasar el trabajo por bandejas compartidas, ingesta de tickets y reglas de escalado. También es fácil de hacer mal.
Un correo de vencimiento útil debería identificar el tenant, la aplicación, el tipo de credencial, la fecha de vencimiento y el tiempo restante. Debería quedar claro si el mensaje es un aviso temprano, un recordatorio o una alerta de credencial ya vencida. El asunto tiene que permitir escanear y enrutar sin abrir el cuerpo.
El aviso no debería incluir el valor de la credencial. El monitoreo de vencimientos necesita metadatos, no material secreto. Incluir valores sensibles aumentaría el riesgo de manipulación sin ayudar a quien recibe a agendar la renovación.
La frecuencia también cuenta. Mandar todas las credenciales próximas todos los días produce un resumen que los operadores aprenden a ignorar. Mandar una sola vez asume cosas demasiado optimistas sobre la entrega y la propiedad. Un patrón mejor es notificar en las transiciones que importan, repetir dentro de las ventanas más ajustadas, y cortar o reiniciar la secuencia cuando el inventario muestra un reemplazo.
Ese último paso evita los avisos obsoletos. La renovación suele crear una credencial nueva antes de que la vieja se elimine. La vista operativa tiene que distinguir la credencial que vence de su reemplazo, en vez de tratar la App Registration como un único estado indiferenciado.
El ciclo termina después de verificar
Crear la credencial de reemplazo no es haber terminado.
La aplicación que la consume tiene que recibir el nuevo valor o certificado, desplegarlo correctamente y autenticarse con éxito. La credencial vieja puede quedar un tiempo para poder revertir, pero no debería convertirse en ambigüedad permanente. El inventario tiene que terminar reflejando el reemplazo activo y la eliminación deliberada de la anterior.
Eso le da al equipo un ciclo concreto:
- Detectar los vencimientos próximos en todos los tenants gestionados.
- Asignar un dueño responsable.
- Arrancar el trabajo según el margen que el cambio requiere.
- Reemplazar y desplegar la credencial.
- Verificar la autenticación.
- Eliminar o cerrar la credencial vieja.
La fecha de vencimiento arranca el ciclo, pero son el inventario, la propiedad y el estado del proceso los que lo hacen operable. Sin esos controles, al equipo le quedan revisiones manuales en el portal y recordatorios de calendario que no comparten una fuente de verdad.
El vencimiento de credenciales, entonces, no es principalmente un problema de criptografía. Es mantenimiento predecible a través de fronteras administrativas. Un MSP necesita una vista entre tenants, responsabilidad clara, margen suficiente para el proceso de cambio real y avisos que entren a la cola con contexto útil.
CredWatch se está construyendo alrededor de ese problema acotado: monitorear el vencimiento de client secrets y certificados de App Registrations de Microsoft Entra ID en varios tenants, con un correo antes de que expiren. Preguntá por CredWatch mientras se construye.