Your situation The typical moment when clients call
- The regulator or auditor asked for documentation. A CP, a CPS, a revocation plan, ceremony evidence. And no one on the team has it written down.
- There's a new use case demanding digital signature. Documents, code, EMV, IoT, open banking. The current PKI wasn't designed for it and you have to decide whether to extend or create a new one.
- The legacy PKI lost its owner. Whoever designed it is no longer there. Renewals are done "the way they've always been" without anyone able to explain why.
- Decision to move from a managed provider to internal operation (or vice versa). The question isn't just which CA to use; it's what happens with everything around it.
Why it's hard to solve internally The software is 10% of the problem
We've seen many implementations where someone turned on EJBCA or
equivalent, generated certificates, and that's where it stopped:
no policies, no ceremony documentation, no revocation plan, no
monitoring, no strategy facing deprecating algorithms. When the
regulator arrives or when the original team rotates, the project
falls apart.
The hard part isn't installing a CA. It's writing what surrounds
it — with enough detail to survive audits and personnel rotation,
and with enough common sense for your team to operate it.
What we deliver The complete ecosystem, including the platform
- CA architecture (root, subordinate, issuing) aligned with your real use cases.
- Certificate profiles per use case (TLS, document signing, EMV, 3DS, code).
- Written and executable ceremony procedures: installation, activation, rotation, retirement.
- Revocation strategy (CRL, OCSP, OCSP stapling) with explicit SLOs.
- Monitoring and alerting plan: what's measured, what triggers an alert, who handles it.
- Governance model: CP, CPS and clear responsibility matrix.
- Cryptographic agility strategy: how your PKI prepares against deprecating algorithms and the post-quantum horizon.
Platform installation (EJBCA or other) follows the design.
That's why the result passes audit.
Digital signature as a use case When what you need is for something to be signed and verifiable
Digital signature is one of the most concrete use cases for a
well-designed PKI: document signing, customer-notification
signing, transaction or order signing, code signing. The PKI is
designed with specific certificate profiles for each, with
lifetimes, ceremonies and revocation tuned to the risk of the
case. It's not a separate capability — it's what you get when
the PKI is built right.
If you already have a PKI running Maturity assessment before any change
For institutions with a PKI already in operation, we first offer
a maturity assessment based on public sector frameworks (PKI
Maturity Model from the PKI Consortium) adapted to the LatAm
regulatory context. The deliverable is a report with concrete,
prioritized gaps in governance, management, operations and
resources. So investment goes to what's really weak, instead
of what's easiest to do.
What changes for you Verifiable outcomes
- The next visit from the regulator or auditor finds documentation that passes review.
- The new use case (open banking, EMV, document signing) starts with certificate profiles already defined.
- Critical renewals no longer depend on one person's memory.
- Your institution has a declared position on crypto agility and post-quantum migration.
Platforms Software and HSM
The HSM behind the PKI is typically Utimaco. We've
deployed EJBCA as CA software across multiple
scenarios. Selection is decided by your constraints (regulatory,
budget, support, internal operation), not by a preference of
ours.
Next step Tell us what the regulator or auditor asked for
If you have a deadline, this is the time to talk. If you're still
evaluating whether your PKI needs attention, also.
