La mayoría de instituciones financieras peruanas que nos contactan sobre PKI llegan después de comprar un software de Autoridad Certificadora (CA) o un HSM. Lo encendieron, generaron algunos certificados, y la conversación arranca con una variante de:
“Tenemos la PKI funcionando, pero el auditor pide documentación que no tenemos.”
El malentendido es entendible: el software de PKI se vende como “la PKI.” Pero una PKI funcionando en producción es un ecosistema, no un servidor. Este artículo explica qué compone ese ecosistema, cuándo tiene sentido construirlo, y cuándo es desperdicio de presupuesto.
Qué hay realmente dentro de una PKI
Cuando hablamos de una PKI completa, hay nueve piezas que tienen que existir simultáneamente:
- Jerarquía de CAs — una raíz offline (apagada salvo ceremonias), una o varias emisoras online, y una decisión consciente sobre subordinadas intermedias.
- Política de Certificado (CP) — el documento que define qué se está prometiendo a quien confía en tus certificados.
- Declaración de Prácticas de Certificación (CPS) — cómo se cumple esa política en la práctica diaria.
- Perfiles de certificado — por caso de uso (TLS interno, firma de documentos, EMV, 3DS, código). Cada uno con tiempo de vida, extensiones, key usage diferentes.
- Ceremonias — instalación de raíz, activación de subordinadas, renovación, retiro. Cada una escrita, con guion, ejecutada bajo control dual, con actas firmadas.
- Estrategia de revocación — CRL, OCSP, OCSP stapling. Con SLOs explícitos: cuánto tiempo entre que se revoca un cert y la red se entera.
- Monitoreo — qué se mide (próximas expiraciones, CAs disponibles, OCSP responder up), qué dispara una alerta, quién la atiende.
- Modelo de gobernanza — quién aprueba un nuevo perfil de certificado, quién custodia las llaves, qué pasa cuando rota personal.
- Estrategia de agilidad criptográfica — qué hace cuando un algoritmo se deprecia (SHA-1, RSA-2048 eventualmente), qué hace frente al horizonte post-cuántico.
Ninguna de estas piezas se compra con el software de CA. Las nueve son trabajo de diseño, escritura y procedimiento.
Tres señales de que sí necesitas una PKI
No toda institución necesita una PKI propia. Antes de embarcarse en construir una, vale verificar si aplica alguna de estas tres situaciones:
1. El regulador o el auditor lo está pidiendo
En el Perú, la SBS y, dependiendo del sector, otros entes regulatorios exigen mecanismos de autenticidad e integridad documentados. Si tienes un hallazgo abierto sobre firma de documentos, mensajería segura entre sistemas internos, o autenticación de servicios, una PKI es típicamente la respuesta correcta.
2. Tu negocio depende de un caso de uso que la requiere
Los casos de uso que casi siempre justifican una PKI propia:
- Emisión de tarjetas con EMV — necesitas Issuer CAs alineadas con los esquemas (Visa, MasterCard).
- 3D Secure como emisor o adquirente — la sesión 3DS depende de certificados específicos.
- Firma digital con validez legal — para procesos internos o frente a clientes.
- Mensajería segura entre sistemas internos — TLS mutuo (mTLS) entre microservicios o entre tu core y satélites.
3. Tienes una PKI heredada que perdió a su dueño
Esta es la situación más común y la más peligrosa. Una PKI sin gobernanza viva acumula riesgo silencioso:
- Certificados que se renuevan “como siempre” sin que nadie pueda explicar por qué.
- Ceremonias no documentadas que dependen de la memoria de una persona.
- Procedimientos de revocación que nadie ha probado en años.
- Un día el regulador pregunta y la organización entra en pánico.
Reconstruir gobernanza sobre una PKI existente es trabajo, pero es trabajo finito. Posponerlo solo lo hace más caro.
Tres señales de que NO necesitas una PKI propia
A veces la respuesta es no construir una PKI propia:
- Volumen y casos de uso bajos. Si solo necesitas TLS para tu sitio público, Let’s Encrypt resuelve. No montas una CA para eso.
- No tienes voluntad de gobernar. Una PKI sin gobernanza es peor que no tenerla. Si la institución no se compromete a CPS, ceremonias y monitoreo, mejor consume servicios PKI gestionados.
- No hay un caso de uso con dueño claro. “Tener una PKI por si acaso” no es un caso de uso. Es un proyecto que se desinfla.
La pregunta correcta antes de empezar
Antes de pedir presupuesto para una PKI, la pregunta no es “qué software de CA usamos” ni “qué HSM compramos.” La pregunta es:
¿Cuáles son los casos de uso concretos que justifican esta PKI, quién es el dueño de cada uno, y qué pasa con cada uno si la PKI falla?
Si la respuesta es clara, el software y el HSM son consecuencia. Si la respuesta es vaga, ningún software va a arreglar eso.
En 2PSECURE diseñamos PKI completas — el ecosistema, no solo la plataforma — para instituciones financieras que necesitan pasar auditorías y mantener la operación después. Si tu organización está en una de las tres situaciones de arriba, conversemos sobre tu caso.
¿Te resultó útil? Compártelo: