Walk into any modern enterprise running a cloud-native stack, and you will almost certainly find HashiCorp Vault somewhere in the trust chain. What started as a secrets manager for Kubernetes deployments has, over the last few years, quietly become the issuing Certificate Authority for an enormous share of internal mTLS traffic, service mesh identities, ephemeral workloads, and short-lived TLS certificates across DevOps environments. The Vault PKI Secrets Engine is fast, API-driven, infinitely scriptable, and tightly integrated with the tooling that platform teams already love.
The platform team can list certificates per mount if pressed. The security team has spreadsheets of certificates from the public CAs and from Microsoft ADCS. The two never reconcile. When the next 47-day shortening of TLS validity hits, or when the organization starts planning for post-quantum migration, the Vault-issued half of the estate is a black box.
This is not a Vault problem. Vault is doing exactly what it was designed to do: issue certificates fast, with cryptographically sound policies, scoped to whichever team or workload requested them. The gap is that Vault was never built to be the single pane of glass for enterprise certificate lifecycle management. It is a CA, not a CLM.
CertSecure Manager closes that gap. In this blog, we will walk through exactly how the integration works under the hood, what it adds on top of Vault’s native capabilities, and the specific automation and consulting patterns we deploy at client sites to bring Vault-issued certificates into the same governance, visibility, and renewal pipeline as the rest of the enterprise estate.
Why HashiCorp Vault PKI Has Become the Cloud-Native CA
Before discussing the gap, it is worth being precise about why so many enterprises are running so much PKI through Vault to begin with. Three properties of the Vault PKI engine made it a natural fit for cloud-native infrastructure.
API-first issuance with sub-second latency. A vault write pki_int/issue/<role> call returns a fully formed certificate and private key in milliseconds. Compare that to a traditional ticket-driven workflow against Microsoft ADCS, where a developer might wait hours or days for a manually approved certificate, and the appeal is obvious. Workloads that scale up and down on Kubernetes simply cannot wait for human approval cycles.
Short-lived, ephemeral certificates aligned with zero trust. Vault encourages certificates that live for hours or days rather than years. This dovetails with the zero trust security model, where continuous validation replaces long-lived assumptions. A pod that exists for forty minutes does not need a one-year certificate.
Native fit with the cloud-native toolchain. cert-manager, Consul service mesh, Nomad, Terraform, and a long list of CI/CD platforms speak Vault PKI natively. Plugging Vault into the platform layer is, for most teams, a matter of configuration rather than a custom integration build.
The typical pattern we see at client sites is an offline Root CA (sometimes ADCS-based, sometimes EJBCA, sometimes a hardware-anchored ceremony root), with one or more Vault clusters running an intermediate PKI mount per environment or per business unit. Vault becomes the high-throughput issuing layer, while the Root sits in a vault, literally.
It is an architecture we recommend. The problem is what happens after that initial design.
Where Vault PKI Alone Falls Short for the Enterprise
The same properties that make Vault excellent at the workload layer become liabilities at the enterprise governance layer. We see five recurring gaps across consulting engagements.
| Gap | Why It’s Happening | Result |
|---|---|---|
| Visibility Stops at the Vault Boundary | Each Vault cluster, and each PKI mount within that cluster, maintains its own inventory of issued certificates. A query against /pki_int/certs returns serials for that one mount. There is no native federation across clusters, no rollup of “show me every Vault-issued certificate across Dev, Staging, and Production.” Add in the public CA certificates and the Microsoft ADCS-issued certificates, and the enterprise has at least three disjoint inventories with no shared identifier scheme. | Security teams cannot answer the simplest enterprise questions. How many certificates expire in the next thirty days? Which services are still using SHA-1 or 2048-bit RSA? Where are the certificates with wildcard SANs that the compliance team flagged last quarter? Each question requires a manual reconciliation across systems that were never designed to talk to each other. |
| Discovery Gaps Beyond the Issuing Mount | Even within a single Vault cluster, the issuing record and the deployment record are not connected. Vault knows it issued a certificate to a role. It does not know which host that certificate ended up on, which load balancer is presenting it, or whether the consumer is still using it months later. If the consumer service deploys a certificate to ten endpoints, Vault sees one issuance. | When a security incident requires impact analysis (“we need to revoke every certificate with the old SAN policy”), the team has to combine Vault data with network discovery, endpoint scans, and tribal knowledge to find every place the certificate is actually presented. This is exactly the kind of fragmented response that turns a minor finding into a multi-week remediation project. |
| Renewal Lives on the Consumer, Not the Issuer | Vault’s design philosophy hands renewal to the consumer. The platform team configures the workload to request a new certificate before the current one expires, and Vault happily issues again. When that consumer is Kubernetes with cert-manager, it works beautifully. When that consumer is a legacy Java application running on a VM in a different business unit, renewal is whatever someone wrote in a runbook three years ago, assuming the runbook still exists. | Certificate outages happen at the boundary between Vault’s modern issuance model and the older infrastructure that consumes Vault-issued certificates. The PKI team is blamed for an outage they had no visibility into. |
| No Native Approval Workflow or Cross-Team RBAC | Vault enforces policy at the token and role level. If a token has the update capability on pki_int/issue/web-server, it can issue web-server certificates. There is no native approval gate, no four-eyes review, no business-context tagging at issuance time. The Vault role’s allowed_domains is the only policy boundary, and it is binary: either the SAN matches the allow-list or the issuance fails. | This works for the platform team that owns Vault. It does not work for the security team that needs to enforce “high-value certificates need security review before issuance” or “any certificate with a SAN matching the production payment domain requires explicit approval.” Those controls have to live somewhere above Vault. |
| Audit and Compliance Evidence Are Fragmented | Vault’s audit device produces an extraordinarily detailed log of every operation. It is also written in Vault’s JSON schema, separate from the audit trails of every other CA in the environment, with no business context attached. Auditors do not want raw Vault logs; they want evidence that high-risk certificates were approved, by whom, when, and for which business reason, across all CAs in scope. | Compliance teams end up running quarterly reconciliation projects to produce the evidence auditors actually want, pulling data from Vault, from ADCS, from the public CA management portals, and stitching it together by hand. This is operationally expensive and tends to surface the embarrassing finding that the reconciliation itself is incomplete. |
How CertSecure Manager Integrates with HashiCorp Vault PKI
CertSecure Manager addresses these gaps by sitting above Vault as an orchestration and governance layer. The integration is intentionally lightweight on the Vault side: we do not ask clients to modify Vault policies in disruptive ways or to replace any existing automation. The integration uses the same REST API surface that Vault exposes to every other consumer.
Authentication via AppRole
CertSecure Manager authenticates to each Vault cluster using the AppRole auth method. We deliberately avoid root tokens and we never store long-lived bearer tokens in the CertSecure Manager configuration. The AppRole pattern uses a role_id (which can be stored alongside the integration config) and a short-lived secret_id (delivered through a secure secret-zero process). CertSecure Manager exchanges the two for a Vault token at the start of each session, the token is bounded by a configurable TTL, and renewal happens automatically as long as the integration is active.
The Vault policy bound to that AppRole is scoped to exactly what CertSecure Manager needs: read access to the PKI mount metadata, list access to issued certificates, and issue/revoke capability on the specific roles in scope. Nothing more. This means a compromise of the CertSecure Manager integration cannot escalate to administrative access on Vault.
Multi-Cluster, Multi-Environment Topology
Most of our clients run separate Vault clusters for Development, Staging, and Production, sometimes with additional clusters for regulated workloads or for specific business units. CertSecure Manager handles this natively. Each Vault cluster is configured as a distinct CA target with its own AppRole credentials, its own network path (HTTPS with a CA-bundle-validated certificate on the Vault listener), and its own set of mounts and roles in scope.
This matters more than it sounds. It means the same CertSecure Manager deployment can govern certificate issuance across an entire enterprise without conflating environments. A request submitted against the production template lands on the production Vault cluster. There is no cross-environment leakage by design.
Per-Mount, Per-Role Mapping
Within each cluster, CertSecure Manager maps its certificate templates to specific Vault PKI mounts and roles. A template named “Internal Web Server – Production” might map to the pki_int_prod/issue/web-server role on the production Vault cluster, with all the role’s underlying policy (allowed_domains, max_ttl, key type constraints) preserved.
This mapping is the seam where consulting expertise pays off. We size the templates against the client’s actual issuance patterns, eliminate overlapping roles, and bring the Vault role definitions into alignment with the enterprise certificate policy. By the end of the integration, every template the requester sees in the CertSecure Manager portal corresponds to a known, audited, policy-aligned Vault role.
What CertSecure Manager Layers on Top of Vault PKI
This is where the consulting value lives. The integration itself is straightforward. The transformation happens in what CertSecure Manager does with Vault as a back end.
1. Centralized Discovery Across All Vault Mounts and Clusters
CertSecure Manager periodically enumerates every configured PKI mount across every configured Vault cluster. For each mount, it pulls the list of issued certificate serials, fetches the full certificate metadata, and ingests it into the central inventory. The result is a single, queryable, deduplicated record of every certificate Vault has ever issued in the environment.
We extend this with network-based discovery. CertSecure Manager’s TLS scanner sweeps the client network ranges, identifies certificates actually being presented in production, and cross-references the serials against the Vault-issued inventory. When a Vault-issued certificate is detected at an endpoint that was not previously known, it is automatically tagged with the deployment location. When a Vault-issued certificate is in inventory but never observed on the network, it gets flagged for cleanup review. The discovery gap closes.
2. Single-Pane Visibility Across Vault, ADCS, and Public CAs
Vault-issued certificates land in the same dashboard as Microsoft ADCS, DigiCert, Entrust, Let’s Encrypt, and any other CA the client uses. Expiry timelines, ownership tagging, algorithm distribution, and SAN-based search work across the entire inventory. The reconciliation project disappears because there is nothing to reconcile; every certificate, regardless of issuing CA, is in the same record.
This is the single most consequential outcome of the integration. Security teams can finally answer the questions they have always needed to answer.
3. Policy-Driven Issuance Mapped to Vault Roles
CertSecure Manager templates carry policy that Vault roles do not natively support: approval workflows, role-based access controls scoped to specific requesters, custom fields for business context, and validation logic that runs before the request ever reaches Vault. A certificate request that violates the template policy is rejected at the CertSecure Manager layer. A request that passes is translated into a Vault issue call with the exact parameters required.
The Vault role becomes a policy floor, not a policy ceiling. CertSecure Manager can tighten the issuance criteria for specific templates beyond what the underlying Vault role allows, without touching the Vault configuration.
4. Automated Renewal Orchestration and Deployment
This is where the renewal gap closes. CertSecure Manager monitors every Vault-issued certificate in inventory and schedules renewal at a configurable point in the certificate’s lifetime, typically at seventy-five percent of validity for short-lived certificates, or thirty days before expiry for longer-lived ones. When renewal is triggered, CertSecure Manager re-issues against the same Vault role, retrieves the new certificate, and pushes it to the deployment target through the appropriate connector: F5 BIG-IP, IIS, Apache, NGINX, Tomcat, Kubernetes secrets, Azure Key Vault, or a custom connector for environments outside the standard library.
The consumer no longer has to manage its own renewal. The PKI team gets a centralized view of every renewal in flight, every renewal that succeeded, and every renewal that failed and needs intervention.
5. Audit Aggregation and Compliance Evidence
CertSecure Manager maintains a complete, tamper-evident transaction log of every certificate operation it brokers. When that operation routes through Vault, the CertSecure Manager log carries the Vault correlation identifiers, the requester identity, the template used, the approval chain (if applicable), and the business context fields. Auditors get exactly the evidence they need, pre-formatted for SOC 2, PCI DSS, ISO/IEC 27001, and HIPAA reviews, without the quarterly reconciliation project.
| Capability | Vault PKI Alone | With CertSecure Manager |
|---|---|---|
| Visibility | Visibility scoped to each Vault mount and cluster | Centralized inventory across every cluster, mount, and other CA in the environment |
| Discovery | Discovery stops at issuance, with no link to deployment locations | TLS network scanning correlated with Vault issuance records to map every deployment |
| Renewal | Renewal handed to the consumer, with no central oversight | Scheduled, policy-driven renewal and automated push to deployment targets |
| Approval & RBAC | No native approval workflow or cross-team RBAC at Vault | Template-based approvals, RBAC, and custom business-context fields enforced before issuance |
| Audit | Audit evidence fragmented across Vault and other CAs | Unified, auditor-ready transaction logs aligned with major compliance frameworks |
| Crypto-Agility | Switching algorithms or CAs requires touching every consumer | Template binding at the CLM layer allows underlying CA changes without consumer impact |
Why This Matters Right Now
The pressure on certificate operations is increasing in ways that will not let traditional fragmented models survive. Browser vendors are driving toward progressively shorter TLS validity periods, with the 47-day target now in active discussion. Machine identity counts continue to grow at roughly an order of magnitude faster than human identities. The first wave of practical post-quantum migration is moving from research into procurement conversations. And the regulatory environment around cryptographic inventory, driven by executive orders, NIST guidance, and the post-quantum readiness mandates, is forcing organizations to produce evidence they cannot currently generate.
In each of these scenarios, the enterprises that survive without disruption are the ones with a unified, automated certificate lifecycle layer. Vault, by itself, is half of that picture. CertSecure Manager is the other half.
Encryption Consulting’s role in this is not just to deploy software. Our consultants design the Vault topology, build the integration, calibrate the templates against the client’s actual issuance patterns, train the platform and security teams, and stay engaged through the operational handover. The integration is the means; the outcome is a certificate program the enterprise can actually defend.
How Encryption Consulting Can Help?
Bringing Vault-issued certificates under enterprise control is rarely a tooling problem alone; it is a topology, policy, and operations problem. Encryption Consulting pairs the CertSecure Manager platform with a hands-on advisory engagement that takes the integration from concept to a certificate program the enterprise can defend.
- Assessment and discovery: We start by mapping your existing Vault footprint, every cluster, every PKI mount, every role, alongside your ADCS and public-CA estate, so you have a complete, deduplicated picture of where certificates are issued and where they are actually deployed.
- Topology and template design: Our consultants design the Vault topology, rationalise overlapping roles, and calibrate CertSecure Manager templates against your real issuance patterns, aligning every Vault role with your enterprise certificate policy.
- Integration and automation: We stand up the AppRole-based integration, wire renewal orchestration to the right deployment connectors (F5, IIS, NGINX, Kubernetes, Azure Key Vault, and beyond), and configure policy-driven approval workflows above Vault.
- Enablement and handover: We train your platform and security teams, document the operating model, and stay engaged through the operational handover so the program runs cleanly long after go-live, and remains ready for shorter validity windows and post-quantum migration.
Whether your Vault deployment is greenfield or has already outgrown its initial scope, our PKI consulting team can scope an engagement that fits your environment. Reach out for a personalised demo or to discuss bringing your Vault-issued certificates into a unified, automated certificate lifecycle.
Conclusion
HashiCorp Vault is an outstanding certificate authority for cloud-native workloads. It is not, and was never designed to be, an enterprise certificate lifecycle management platform. The gap between those two things is where outages happen, where compliance findings get written, and where shadow certificate inventories quietly grow until someone is forced to deal with them.
CertSecure Manager closes that gap with a Vault integration that preserves everything the platform team values about Vault (speed, API-first issuance, native fit with cloud-native tooling) while wrapping it in the discovery, visibility, policy enforcement, renewal automation, and audit evidence the enterprise actually needs. Combined with Encryption Consulting’s PKI advisory engagement, the result is a Vault-backed certificate program that scales, audits cleanly, and survives the next certificate validity shortening without anyone losing a weekend.
If your Vault deployment has outgrown its initial scope, or if you are starting to feel the cost of fragmented certificate inventory across Vault and the rest of your CA estate, reach out for a personalized demo or contact our PKI consulting team to scope an engagement.
