What Is PKI (Public Key Infrastructure)

A PKI (Public Key Infrastructure) is the combination of hardware, software, policies, procedures and authorities that issue, distribute, manage and revoke digital certificates based on asymmetric cryptography. It is the invisible infrastructure that lets a browser trust https://secra.es without having seen it before, an S/MIME email get signed with a verifiable identity, an employee authenticate with a smart card and a public administration issue digital signatures with legal value. Without PKI there is no TLS, no recognised electronic signature, no certificate-based authentication and, in practice, no scalable digital trust between systems that did not know each other beforehand.

This guide explains what a PKI is, the components that build it, how the chain of trust works, the enterprise use cases that appear most often, the differences between public and private PKI, the mistakes that turn up in audits and how it fits NIS2, eIDAS, ISO 27001 and the rest of the regulatory landscape.

What a PKI is

A PKI is a trusted system that links digital identities (people, devices, domains, services) to public keys through certificates signed by a recognised authority. Asymmetric cryptography (RSA, ECDSA, Ed25519) lets each entity hold a key pair: a public key that can be shared and a private key only it custodies. PKI solves the question of "how do I trust that this public key actually belongs to who it claims" through a chain of signatures.

What it brings operationally:

• Authentication: the receiver of a certificate can verify that the public key of the other party is signed by an authority they trust.
• Confidentiality: encryption of data in transit (TLS) or at rest (S/MIME, signed files). Federation protocols that support enterprise SSO also depend on PKI to sign assertions.
• Integrity: any modification to signed data is detected when the signature is verified.
• Non-repudiation: the signer cannot later deny having signed a document (in jurisdictions with eIDAS or equivalent).

PKI is the technical foundation of legally valid electronic signatures, server TLS certificates, client certificates for corporate authentication, S/MIME for email, code signing, IoT device certificates and more.

Components of a PKI

Five pieces every serious PKI has:

Certificate Authority (CA)

The CA is the entity that issues and signs digital certificates. It holds a private key under maximum protection (HSM, off-line, segregated). Its public key is embedded in operating systems and browsers as a "trust root" when it is a public CA.

CAs form hierarchies. The root CA issues certificates to intermediate CAs, which in turn issue end-use certificates (TLS, S/MIME, authentication). This structure lets a compromised intermediate CA be revoked without touching the root.

Public examples: Let's Encrypt, DigiCert, Sectigo, Entrust, GlobalSign. In Spain: FNMT-RCM (Fábrica Nacional de Moneda y Timbre), Camerfirma, Firmaprofesional, AC Catalunya.

Registration Authority (RA)

The RA is the entity that verifies the identity of the applicant before the CA issues the certificate. In small corporate PKI this is usually the same person or system as the CA; in large public PKI they are separate entities (physical offices or automated processes for TLS domain validation).

Digital certificate

The certificate is a file signed by the CA containing the holder's public key plus their identifying data. The dominant standard is X.509 v3.

Typical fields:

• Subject: who it belongs to (CN=secra.es, O=Secra Solutions, etc.)
• Issuer: who signed it (the CA)
• Validity period: from when to when it is valid
• Public key: the holder's public key
• Signature: the CA's signature over the rest of the certificate
• Extensions: usage restrictions (TLS server only, client auth only, code signing only), revocation URLs, SANs (Subject Alternative Names) for multiple domains

CRL (Certificate Revocation List) and OCSP

Revocation is what lets you invalidate a certificate before it expires (compromised private key, holder leaving, emission error).

• CRL: a list published periodically by the CA with every revoked certificate. The client downloads and consults it. It works but it is inefficient with large CRLs.
• OCSP (Online Certificate Status Protocol): the client asks an OCSP server about a specific certificate in real time. More efficient than CRL.
• OCSP Stapling: the TLS server attaches the signed OCSP response to the handshake, removing the client's query to the OCSP responder. The recommended model today.

Repository and policies

PKI also includes CPS (Certification Practice Statement) and CP (Certificate Policy): documents detailing how the CA operates, verifies identities, manages keys, audits and responds to incidents. In public PKI these documents are mandatory and public.

How the chain of trust works

When a browser opens https://example.com:

1. The server sends its TLS certificate to the browser, along with the chain of intermediate CAs that signed it.
2. The browser looks up the root CA in its local trust store.
3. It verifies the signature of every intermediate CA up to the root.
4. It checks validity (dates, SAN matches the domain, not revoked via OCSP/CRL).
5. If everything matches, the client trusts the certificate and the TLS connection is established.

Any broken link breaks the chain: root CA not in the store, expired certificate, domain not matching the SAN, revoked certificate, intermediate certificate not delivered by the server (a frequent cause of "incomplete chain").

Common enterprise use cases

PKI is not just TLS. The uses that appear in mid-sized and large organisations:

Public vs private PKI

The two coexist in any mid-sized organisation.

Public PKI

Operated by a globally recognised CA whose root certificate ships in browsers and operating systems. Used for identities that need to be valid externally (public web, cross-domain S/MIME, recognised signature under eIDAS).

Pros: universal trust, no need to distribute root certificates. Cons: cost per certificate (except Let's Encrypt for domain-validated TLS), subject to CA/Browser Forum policies and audits.

Private PKI

Operated by the organisation itself for internal identities (mTLS between microservices, employee authentication with smart cards, device certificates in an IoT fleet). The root certificate is distributed to the systems that need to trust it.

Pros: full control, low cost per certificate, custom validity periods. Cons: operational burden (HSM, rotation, revocation, root distribution). If the team cannot maintain the PKI, outsourcing makes sense.

Common products for private PKI: Microsoft AD Certificate Services (in Windows-heavy organisations), HashiCorp Vault PKI, EJBCA, Smallstep CA, homemade OpenSSL CA (not recommended in production).

Common mistakes in PKI management

Five patterns that show up in audits:

1. Certificates without rotation. Long-lived certificates (5-10 years) that never get renewed, private keys older than the recommended algorithm, no documented rotation process.
2. CA private key on disk without HSM. Any compromise of the server hosting the CA invalidates the whole PKI. The root CA private key should live in an offline HSM; intermediate CAs in an online HSM with auditing.
3. No working CRL or OCSP. When a certificate has to be revoked, in practice you cannot. Clients keep trusting certificates that should already be invalid.
4. Obsolete algorithms. SHA-1, RSA-1024, DSA keys. Any modern audit flags this. The minimum migration is to SHA-256, RSA-2048 or ECDSA P-256.
5. Intermediate CAs reachable from outside the admin network. If the CA issues certificates from an exposed server, an intrusion gains the ability to mint arbitrary certificates. The CA must live on a segregated administrative network.

PKI and compliance

Frameworks where PKI is required or strongly recommended:

• eIDAS (EU Regulation 910/2014, upcoming eIDAS 2). Sets three levels of electronic signature (simple, advanced, qualified). The qualified signature requires a certificate issued by a supervised qualified trust service provider.
• NIS2 (article 21). Demonstrated effectiveness of technical measures, including digital identity management and cryptography. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (article 9). Secure management of data and communications in financial entities.
• ENS (Spanish Royal Decree 311/2022, Operational Framework). Use of electronic signature and certificates with recognised validity in the Spanish public sector.
• ISO 27001:2022 (controls 8.24 and 8.26). Use of cryptography and cryptographic key management.
• PCI DSS v4.0 (req. 3 and 4). Protection of card data at rest and in transit with strong cryptography.

For regulated companies, PKI is not optional. It is critical infrastructure that the auditor reviews specifically.

Frequently asked questions

What is the difference between PKI and a digital certificate?

A digital certificate is one of the components of the PKI. The PKI also includes the authority that issues it (CA), the prior verification step (RA), the revocation system (CRL/OCSP), the operational policies (CPS) and the technical infrastructure (HSM, repositories). The certificate alone does not work; it needs the rest of the PKI ecosystem to carry value.

Does my company need a private PKI?

Probably not if every certificate you use is public-server TLS (covered by Let's Encrypt or a commercial CA) and external electronic signature (covered by FNMT or another provider). You do need a private PKI if you run mTLS between internal microservices, employee authentication with a corporate smart card, IoT fleets with per-device certificates or VPN authentication based on internal certificates.

How much does it cost to stand up a private PKI?

Base cost depends on whether you go with open source software (EJBCA, Smallstep, HashiCorp Vault PKI free tier) or enterprise (DigiCert ONE, Microsoft AD CS on Windows Server). The main spend sits in HSM (typically 10-50k€ for a redundant pair) and in team hours for operation (rotation, revocation, certificate management). Outsourcing to a managed PKI provider can simplify the decision when the organisation has no dedicated team.

What happens if my CA private key gets compromised?

It is the worst-case scenario. Every certificate issued by that CA is in doubt until the full PKI is rotated: new CA, reissuance of every end-use certificate, distribution of the new root to every client that trusts the PKI, invalidation of the old CA. That is why the root CA private key is kept offline in an HSM and only used to sign intermediate CAs in audited ceremonies.

Is an FNMT electronic signature valid for international corporate use?

A signature with an FNMT certificate is legally valid in Spain and across the EU under eIDAS. For use outside the EU, it depends on the receiving country's framework. For international B2B agreements, platforms like DocuSign or Adobe Sign are common: they combine an eIDAS qualified signature with their own audit trail that has broader recognition.

Is it possible to run PKI without HSM?

Technically yes, by storing the private key on disk with restrictive permissions. In practice any serious audit (especially under eIDAS or for meaningful intermediate CAs) requires HSM because it is the only way to guarantee the key never leaves the device. For low-risk private PKI (internal mTLS, non-critical IoT) it can be acceptable to start without HSM and migrate later.

Related resources

• What is a CVE: vulnerabilities explained: how vulnerabilities in cryptographic libraries and PKI get tracked.
• What is a SOC (Security Operations Center): the operation that monitors compromises in corporate PKI infrastructure.
• What is SIEM and how it works: how certificate-related events become detection signals.
• NIS2 in Spain: compliance guide for 2026: the regulatory framework where PKI delivers evidence of technical measures.
• JWT security: vulnerabilities and best practices: the asymmetric algorithms (RS256, ES256) that JWT borrows from PKI.

PKI at Secra

At Secra we work with PKI on two fronts: as part of technical audits (review of TLS, mTLS, client certificates, code signing, key management and rotation implementations) and as support in NIS2, ENS or ISO 27001 compliance projects where cryptography and key management are in scope. If your organisation wants to validate the posture of its PKI or needs support designing a key infrastructure for regulatory compliance, get in touch through contact or check our GRC consulting services.