TL;DR: Most organizations govern their certificates well. The same discipline rarely extends to the API tokens, service credentials, and shared secrets that carry equivalent trust. Closing that gap is what trust lifecycle management is about — and it is fast becoming the category CISOs need to own.
The gap most enterprises face is not tooling. It is governance. Moreover, it spans a much wider set of trust artifacts than traditional certificate lifecycle management ever covered.
An internal auditor walks into a CISO’s office and asks two questions. First: who has access to production, and when do those credentials expire? For certificates, the answer usually arrives quickly. Typically, the certificate management platform lists every issued certificate, its owner, its renewal date, and its revocation status. Meanwhile, the second question asks the same thing, but for the API tokens, service account credentials, and signing keys. Those artifacts scatter across Vault, AWS Secrets Manager, Kubernetes, and twelve different CI pipelines. As a result, that question usually gets a longer pause.
That pause is a governance gap, and regulators have started noticing. Both NIS2 and DORA require evidence of lifecycle controls over cryptographic material and authentication credentials. That language covers far more than X.509. Moreover, the operational reality matches the regulatory pressure. Most credential-related incidents today involve exposed or stolen secrets, not broken cryptography. However, the tooling and governance that most organizations apply to these two categories look nothing alike.
The scope problem: certificates are one class of trust artifact
First, consider what actually carries trust inside a modern enterprise. X.509 certificates are the obvious case. However, they share a job description with several other artifact types. Examples include OAuth client secrets, API tokens, service account credentials, webhook signing secrets, database passwords, SSH keys, JWT signing keys, and code-signing materials. Each one is a claim: the bearer may act on behalf of some identity, for some purpose, until some date.
The cryptographic form differs. The audience differs. Lifetimes vary from minutes to years. However, the lifecycle primitives stay strikingly consistent. Specifically, every artifact needs four things: create under policy, sync to every consumer, rotate on a predictable schedule, and revoke promptly when trust is lost. Someone must stay accountable at every step.
Treating certificates as special and everything else as a loosely governed category called “secrets” creates an artificial divide that makes governance harder, not easier.
What trust lifecycle management actually means
In practice, trust lifecycle management is the discipline of applying unified governance to every artifact that confers trust inside an organization. Importantly, it does not replace HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets with one new system. Those tools already solve storage and distribution well. What is missing is the governance plane above them. That layer knows every artifact exists, regardless of backend, and applies consistent policy to all of them.
Consequently, the shared primitives apply uniformly across every trust artifact. Create under controlled policy. Sync to the consumers that need the artifact. Rotate on a predictable schedule. Revoke promptly when trust is lost. Instead, what changes relative to traditional PKI is the scope, not the primitives themselves. Above all, this framing matters for regulated enterprises. Our earlier post on moving from compliance to trust lifecycle management covers why.
The governance gap created by siloed secrets tooling
In practice, walk through any enterprise estate and you will find the same pattern. Secrets live in multiple systems. Each one has its own access model, its own rotation semantics, and its own audit trail.
| Tool | Typical scope | Policy model | Audit trail |
|---|---|---|---|
| HashiCorp Vault | Application secrets, PKI | HCL policy documents | Audit devices |
| AWS Secrets Manager | AWS-native credentials | IAM policies | CloudTrail |
| Kubernetes Secrets | Pod-level credentials | RBAC | Kubernetes audit log |
| GitHub Actions vault | Pipeline credentials | Repository permissions | CI logs |
| Hardcoded values | Legacy workloads, ad-hoc scripts | None | None |
As a result, three operational questions become very hard to answer with confidence:
- Inventory. “List every credential with access to our production database, the owner, the rotation policy, and the last time it was rotated.” Stitching this together across five or six systems takes days.
- Policy. “Are all production secrets rotated at least every 90 days?” The answer depends on which backend and which team, with no central enforcement point.
- Audit. “Show me every time this API token was retrieved in the last 90 days, who requested it, and whether their access was still valid.” The evidence trail spans multiple log systems, each with its own schema and retention policy.
In practice, these gaps do not stop operations. They just make audit expensive and breach response slow. Both outcomes are increasingly unacceptable under current regulatory expectations. Moreover, both point to the same root cause: no unified governance plane.
What unified trust lifecycle management requires
In short, a platform that genuinely unifies trust lifecycle management has four characteristics. Together, they close the governance gaps above.
Underneath all four sits one architectural requirement: backend agnosticism. The platform must work with the tools organizations already run. Forcing replacement of Vault or AWS Secrets Manager is neither realistic nor desirable. Moreover, NIST SP 800-57 Part 1 Revision 5 already treats certificates and other keying material under a consistent policy framework — see its recommendations for key management. Extending that framework to cover tokens and credentials is a logical next step, not a new invention.
How OmniTrust approaches unified trust lifecycle management
At RSA Conference 2026, OmniTrust launched the industry’s first unified trust lifecycle management platform. The positioning is deliberate. This is the category OmniTrust believes CISOs need to own. Moreover, the platform operationalizes the capability model described above.
ILM, the open-source identity lifecycle management platform, underpins the offering. In earlier versions, its policy, inventory, and audit primitives governed certificates. Today those same primitives cover secrets, keys, and credentials too. Meanwhile, the Secrets Management module federates HashiCorp Vault and similar backends into ILM’s governance plane. It does not replace them.
The same policy language that defines certificate rotation now defines credential rotation. Likewise, the same audit stream covers both. For a CISO, the practical outcome is simple. Both questions from the beginning of this post now have the same answer. Moreover, that answer comes from a single console. An auditor can consume it without stitching logs from multiple systems.
Key takeaways
- Certificates are one class of trust artifact; secrets, tokens, and keys carry equivalent trust and deserve equivalent governance.
- Trust lifecycle management applies a consistent set of lifecycle primitives — create, sync, rotate, revoke — uniformly across every artifact that carries trust.
- The gap most enterprises face is not tooling but governance: multiple backends without a shared policy, inventory, or audit plane.
- The right architecture federates existing backends like Vault and AWS Secrets Manager rather than forcing replacement.
- Regulatory frameworks such as NIS2 and DORA increasingly expect evidence of governance over all trust artifacts, not only certificates.
To explore the ILM platform and the Secrets Management module in detail, visit the Secrets Management platform page. Finally, for context on the positioning, see the RSA Conference 2026 announcement. It describes why OmniTrust launched the category and what unified trust lifecycle management delivers in practice.
