Certificate Lifecycle Management needs a dedicated monitoring platform

Last updated: January 2026

Certificate monitoring, as a product category, has always been a challenging market. In part because a lot of this type of functionality ends up being embedded in network monitoring tools, and in part because companies often have someone on staff who will write a quick script or two and call the job done. Or at least, that's the intention.

In practice, these approaches never end up working well, even if they solve some of the needs. The root cause is the fact that certificate monitoring is one of those problems that look easy when you're on the outside; but there's nothing easy when it comes to Public Key Infrastructures (PKIs), and most organisations learn and re-learn this as they play with their scripts.

Red Sift provides a dedicated platform for certificate monitoring and we're often asked to explain what our product can do better than the status quo. The aim of this blog post is to discuss the state of the art of certificate monitoring so that it becomes more clear how much effort goes into designing a good product.

Certificate monitoring is often considered as part of the Certificate Lifecycle Management (CLM) category, which has seen a rise of popularity in recent years. CLM tools are designed for certificate orchestration. Vendors who have such products will also claim monitoring capabilities, but, in my experience, they too leave a lot to be desired. It's counterintuitive, but you'd expect CLM tools to have good certificate monitoring capabilities, right?

In the CLM case, the root cause is the fact that the primary purpose of these tools is to manage certificates. That's not an easy job because there is a great deal of diversity out there in terms of products consuming certificates. CLM developers are spending most of their time implementing automation integrations, which leaves them less time to focus on monitoring, which often ends up being tacked-on on the main product.

In practice, CLMs may provide visibility into the certificates under their control, but these are just a fraction of all certificates used by an organization.

The dream of CLM is that you deploy one product that gives you full control over all your certificates. In practice, that's very difficult to achieve. One reason is that automation requires integration with many different platforms, and no CLM can claim support for everything. A small company may end up with a single CLM that's just right, but a larger company will inevitably have multiple CLMs, either because they are needed for their best features (e.g., integration with a particular important private PKI) or because of mergers and acquisitions. To that you can add CDNs and outsourced servers. And you add ACME, which is now provided by default in many situations, and which is too expensive at scale to connect to a CLM, even when it's supported.

As a result, you end up having multiple CLMs and multiple ACME deployments, but you're still not closer to having full visibility and unified monitoring. If anything, multiple CLMs make this more difficult.

Our approach is to provide a dedicated certificate monitoring platform, where we spend our development time on being very good at our core feature set. What does that look like? Well, consider the following broad aspects:

• Automated infrastructure discovery and deep infrastructure monitoring; these aspects are needed to avoid relying on manual work, which is time-consuming and limited in what it can produce. We have a separate blog post with more information on this topic.
• Certificate Transparency monitoring for comprehensive visibility of all issued certificates, covering existing certificates as well as new issuances in real time. More details in this earlier blog post.
• Cryptography and PKI as core competencies, which ensures support for key protocols and their configuration, aimed at building a cryptographic inventory. With so much change in this space, just keeping up requires significant development time, for functionality exactly in our main scope.
• DevOps tools for ad-hoc inspection and advice around a variety of configuration options, including TLS, PKI, HSTS, CAA, DNSSEC, DANE, and others.

Our point here is not to list a bunch of features, but to highlight how a good tool for this complex use case needs to be designed and built from the ground up. For example, our discovery capabilities are focused on infrastructure first, and on top of that we add certificate discovery that works seamlessly across all CAs with no manual effort. We then layer on active network monitoring to be able to tell what's used and where, as well as discover third-party relationships.

What we hear from our customers is that they like our visibility, not only for the information it provides, but also as a way to understand their estates to be able to plan their other tasks such as procuring CLMs, deploying private PKIs, and assessing their automation and post-quantum readiness. It doesn't hurt that our platform is very easy to deploy and provides results quickly.