Decentralized PKI: The New Reality

The migration to cloud has quickly shifted the security focus from boundaries to identities. In this perimeterless model, nothing is inherently trusted until it’s authenticated and authorized with a unique identity – an idea known as zero-trust security. 

Public key infrastructure (PKI) and machine identities are key ingredients to zero trust security. Everything from virtual machines, containers, applications, container orchestration, and service mesh platforms all rely on keys and certificates to authenticate and securely communicate with one another.

Knowing what can be trusted, in which environments, and when, depends on digital certificates and the public key infrastructure (PKI) that sits behind them.

Behind every certificate is a certificate authority (CA). Microsoft Active Directory Certificate Services (ADCS), often referred to as Microsoft CA, has long been the de facto choice for many organizations. It’s well integrated with Microsoft infrastructure and it supports standard use cases like user and device authentication.

However, the path to the cloud introduces new challenges. For starters, most on-premise PKI deployments just weren’t built to handle the volume and velocity of certificate usage today. Not to mention a lack of out-of-the-box integrations with non-Microsoft infrastructure and commonly overlooked misconfigurations that lead to serious security risks.

Organizations now face a dilemma — they’ve outgrown their traditional PKI. As a result, many need to re-build or redesign to support this new reality. It starts with looking at the wide array of CAs that serve as the backbone of PKI today.

The reality is that PKI no longer consists of just one or two CAs behind the four walls of your data center. Today’s hybrid and multi-cloud operations involve various public, private, open-source, and cloud-based CAs, each implemented by different teams to meet specific use cases.

The new reality is a decentralized PKI model – a web of trust that extends across on-premise and cloud environments. In other words, PKI is everywhere, certificates are everywhere, your machines are everywhere, and it’s all being driven by:

• Hybrid trust: every organization relies on a mix of trusted third-party CAs and internal private CAs to meet trust models within and outside the organization.
• Hybrid and multi-cloud: most businesses use multiple cloud services, such as AWS, Azure, and Google Cloud Platform, each with their own built-in capabilities for certificate issuance.
• Availability: uptime is money. PKI infrastructure is deployed in clustered, geo-redundant or high-availability architectures to avoid a single point of failure and ensure uptime for certificate revocation and issuance.
• Specialized use cases: CI/CD toolchains and containerized environments require short-lived SSL/TLS certificates versus traditional web servers and devices that may leverage one or two-year certificates.
• Dispersed teams: different teams and departments across the organization prefer different CAs due to cost, requirements, certificate types, assurance levels, etc.
• Lack of integrations: ADCS is well-suited for Microsoft infrastructure, but it does not offer native support for other applications, creating a heavy burden on teams to develop homegrown scripts and tracking mechanisms.
• Business growth: mergers and acquisitions in high-growth companies result in mixed CA environments, often with conflicting rules and security policies.

Whether you have multiple CAs already in production, or you’re starting from scratch, there is a lot to consider. PKI systems are complex and require proper planning and implementation to ensure trust and availability across the organization.

So, what now? Do you spin up a new cloud CA? Do you extend your existing PKI to the cloud? Do you allow teams to use a built-in issuer? How do you manage decentralized PKI? There are plenty of important questions and discussions ahead of you, but it starts with these five key considerations.

Trust requirements 

Determine where public and private certificates are best suited on a case-by-case basis to avoid blurring trust boundaries. Then consider the PKI infrastructure you’ll need to support this trust model and how you’ll delegate and manage trust across different siloes. 

Assurance levels 

Consider the physical and digital safeguards around your root and issuing CAs. For testing purposes, it may be acceptable to issue certs from a low-assurance PKI, whereas production certs require higher levels of assurance. 

Required expertise 

Determine if you have the right expertise, bandwidth, hardware and security controls in place to implement a secure internal PKI, including an offline air-gapped root CA, and maintain it over a 10-20 year lifespan. 

Use cases

Identify use cases across infrastructure, security, network, and application teams. Determine the certificate types, templates, issuance volume, protocols, integrations, self-service and automation capabilities these teams will need to support their specific use cases. 

Business continuity 

Mergers, acquisitions, divestitures, and overall business growth will change your PKI over time. Ensure that you have the ability to take these different business environments and propagate trust across all of them appropriately. 

Crypto-agility

Prepare for the eventual migration to new key sizes and algorithms, or in the short term, for a potential CA failure or vulnerability. The ability to revoke and re-issue certificates at massive scale is critical to your success.

Download the Beginner’s Guide to Scaling PKI in Hybrid and Multi-Cloud Operations to discover the key differences and implementation needs between different CAs in your environment.

Ready to start? Check out our flexible deployment options to achieve zero-trust with end-to-end governance and automation in decentralized PKI environments.