Un checklist abierto, un alcance claro.
Esta es una fotografía de preparación, no una auditoría de seguridad. Combina observaciones de un endpoint público con respuestas declaradas. No certifica protección post-cuántica, ausencia de vulnerabilidades ni cumplimiento regulatorio.
Dos resultados diferentes
La señal técnica describe negociaciones del hostname público. La preparación declarada suma cinco dimensiones de tus respuestas: inventario, proveedores, responsable, capacidad de cambio y plan. Tener datos sensibles no baja el score; pagar tampoco lo sube.
| Dimensión | No sé / ausencia | Parcial | Completo declarado |
|---|---|---|---|
| Inventario | 0 | 10 | 20 |
| Proveedores | 0 | 5 | 20 |
| Responsable | 0 | 10 | 20 |
| Capacidad de cambio | 0 | 5 | 20 |
| Plan | 0 | 10 | 20 |
Sumamos sin ponderaciones ocultas. No excluimos desconocidos del denominador. “No sé” y “no existe” se conservan distintos: averiguar no es lo mismo que crear.
0–24: por organizar. 25–49: primeros pasos. 50–74: plan parcial. 75–100: base declarada avanzada. Los rangos son decisiones editoriales, no una escala validada por NIST.
Prioridad y límites
Datos, horizonte de confidencialidad y complejidad definen prioridades aparte. Los plazos de 7, 30, 90 y 180 días organizan tareas; no predicen un CRQC ni determinan cumplimiento legal. Una falla clásica de certificado se muestra primero y gratis.
Una negociación híbrida no acredita todos los tramos de una aplicación. Un error o timeout no demuestra ausencia de soporte PQ. TLS 1.0/1.1 y suites no ensayadas permanecen como no comprobadas.
Fuentes primarias
- NIST: estándares PQC
- Preparación: inventario y proveedores
- NIST: crypto-agility
- IETF: intercambio híbrido TLS
- Cloudflare: conexión al origen
- NCSC: preparación para PYMES
- IETF RFC 5280: certificados X.509 y validación PKIX
- IETF RFC 9525: identidad del servicio en TLS
Método 1.0.1 · Contenido 2026-09-09.2. Los reportes conservan su versión y fecha.