Skip to main content

Modernize PKI, improve crypto-agility and prepare for post-quantum readiness

Vault now supports certificate issuance via ACME fully with Public CAs. Issue PQC-ready certificates now and improve crypto-agility with Transform and Transit enhancements.

As enterprises scale AI-driven workloads, expand hybrid cloud environments, and navigate evolving cryptographic requirements, security teams are under increasing pressure to automate certificate lifecycle management, maintain cryptographic compliance, and prepare for post-quantum threats without adding operational complexity. In this blog, we'll highlight capabilities that advance public certificate automation, PKI modernization, post-quantum readiness, and crypto agility, helping organizations build a more resilient and future-ready security foundation for the autonomous hybrid cloud. 

»Shorter certificate lifecycles require automated process for scale 

Today, security and platform teams manage a growing volume of public certificates that secure critical applications and services. Without centralized visibility and automated processes for issuance, renewal, rotation, and revocation, organizations risk expired certificates, service outages, audit failures, and security gaps. Changes in certificate operational periods as outlined by the Certificate Authority Browser Forum have set phased reductions in certificate lifetimes from 398 days max for certificates issued before March 14, 2026 to 47 days for certificates issued after March 15, 2029. As certificate lifetimes shrink, manual processes cannot scale. Organizations need a secure, automated way to manage and renew external CA-issued certificates, helping teams maintain trust, reduce operational risk, and safeguard critical services. 

»Automate public certificate workflows with Vault 

Vault 2.2 adds native orchestration for public CA workflows, extending the PKI secrets engine’s private CA capabilities to publicly trusted certificates. Direct integrations, centralized policies, and automated issuance, renewal, rotation, and revocation reduce manual handoffs and help teams maintain continuous trust across applications and environments. 

Application developers need a fast, reliable way to request certificates for themselves, their applications, or their systems so they can access resources or provide services that use certificate-based authentication. When public CA enrollment depends on manual approvals, certificate signing requests, and domain validation, developers may face release delays, inconsistent processes, and certificate-related outages. Automated, self-service issuance and renewal reduce this friction while helping developers deploy trusted applications securely and at scale. 

»Validate certificates consistently and at scale 

Vault 2.2 delivers the HTTP and DNS-based validation methods to obtain and renew public certificates. Previously, these processes required manual coordination across security, networking, application, and platform teams, an approach that was manageable when certificate volumes were lower. As internet-facing applications, machine identities, and renewal activity grow, organizations can depend on Vault to validate domain ownership consistently, maintain visibility, and prevent issuance failures. The result is operational efficiency, reduced risk of certificate related outages due to incomplete validation and the ability to scale across hybrid cloud environments.   

»Centralize certificate visibility and governance 

With the latest release, Vault users can, within the Vault UI, request and issue public certificates from their organization’s public certificate authority. Vault automates issuance and deployment while providing visibility into certificate orders, status, validity, and the external Certificate Authority, as well as controls for managing DNS and HTTP challenges.  

An image of the Vault UI with updates to Secrets Engine to view and manage public certificates.

Fig. 1: Manage PKI within the Vault UI with a centralized view of roles and status.

An image of the Vault UI showing the detail of certificate orders.

Fig. 2: View the detail on certificate orders within the Vault UI.

Supported DNS challenge partner integrations include AWS, GCP, Azure, NS1, Infoblox, Akamai, BlueCat, Cloudflare, DigitalOcean, and GoDaddy. This centralized view of the certificate lifecycle improves visibility, governance, and operational efficiency while simplifying audit and compliance tracking. 

»Build post-quantum cryptography readiness 

The shift to post-quantum cryptography is urgent because quantum threats put both confidentiality and trust at risk. In a Harvest Now, Decrypt Later attack, adversaries collect encrypted data today with the expectation that future quantum computers will decrypt it, exposing information that must remain confidential for years. In a Trust Now, Forge Later attack, quantum computers could break vulnerable digital-signature algorithms, enabling attackers to forge certificates, software signatures, identities, or transactions that appear legitimate. Legacy infrastructure, hard-coded algorithms, fragmented certificate workflows, and format-dependent data protections make the transition to quantum-resistant cryptography slow, costly, and disruptive.  

Enterprises must assess their post-quantum readiness now and establish a phased migration plan for modernizing PKI, replacing vulnerable algorithms, and building crypto-agility into key workflows. 

»Operationalize post-quantum protection at scale 

Platform engineers must turn post-quantum requirements into production-ready services without disrupting applications or infrastructure. NIST finalized its first post-quantum standards in August 2024, including FIPS 204 for ML-DSA digital signatures, and recommends that organizations begin migrating now before it removes quantum-vulnerable algorithms from its standards by 2035. Yet fragmented tools and algorithm dependencies make it difficult to modernize cryptography safely and at scale. 

PKI migration is especially difficult because replacing quantum-vulnerable roots, certificate authorities, and downstream certificates can disrupt services, while operating traditional and post-quantum PKI together adds complexity. Vault 2.2 brings ML-DSA support to X.509 certificates in the PKI Secrets Engine with workflows designed to lower operational and security risk. Platform engineers can issue post-quantum X.509 certificates and build a more resilient root of trust by leveraging these automations in certificate lifecycle management and executing PKI modernization. 

»Vault 2.2 builds crypto-agility into Transit 

When enterprises tie cryptographic workloads to specific algorithms, they accumulate technical debt and face security risk when standards bodies deprecate those algorithms or attackers compromise them. Rotating a key does not solve the problem because the original algorithm still restricts teams. Moving to modern standards, including post-quantum algorithms, can therefore break stable key references or require manual, error-prone application code changes. 

Vault 2.2 separates the logical key use from the cryptographic algorithm behind each version, so teams can modernize without changing stable key references. Users can add a new Key Version with a different algorithm, for example, moving from ECDSA to ML-DSA  within the same parent key. The Transit service automatically selects the appropriate key material and algorithm based on the version ID, abstracting cryptographic complexity from applications and enabling crypto-agility at scale. This allows organizations to continuously evolve their cryptographic posture, adopt stronger and post-quantum standards without disrupting business operations, and rapidly reduce risk by phasing out vulnerable algorithms as new threats and compliance requirements emerge. 

»Secure data with NIST-approved FF1 

Vault 2.2 helps organizations strengthen format-preserving encryption by moving ADP Transform FPW algorithms from FF3-1 to FF1. After researchers identified security concerns with FF3 and FF3-1, NIST retained FF1 in its latest SP 800-38G Revision 1 draft. Vault uses FF1 as the standard for new encryption and limits FF3-1 to decrypting existing data during the transition. A new rewrap process will let teams convert legacy data to FF1 without changing its format or compromising data integrity, supporting a smoother and more secure migration. 

»Start your PKI modernization and improve crypto agility

Explore the Vault developer documentation to learn more about these capabilities and plan your next steps. Talk with an IBM representative about your PKI modernization and post-quantum readiness priorities, and where supported, upgrade to Vault 2.2 to begin putting these into practice for improved crypto agility. 

More posts like this