Most financial institutions in Peru that reach out to us about PKI arrive after they’ve already bought CA software or an HSM. They turned it on, generated a few certificates, and the conversation opens with some variant of:
“We have the PKI running, but the auditor is asking for documentation we don’t have.”
The misunderstanding is understandable: PKI software is sold as “the PKI.” But a working production PKI is an ecosystem, not a server. This article explains what that ecosystem actually contains, when it makes sense to build it, and when it’s wasted budget.
What’s actually inside a PKI
When we talk about a complete PKI, nine pieces have to exist simultaneously:
- CA hierarchy — an offline root (powered off except during ceremonies), one or more online issuing CAs, and a conscious decision about intermediate subordinates.
- Certificate Policy (CP) — the document that defines what you promise to whoever trusts your certificates.
- Certification Practices Statement (CPS) — how that policy is followed in daily practice.
- Certificate profiles — per use case (internal TLS, document signing, EMV, 3DS, code). Each with different lifetimes, extensions, key usage.
- Ceremonies — root installation, subordinate activation, renewal, retirement. Each written, scripted, executed under dual control, with signed records.
- Revocation strategy — CRL, OCSP, OCSP stapling. With explicit SLOs: how long between revoking a cert and the network knowing.
- Monitoring — what’s measured (upcoming expirations, CAs available, OCSP responder up), what triggers an alert, who handles it.
- Governance model — who approves a new certificate profile, who has custody of keys, what happens when personnel rotate.
- Cryptographic-agility strategy — what happens when an algorithm is deprecated (SHA-1, eventually RSA-2048), what happens facing the post-quantum horizon.
None of these pieces is bought with the CA software. All nine are work — design, writing, procedure.
Three signals you do need a PKI
Not every institution needs its own PKI. Before getting on board, check whether any of these three situations apply:
1. The regulator or auditor is asking for it
In Peru, the SBS and, depending on the sector, other regulatory entities require documented mechanisms for authenticity and integrity. If you have an open finding on document signing, secure messaging between internal systems, or service authentication, a PKI is typically the right answer.
2. Your business depends on a use case that requires it
The use cases that almost always justify your own PKI:
- Card issuance with EMV — you need Issuer CAs aligned with the schemes (Visa, MasterCard).
- 3D Secure as issuer or acquirer — the 3DS session depends on specific certificates.
- Digital signature with legal validity — for internal processes or client-facing.
- Secure messaging between internal systems — mutual TLS (mTLS) between microservices or between your core and satellites.
3. You have a legacy PKI that lost its owner
This is the most common situation and the most dangerous. A PKI without living governance accumulates silent risk:
- Certificates renewed “the way they’ve always been” without anyone able to explain why.
- Undocumented ceremonies that depend on one person’s memory.
- Revocation procedures no one has tested in years.
- One day the regulator asks, and the organization panics.
Rebuilding governance on top of an existing PKI is work, but it’s finite work. Postponing only makes it more expensive.
Three signals you do NOT need your own PKI
Sometimes the answer is don’t build your own PKI:
- Low volume and few use cases. If all you need is TLS for your public site, Let’s Encrypt solves it. You don’t stand up a CA for that.
- No willingness to govern. A PKI without governance is worse than not having one. If the institution won’t commit to CPS, ceremonies and monitoring, consume managed PKI services instead.
- No use case with a clear owner. “Having a PKI just in case” is not a use case. It’s a project that deflates.
The right question before starting
Before asking for budget for a PKI, the question isn’t “which CA software do we use” or “which HSM do we buy.” The question is:
What are the concrete use cases that justify this PKI, who owns each one, and what happens to each if the PKI fails?
If the answer is clear, the software and the HSM are a consequence. If the answer is vague, no software is going to fix that.
At 2PSECURE we design complete PKIs — the ecosystem, not just the platform — for financial institutions that need to pass audits and keep operating afterward. If your organization is in one of the three situations above, let’s talk about your case.
Found it useful? Share it: