{"id":14800,"date":"2026-08-05T01:50:29","date_gmt":"2026-08-05T08:50:29","guid":{"rendered":"https:\/\/omnitrust.com\/blog\/pki-maturity-model-2-0-0-que-cambio-en-la-vista-previa\/"},"modified":"2026-09-21T01:53:20","modified_gmt":"2026-09-21T08:53:20","slug":"pki-maturity-model-2-0-0-que-cambio-en-la-vista-previa","status":"publish","type":"post","link":"https:\/\/omnitrust.com\/es\/blog\/pki-maturity-model-2-0-0-que-cambio-en-la-vista-previa\/","title":{"rendered":"PKI Maturity Model 2.0.0: Qu\u00e9 cambi\u00f3 en la vista previa"},"content":{"rendered":" \n

Resumen:<\/strong> PKI Maturity Model 2.0.0 est\u00e1 en vista previa p\u00fablica, y su principal cambio es una nueva categor\u00eda de Criptograf\u00eda en el m\u00f3dulo de Gobernanza. Las decisiones criptogr\u00e1ficas que estaban dispersas entre la gesti\u00f3n de certificados y de claves ahora tienen un \u00fanico lugar coherente.<\/p> \n\r\n

\u00a0<\/div>\r\n\r\n
\n

Pedir a un proceso de gesti\u00f3n de certificados que gobernara conjuntos de cifrado siempre fue un error de categorizaci\u00f3n. 2.0.0 corrige la taxonom\u00eda en lugar de ampliarla.<\/p> \n<\/div>\r\n\r\n

\u00a0<\/div>\r\n \n

El PKI Maturity Model<\/a> es desarrollado por un grupo de trabajo del PKI Consortium. La versi\u00f3n 1.0.0 formaliz\u00f3 cinco niveles de madurez en cuatro m\u00f3dulos y quince categor\u00edas. Desde entonces, los evaluadores lo han utilizado en programas reales, y las dificultades que comunicaron han dado forma a esta revisi\u00f3n.<\/p> \n \n

La versi\u00f3n 2.0.0 ya est\u00e1 disponible como vista previa p\u00fablica. Este art\u00edculo repasa qu\u00e9 cambi\u00f3 y qu\u00e9 significa si ya ha completado una evaluaci\u00f3n.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

La nueva categor\u00eda de Criptograf\u00eda<\/h2> \n \n

Gobernanza incorpora una categor\u00eda: Criptograf\u00eda. Centraliza la gobernanza de algoritmos y par\u00e1metros criptogr\u00e1ficos, protocolos y versiones, visibilidad de activos criptogr\u00e1ficos, y ciclo de vida, retirada y agilidad criptogr\u00e1fica.<\/p> \n \n

Anteriormente, esas cuestiones se encontraban dentro de Gesti\u00f3n de claves y Gesti\u00f3n de certificados como requisitos de conjuntos de cifrado. Esa ubicaci\u00f3n generaba solapamientos y terminolog\u00eda ambigua. Como consecuencia, dos evaluadores pod\u00edan discrepar razonablemente sobre d\u00f3nde correspond\u00eda un hallazgo.<\/p> \n \n

La nueva categor\u00eda contiene seis requisitos.<\/p> \n \n

\n \n \n \n \n \n \n \n \n \n \n
Requisito<\/th> \nQu\u00e9 eval\u00faa un evaluador<\/th> \n<\/tr> \n<\/thead> \n
Terminolog\u00eda y alcance<\/td> \nSi la terminolog\u00eda criptogr\u00e1fica y el alcance aplicables a la PKI est\u00e1n definidos y documentados<\/td> \n<\/tr> \n
Algoritmos y par\u00e1metros<\/td> \nSi los algoritmos y par\u00e1metros en uso est\u00e1n documentados y formalmente aprobados<\/td> \n<\/tr> \n
Protocolos y versiones<\/td> \nSi los protocolos y las versiones de protocolo en uso est\u00e1n documentados y aprobados<\/td> \n<\/tr> \n
Visibilidad del uso<\/td> \nSi se ha establecido y se mantiene visibilidad sobre el uso criptogr\u00e1fico real<\/td> \n<\/tr> \n
Ciclo de vida y retirada<\/td> \nSi est\u00e1n definidas las reglas de ciclo de vida y retirada criptogr\u00e1fica<\/td> \n<\/tr> \n
Agilidad criptogr\u00e1fica<\/td> \nSi la agilidad est\u00e1 definida y gobernada: la capacidad de sustituir algoritmos o par\u00e1metros de forma controlada<\/td> \n<\/tr> \n<\/tbody> \n<\/table> \n
Los seis requisitos de la nueva categor\u00eda de Criptograf\u00eda, m\u00f3dulo de Gobernanza.<\/figcaption> \n<\/figure> \n \n

Lea esa lista junto a cualquier plan de migraci\u00f3n poscu\u00e1ntica. Cuatro de los seis son requisitos previos para uno, y la mayor\u00eda de las organizaciones descubren que no pueden aportar evidencias de ellos.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Se eliminaron dos requisitos<\/h2> \n \n

La consolidaci\u00f3n funciona en ambos sentidos. Gesti\u00f3n de certificados pierde \u00abLos conjuntos de cifrado de certificados est\u00e1n documentados\u00bb, y Gesti\u00f3n de claves pierde \u00abLos conjuntos de cifrado y protocolos criptogr\u00e1ficos est\u00e1n documentados y se mantienen\u00bb.<\/p> \n \n

Conviene explicar el razonamiento con claridad. Los conjuntos de cifrado son un concepto a nivel de protocolo, asociado principalmente con TLS y protocolos similares. Los certificados no los definen ni los negocian. Por tanto, mantener ese requisito en Gesti\u00f3n de certificados mezclaba la gobernanza criptogr\u00e1fica con la gesti\u00f3n del ciclo de vida de certificados.<\/p> \n \n

Gesti\u00f3n de claves ten\u00eda el mismo problema desde la otra direcci\u00f3n. La aprobaci\u00f3n de algoritmos y protocolos es una cuesti\u00f3n de gobernanza, no del ciclo de vida de las claves. As\u00ed, Gesti\u00f3n de claves se centra ahora exclusivamente en el ciclo de vida de las claves y Gesti\u00f3n de certificados en el ciclo de vida de los certificados.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Cambios que afectan a sus informes existentes<\/h2> \n \n

Varios cambios son estructurales y no sustantivos. Aun as\u00ed, afectan a cualquier cosa que haya automatizado o guardado como marcador.<\/p> \n \n

El nivel de madurez 2 cambia de nombre de \u00abB\u00e1sico\u00bb a \u00abFundacional\u00bb. El n\u00famero de nivel y la descripci\u00f3n de lo que significa alcanzarlo no cambian, por lo que el cambio de nombre busca transmitir mejor la intenci\u00f3n. Los informes existentes de 1.0.0 siguen siendo v\u00e1lidos. Sin embargo, si vuelve a emitir uno, actualice la etiqueta.<\/p> \n \n

Los identificadores estables sustituyen a los n\u00fameros basados en posici\u00f3n. Antes, las categor\u00edas y requisitos se referenciaban como G.1<\/code> y G.1.1<\/code>; ahora son G.strategy-and-vision<\/code> y G.strategy-and-vision.sponsor-support<\/code>. Como los identificadores son estables, sobreviven a futuras versiones menores. Cualquier cosa que haya creado sobre los n\u00fameros necesitar\u00e1 una actualizaci\u00f3n \u00fanica.<\/p> \n \n

Las URL de las p\u00e1ginas de categor\u00edas tambi\u00e9n eliminaron sus prefijos num\u00e9ricos, por lo que los marcadores que apunten a rutas con estilo 01-\u2026<\/code> deber\u00edan pasar al formato que contiene solo el identificador. Adem\u00e1s, un cat\u00e1logo compartido de referencias contiene ahora las normas, regulaciones y publicaciones citadas por el modelo, lo que permite mantener centralmente los t\u00edtulos y enlaces entre versiones mayores.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Las herramientas se movieron y una fue retirada<\/h2> \n \n

Las herramientas de evaluaci\u00f3n basadas en Excel se retiran a partir de 2.0.0 y son sustituidas por la autoevaluaci\u00f3n web. Siguen accesibles en las URL etiquetadas como 1.0.0 y en la secci\u00f3n 1.0.0 del sitio web. Pero si automatiz\u00f3 contra una ruta fijada a la rama principal, ese enlace dejar\u00e1 de resolverse.<\/p> \n \n

Los scripts de conversi\u00f3n CSV de Eramba se trasladaron a un repositorio de integraciones independiente. Del mismo modo, las extensiones publicadas ahora viven en su propio cat\u00e1logo en lugar de distribuirse con el modelo central.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Si evalu\u00f3 con 1.0.0<\/h2> \n \n

El impacto pr\u00e1ctico es menor de lo que sugiere un salto de versi\u00f3n mayor.<\/p> \n \n

Las categor\u00edas heredadas de 1.0.0 no tienen cambios de contenido m\u00e1s all\u00e1 de la eliminaci\u00f3n de los dos requisitos de conjuntos de cifrado. Por tanto, puede ser necesario reevaluar ligeramente las puntuaciones cuando ese requisito eliminado influyera de forma material en un nivel. Para la mayor\u00eda de las evaluaciones, el efecto es menor y se limita a un \u00fanico requisito.<\/p> \n \n

El trabajo real es aditivo. Las organizaciones que completaron una evaluaci\u00f3n con 1.0.0 deber\u00edan a\u00f1adir la categor\u00eda de Criptograf\u00eda en su siguiente ciclo. Ese es el \u00fanico lugar donde 2.0.0 plantea preguntas realmente nuevas.<\/p> \n\r\n

\u00a0<\/div>\r\n \n

Por qu\u00e9 esto importa m\u00e1s all\u00e1 del modelo<\/h2> \n \n

OmniTrust participa en el grupo de trabajo de PKI Maturity Model, y creemos que esta revisi\u00f3n representa el tipo correcto de cambio. No persigue temas nuevos. En su lugar, corrige una taxonom\u00eda que hab\u00eda archivado la gobernanza criptogr\u00e1fica bajo gesti\u00f3n del ciclo de vida.<\/p> \n \n

Esa correcci\u00f3n importa porque se est\u00e1 pidiendo al sector, todo al mismo tiempo, que inventar\u00ede su criptograf\u00eda, acorte la vigencia de los certificados y planifique una migraci\u00f3n poscu\u00e1ntica. Nada de eso es posible sin saber qu\u00e9 algoritmos utiliza y qui\u00e9n los aprob\u00f3. Un modelo de madurez que dispersa esas preguntas entre tres categor\u00edas no puede medir si usted lo sabe.<\/p> \n \n

El modelo se desarrolla de forma abierta y el grupo de trabajo agradece las aportaciones. Si se dedica profesionalmente a evaluar programas de PKI, la vista previa es el momento en que resulta m\u00e1s barato actuar sobre sus objeciones.<\/p> \n\r\n

\u00a0<\/div>\r\n
\r\n
\u00a0<\/div>\r\n\r\n
\n

Puntos clave<\/h3> \n\r\n\r\n \n