Desplegar un método resistente al phishing por fases

Un despliegue de métodos resistentes al phishing se hace por olas porque cada una enseña algo: la primera (un piloto de TI) descubre qué se rompe, y las siguientes lo repiten con más gente y menos sorpresas. El orden lo decide el daño posible: primero quien puede hacer más si le roban la sesión (administración, tesorería), después quien maneja datos sensibles, y al final el resto.

Abre la carpeta despliegue y lee plan.txt. La ola 4, al final, retira el SMS y la voz: se hace al cierre y no al principio, porque quitarlos antes deja sin acceso a quien todavía depende de ellos.

La cobertura es la proporción de personas de cada grupo que ya tiene un método resistente al phishing registrado. Es el indicador del despliegue: no cuántas llaves se compraron, sino cuántas personas pueden entrar con ellas. Se mide en una fecha y sobre un grupo concreto.

En cobertura-2026-10-02.txt están los números. La ola 1 cubre administración y tesorería. Calcula cuántas personas de esos dos grupos todavía no tienen método resistente.

Un plan sin fechas es una intención. La ola 1 tenía fecha límite y el corte es del 2 de octubre de 2026. Mide cuántos días calendario han pasado desde la fecha límite hasta el corte.

Habrá personas que no puedan pasar a tiempo: la llave se reemplaza, alguien viaja. Para eso existen las excepciones, con un motivo y una fecha de vencimiento. Una excepción sin vencimiento termina siendo la regla; una vencida que sigue «activa» es una cuenta fuera de la política sin que nadie lo haya decidido.

Lee excepciones.txt. Busca la que venció antes del corte del 2 de octubre y todavía figura como activa.

El informe de la revisión no debe limitarse a señalar el retraso: propone qué hacer. Con una excepción vencida y una ola retrasada, lo razonable es pedir al dueño de la excepción que la cierre o la renueve con motivo y nueva fecha, y reprogramar la ola con las llaves que faltan, no esconder el número.