Whether you think of it as a security technology, a security model, or something you rarely think about at all, public key infrastructure (PKI) is an essential part of everyday life. From smart TVs to fuel pumps to the entire World Wide Web, PKI enables systems to identify who (and what) they can trust. 

Digital trust isn’t universal or absolute; it’s contextual, situational, and shaped by risk. When two parties recognize the same authority, they can trust what it produces. That’s true for information, currency, and identity documents—and it’s just as true in digital systems. 

Trust also changes based on context. I trust my old Land Rover to handle tough off-road trails, but I’d think twice before taking it on a long road trip—even though it’s never let me down. PKI works the same way. The question isn’t whether something is trustworthy, but whether it’s trustworthy enough for the job at hand. 

The 3 types of PKI

PKI uses certificate authorities (CAs) to issue certificates that systems like web servers, devices, and even people use to prove their identities and communicate securely. When you trust a CA, you implicitly trust the certificates it issues. That relationship is what makes PKI flexible enough to support trust in the real world.  

Broadly speaking, there are three PKI trust models, each suited to different use cases: 

• External PKI relies on public certificate authorities that are trusted by default in web browsers and major operating systems. These CAs operate under governance frameworks defined by the CA/Browser Forum and enforced by browser and OS vendors. The most common example is the Web PKI, where CAs like DigiCert, Sectigo, and Let’s Encrypt issue TLS certificates for public-facing web servers.
• Internal PKI uses private CAs operated within an organization or other closed environment. The organization controls how trust is established and enforced, including who and what receives certificates. Corporate laptops, internal services, and enterprise devices are often authenticated using certificates issued by an organization’s private CA.
• Federated PKI occupies the space between public and private trust models. These PKIs establish a shared root of trust across multiple organizations, typically within a specific industry or ecosystem. Like the Web PKI, they’re governed externally but tailored to meet specialized interoperability and policy requirements. DirectTrust, which supports trusted information exchange in healthcare, is one example of a federated PKI.

How PKI trust is established and enforced

PKI establishes trust in different ways depending on who operates the CA and who needs to rely on it. Those differences define the boundaries of trust—whether it’s public, confined to a single organization, or shared across an ecosystem. 

Trust with public certificate authorities

In the Web PKI, trust in a certificate authority exists because it operates under a defined set of rules. That trust is enforced through independent audits, external governance, and meaningful consequences for violations. Browser and operating system vendors ultimately decide which CAs are trusted by default—and remove that trust when requirements fail to be met.

Trust within a closed ecosystem

Private PKIs operate very differently. IoT device manufacturers, for example, often use private certificate authorities to issue certificates for their devices. A device that presents a valid certificate issued by the manufacturer’s trusted private CA can be authenticated as genuine and authorized. If the certificate is missing or invalid, the device may be counterfeit, misconfigured, or unauthorized.

This model helps secure device communications, protect software integrity, and limit the impact of tampering or counterfeiting. Operating a private CA, however, isn't an easy feat. It requires layered security controls, disciplined operational processes, and ongoing governance—often exceeding the in-house expertise or resources of many organizations.

Establishing trust in a closed ecosystem also requires every participating system to be explicitly configured to trust the private CA. Without careful planning and ongoing management, this can increase the risk of outages and operational gaps.

Trust across organizational boundaries 

Private PKIs are designed for closed ecosystems. When trust must extend beyond a single organization, that model breaks down. A private CA is neither independently governed nor externally audited, which makes it difficult for external parties to rely on it.

Federated PKIs exist to address this gap. They provide a shared basis for trust across multiple organizations while preserving the specialization and policy control of an internal PKI. These PKIs are typically governed by industry consortiums and operated by commercial PKI providers with established security controls and audit frameworks. 

Unlike the Web PKI, operating systems and browsers don't trust federated PKI roots by default. Participating organizations must explicitly configure their environments to trust them.

External PKI: Convenience with consequences

Because external PKI relies on certificates trusted by major operating systems and web browsers, it offers immediate, broad trust with minimal configuration. For many use cases, that convenience makes public certificates the obvious choice.

The trade-off is that external PKI is governed by policies designed primarily for browsers—not for proprietary devices, internal services, or long-lived infrastructure. Using public certificates outside their intended scope can introduce operational risk as those policies evolve.

When convenience aligns with the use case

External PKI is essential when trust must extend across the public internet. Web servers, public-facing APIs, email, and software distribution all depend on certificates that are trusted by default across browsers and operating systems. In these scenarios, adherence to strict standards and external governance is a feature, not a limitation.

When convenience creates hidden risk

Using public web server certificates for internal APIs, cloud workloads, or device authentication can lead to unexpected disruption. These certificates are subject to ongoing policy changes from the CA/Browser Forum and browser trust programs—changes that may not align with non-browser environments.

Recent examples include: 

• The phased reduction of TLS certificate lifetimes to 47 days, a cadence that’s incompatible with many devices and embedded systems. 
• Chrome’s announcement that it will distrust certificate authorities that issue TLS certificates for client authentication, making affected certificates difficult to identify without deep inventory visibility. 
• Mandatory mass revocation of certificates in response to documentation or compliance errors, increasing the risk of outages even when no security vulnerability exists. 
• Public exposure of internal network names through Certificate Transparency (CT) logs, which can provide reconnaissance value to external attackers. 

When choosing convenience makes sense

None of these outcomes indicate a failure of the Web PKI—they simply reflect its purpose. External PKI optimizes for global interoperability and rapid response to risk, not for operational control in closed or specialized environments. 

When convenience is the primary requirement, external PKI is often the right choice. When control, or long-lived trust relationships matter more, internal or federated PKI models may be a better fit. 

How to pick the right PKI for the job

Choosing the right PKI model is less about cryptography and more about understanding how trust needs to function in your environment. The key question is scope: who needs to trust whom, under what conditions, and for how long. Different PKI models answer those questions in different ways, trading off convenience, control, and interoperability. Understanding those trade-offs makes it easier to match the right PKI approach to the job at hand.

Option 1: External PKI 

External PKI is designed for use cases that require broad, internet-wide trust and default acceptance by browsers and operating systems. That convenience comes with externally governed policies and timelines that may not align with all environments. Common use cases include: 

• Public-facing web servers 
• APIs exposed to external users 
• Email security 
• Software distribution and updates 

Option 2: Internal PKI

Internal PKI is best suited to environments where trust is confined to a single organization and policy control is a priority. It enables flexible identity and authentication for devices, users, and workloads but requires disciplined operations, secure infrastructure, and ongoing governance. Typical use cases include: 

• Secure WiFi and VPN authentication 
• Internal code signing 
• Identity for devices, users, and workloads 
• IoT device authentication 

Option 3: Federated PKI 

Federated PKIs support trust across multiple organizations within a defined ecosystem, balancing shared governance with domain-specific requirements. They enable interoperability and cross-organizational authentication without relying on browser trust programs. Common examples include: 

• Cross-organizational authentication 
• Industry-specific interoperability 
• Shared device identity across ecosystems 
• Examples include the X9 Financial PKI, the Matter PKI, and SAE’s EVPKI. 

Putting PKI into practice

If you’re evaluating how PKI fits into your security or infrastructure strategy, start by clearly defining your use cases and trust boundaries. Understanding where trust needs to originate—and how far it needs to extend—is the most reliable way to select a PKI model that supports both immediate needs and long-term stability.

Get in touch to learn how DigiCert supports external, internal, and federated PKI use cases.