Explaining Why Certificate Failures Are Still Taking Down Critical Systems

AppViewX CEO Dino DiMarino joins TechNadu to discuss one of the fastest-moving challenges in enterprise security: the rise of non-human identities and the rapid expansion of machine-to-machine communication.

DiMarino brings more than two decades of leadership across RSA, Mimecast, Snyk, and Qualys. He outlines the visibility and control gaps that plague certificate management in hybrid and multi-cloud environments and the path to crypto-agility as organizations prepare for post-quantum cryptography.

This conversation breaks down the root causes behind recurring PKI-related outages and what enterprises consistently get wrong. Finally, DiMarino examines how Kubernetes and containerized environments are reshaping certificate automation and security strategy.

Vishwa: How does AppViewX define “non-human identity” and why is it becoming a top priority now for security professionals?

Dino: When we talk about non-human identity, we’re referring to anything that authenticates and communicates in your environment that is a machine: TLS certificates, SSH keys, API keys, service accounts, workloads, containers, microservices, IoT devices, even code-signing certificates and bots. 

All of these are identities because they’re used to establish trust and authorize access between systems. What’s changed is the volume and criticality. In many enterprises, machine identities now outnumber human identities by more than 45 to 1, driven by cloud, containers, IoT, and now AI and automation.

These identities are often created programmatically, live much longer than they should, and are over-privileged and under-governed. That combination makes them one of the most attractive targets for attackers and a growing focus area for security leaders and boards.

At AppViewX, we see machine (aka non-human) identity as the connective tissue of modern digital infrastructure. If you don’t manage, orchestrate, and secure it with the same rigor as user identity, you’re effectively blind to a huge portion of your attack surface.

Vishwa: What is the biggest challenge enterprises face when managing their certificate lifecycle in hybrid cloud environments?

Dino: It’s fragmented visibility and control. Organizations have certificates coming from multiple Certificate Authorities (CAs), spread across on-prem data centers, multiple clouds, Kubernetes clusters, and SaaS platforms. Each environment has its own native tools, and those tools rarely give you an end-to-end view of all certificates and keys.

In practice, teams are still tracking certificates in spreadsheets or ticketing systems, while cloud services like AWS Certificate Manager only cover part of the footprint and don’t extend cleanly to multi-cloud or on-prem.That’s how you end up with “orphan” certificates on load balancers or internal apps that nobody owns, until they expire and take down a critical service.

Hybrid and multi-cloud certificate lifecycle management requires a centralized control plane: smart discovery to find everything, a single inventory, and policy-driven automation that can enroll, renew, and revoke certificates consistently regardless of where they live. That’s exactly the problem we built AVX ONE certificate lifecycle management (CLM) platform to solve.

Vishwa: How do you ensure crypto-agility in a world moving toward post-quantum cryptography?

Dino: Crypto-agility starts with knowing what you have. You can’t plan for post-quantum cryptography (PQC) without an accurate cryptographic bill of materials (CBOM), including which algorithms are currently in use, for which applications, and how long specific assets must remain protected by encryption. 

From there, you can prioritize long-lived and high-value data and systems, because those are most at risk from “harvest now, decrypt later” attacks.

From there, create a multi-year transition plan. That means testing PQC algorithms, working closely with vendors, and building crypto-resilience scorecards so you can measure progress across business units and infrastructure. 

As I’ve said elsewhere, organizations that don’t prepare for cryptographic change will experience vulnerabilities in their encryption systems; our strategy is to help customers get ahead of that curve, not react to it after the fact.

Vishwa: What is the single most common root cause of outages tied to Public Key Infrastructure (PKI) failures you see across your customers?

Dino: Almost every major PKI-related outage we see traces back to a certificate that wasn’t in any central inventory, was owned by a team that has since reorganized, or was manually installed years ago on an application, gateway, or load balancer. 

When that certificate expires, authentication fails, and suddenly a trading platform, healthcare portal, or customer-facing website goes dark.

The risk is only increasing. With TLS validity periods shrinking, organizations will face more frequent renewal cycles, and we expect high-profile outages to accelerate in the coming quarters. 

At the same time, certificate distrust events, like the recent issues involving Entrust and others, are forcing enterprises to replace large volumes of certificates on short timelines, magnifying the blast radius when visibility and automation are lacking. Underneath all of these symptoms is the same root cause: no unified discovery, no automated renewals, and no clear ownership. 

Once customers move to automated certificate lifecycle management, with full discovery, inventory, and policy-driven renewal, those “mystery” certificates disappear, and the outage pattern changes dramatically.

Vishwa: How should organisations treat machine identities differently from human identities in their security strategy?

Dino: There are common principles, least privilege, strong authentication, continuous verification, but the operating model is very different. Machine identities operate at a completely different scale and pace. You might have tens of thousands of human users, but millions of certificates, keys, and service accounts. 

Many of these are short-lived or ephemeral, created and destroyed by automation in CI/CD pipelines and Kubernetes clusters. Trying to manage them with traditional IAM processes designed for human users doesn’t work.

So, organizations should treat machine identity as its own discipline with dedicated tooling and automation, tightly integrated with PKI, DevOps, and cloud platforms. Policies should be expressed as code, defining which workloads can get which certificates, with what algorithms and lifetimes, and enforced automatically at issuance time. 

At the same time, you need a unified view that links human and machine identities so Zero Trust policies are consistent across both.

Vishwa: In your view, what is the key benefit of automating certificate and SSH-key lifecycle versus manual processes?

Dino: The biggest benefit is business and security risk reduction at scale. Manual processes don’t just consume time; they introduce human error and make it impossible to keep up with shrinking certificate lifetimes and growing machine identity footprints. With 47-day TLS validity on the horizon, manual renewal simply does not scale.

Automation changes the equation. When discovery, issuance, renewal, and revocation of certificates and SSH keys are centrally automated, you dramatically reduce outages, close security gaps from weak or stale keys, and enforce consistent policies across teams and environments. 

Customers routinely see certificate creation and renewal times drop from hours to minutes, with clear audit trails that satisfy compliance.

It also frees up highly skilled security and operations staff from repetitive ticket work so they can focus on higher-value tasks, like improving architectures, strengthening policies, and preparing for the post-quantum transition.

Vishwa: How does AppViewX approach cloud-native environments (containers/ Kubernetes) differently for certificate management?

Dino: Kubernetes and containerized environments require a different approach because identities are highly dynamic. Pods are created and destroyed constantly, services are re-deployed multiple times a day, and mTLS between microservices is becoming the norm. In that world, certificates are not a static asset; they are part of the application fabric.

Our AVX ONE platform for Kubernetes provides centralized discovery, automation, and control of certificates and keys across clusters, but does so in a way that fits native DevOps workflows. 

We integrate with Kubernetes-native components like ingress controllers, service meshes, and cert-management operators, so developers can request and receive certificates programmatically while security teams define and enforce the policies behind the scenes.

The goal is to bring security up to DevOps speed: give platform and application teams self-service capabilities and GitOps-friendly APIs, while ensuring every certificate in those clusters is compliant, rotated on time, and visible to security. That’s how you keep cloud-native environments both agile and resilient.