CMDB as an Orchestration Platform: Keeping PKI and Certificates Under Control

In many organizations, CMDBs primarily serve as passive inventories, providing an overview of which assets exist within a given environment. While useful for documentation purposes, this limited role falls short in the context of modern security requirements.

To become truly effective, CMDBs must evolve beyond static asset lists. They need to act as active orchestration layers—capable of managing asset lifecycles and enabling automated integration with PKI systems. Achieving this, however, requires a closer look at both their current capabilities and their inherent limitations.

Complexity in OT Environments

The challenges are particularly pronounced in operational technology (OT) environments.

OT assets—such as programmable logic controllers (PLCs), gateways, and industrial control systems—typically remain in use for ten to twenty years. As a result, their corresponding entries in CMDBs are often outdated or incomplete. In addition, the required metadata varies significantly depending on the type of asset, further complicating standardization.

Another key factor is the prevalence of legacy systems. Many OT devices do not support modern security protocols, including those required for PKI-based identity management. Consequently, CMDB adoption in OT environments is often limited or inconsistent.

Limited Visibility Across the Purdue Model

The limitations of CMDBs become particularly evident when viewed through the lens of the Purdue Model, which structures industrial networks into hierarchical levels.

While traditional IT CMDBs typically cover assets up to Level 3—such as manufacturing execution systems or OT servers—they rarely extend into the lower levels. Devices such as PLCs, sensors, and fieldbus components are often either abstracted or entirely absent.

This lack of visibility is not merely a documentation issue. It introduces tangible security risks. Assets that are no longer actively managed but remain operational may still possess valid certificates, credentials, or access rights. Without proper tracking, these assets can become unnoticed entry points for attackers.

From Documentation to Orchestration

Transforming a CMDB into an orchestration layer fundamentally changes its role.

Instead of merely recording changes, the CMDB can actively trigger processes based on lifecycle events. For example, when a new asset is deployed, a corresponding digital certificate can be automatically requested and installed. Similarly, when an asset is decommissioned, its certificate can be revoked without manual intervention.

More advanced use cases include the synchronization of identity records or the automatic updating of PKI metadata when asset attributes—such as hostname or ownership—change.

Through this approach, the CMDB becomes a central coordination point for digital identities. Certificates are directly linked to assets, and lifecycle events are consistently enforced across systems. While this does not eliminate complexity entirely, it significantly reduces it by aligning asset and certificate lifecycles.

The Role of PKI and CLM

Such an approach depends on a robust integration with PKI and certificate lifecycle management.

In modern environments, digital certificates are used extensively—for securing communications via TLS, enabling device authentication, ensuring data integrity through signatures, and supporting code signing. Managing these certificates manually is no longer viable, particularly in environments with large numbers of assets.

CLM solutions address this challenge by automating certificate issuance, renewal, and revocation. However, when deployed in isolation, they lack the contextual information required for effective management. This can result in certificates existing without corresponding assets—or assets lacking valid certificates altogether.

Integrating CLM with a CMDB resolves this issue by providing a shared data foundation. The CMDB supplies the necessary context, while CLM enables automation.

From Manual Processes to Automation

Without integration, certificate management processes remain largely manual.

Administrators must regularly monitor certificate validity, often across multiple tools, and initiate renewal processes themselves. This may involve coordination across teams, manual installation of certificates, and subsequent validation—an approach that is both time-consuming and error-prone.

By contrast, an integrated CMDB and PKI/CLM architecture enables end-to-end automation.

Certificate metadata, including expiration dates, is stored directly alongside asset data in the CMDB. When a certificate approaches expiration, the CMDB can automatically trigger a renewal workflow. A certificate signing request (CSR) is generated, submitted to the appropriate certificate authority, and the newly issued certificate is deployed without manual intervention.

If maintenance windows are defined within the CMDB, these processes can be scheduled accordingly, minimizing the risk of disruption.

Benefits and Practical Limitations

Ideally, every active asset is associated with a managed digital certificate, and every certificate can be clearly assigned to a specific asset or service. This creates transparency across digital identities and ensures consistent management.

The benefits are clear:

• Reduced risk of human error
• Elimination of outages caused by expired certificates
• Improved compliance with standards such as NIS2, IEC 62443, or BaFin
  

At the same time, several challenges must be addressed. Data quality remains a critical factor. Automation is only as reliable as the underlying CMDB data. Inaccurate or incomplete records can undermine the entire system.

Legacy OT devices present another limitation, as many do not support certificate-based security. In such cases, intermediary systems or gateways may be required to extend certificate functionality.

Clear governance is equally important. Responsibilities for asset lifecycle data—whether within IT, OT, or security teams—must be defined in advance. Without this, automation processes are unlikely to remain sustainable.

Finally, integrating CMDB and CLM systems via APIs can be complex and resource-intensive. Careful planning and alignment with existing infrastructure are essential.

Conclusion: From Inventory to Orchestration

By integrating CMDB data with PKI and CLM platforms, organizations can move beyond static asset inventories toward a more dynamic and automated approach to identity management.

Each asset is assigned a digital identity, and certificate lifecycles are managed consistently and automatically. This reduces operational risk, minimizes manual effort, and provides measurable improvements in resilience.

In OT environments, the impact is particularly significant. A CMDB functioning as an orchestration layer can help reduce unplanned downtime, enable secure remote access, and improve overall operational stability—especially in environments with a high proportion of legacy systems.