Trust Lifecycle Manager 03-03-2026

Inside Customer Zero: Building Trust Ops for the 47-Day Era

Jeremy Rowley
Customer Zero Blog Hero

DigiCert occupies a unique position in the trust ecosystem. We don’t just help shape the standards that govern public trust; we also live by them.

As the industry pivots toward a 47-day TLS certificate lifecycle, this dual role carries a clear responsibility. It's not enough to guide customers through the change—we must prove the approach within our own environment.

This commitment led to the launch of Customer Zero—an internal initiative to modernize our own infrastructure using DigiCert Trust Lifecycle Manager (TLM) before asking anyone else to do the same.

This two-part blog series shares how we strengthened our systems to meet the rising demands of digital trust—along with the lessons we learned that help our customers accelerate their own modernization journeys.

The inherited reality: Organic growth doesn’t scale

Before Customer Zero, our certificate environment reflected the complexity common to large, growing enterprise organizations—including certificate authorities (CA).

Certificate management had evolved across teams over time. Inventory was maintained through a combination of tools, scripts, spreadsheets, and multiple CertCentral accounts. Ownership models existed, though visibility and consistency varied across groups.

As part of our modernization effort, we conducted a comprehensive discovery process across the environment. That exercise confirmed what many large organizations experience: Managing certificates across multiple use cases, teams, and systems becomes increasingly difficult without centralized visibility, clear ownership, and automation.

This structure was a natural outcome of growth. However, as certificate lifecycles shorten and operational demands rise, distributed management of certificates becomes harder to sustain. Modernization was the logical next step to ensure scalability, consistency, and resilience.

A single control plane by design

Our first architectural decision was simple in theory but rigorous in execution: establish one authoritative system of record.

We consolidated all certificate activity into a single TLM tenant. To maintain agility, we mapped teams into distinct business units, preserving their autonomy while enforcing centralized policy and reporting. Our guiding blueprint was explicit:

Inventory → Policy → Automation → Observability

We followed this sequence strictly. We knew that automation without clean inventory is just noise, and policy without ownership is just friction. We had to fix the foundation first.

Why inventory was harder than automation

Discovery revealed the "ghosts" in our machine: duplicates, revoked certificates still showing as issued, and expired artifacts lingering on endpoints with no identifiable owner.

Our sensors were effective—at times, too effective. The same certificate would appear across multiple systems, triggering conflicting renewal notices and "escalation exhaustion."

Cleaning this up required a level of tagging discipline usually reserved for a CMDB. We realized that inventory quality dictates automation quality. If your metadata is flawed, your automation will misroute, renew incorrectly, or fail silently. Until ownership was explicit, we could not safely accelerate our renewal cadence.

Automation: The divide between scale and drag

With a stable inventory, we moved to a protocol-first automation strategy, prioritizing:

  • ACME for web servers and modern platforms

  • SCEP and EST for device identity

  • Connectors and APIs for endpoints that couldn’t run agents

The results were binary. Approximately 50% of our systems supported ACME immediately, and another 40% handled SCEP or EST. For these, the shift was seamless; once configured, renewal became a "background" activity.

The remaining 10% became our primary friction points. These systems—constrained by legacy vendors—required custom scripting or manual coordination. At a one-year certificate lifetime, this overhead is a nuisance. At a 47-day cadence, the work multiplies eightfold. Anything that doesn't support a standard protocol like ACME creates a permanent, compounding operational drag.

Lessons from the friction zone

Customer Zero exposed the "last mile" issues that architecture diagrams often ignore:

  • Rate limiting: API thresholds that were fine at 398 days became breaking points at 47.

  • Silent stalls: Automation jobs would enter "pending" states without a clear failure signal.

  • Notification fatigue: High volumes of alerts masked critical issues.

We learned that automation components (sensors, connectors, and agents) can’t be treated as "set and forget"—they’re production dependencies. We had to build operational signals around sensor health and renewal success rates. Shorter lifetimes drastically reduce the window to fix a "stalled" renewal. If a process hangs for three days during a one-year cycle, you have time. At 47 days, that same delay creates an outage.

From operational heroics to discipline

The most profound shift was cultural. Historically, in the world of one-year certificates, a looming expiration could be "saved" by a heroic, last-minute intervention from a senior engineer. It was stressful, but it worked.

At a 47-day cadence, the "Hero Model" collapses. You can’t ask your team to perform "once-a-year" heroics eight times more often. It leads to burnout, human error, and eventually, a catastrophic outage. To survive the 47-day era, we had to replace individual heroics with institutional standards:

  • Forced standardization: Moving all public certificates to 47-day validity to eliminate "special cases"

  • Modernization by default: Mandatory TLS 1.3 enablement across all endpoints

  • Policy-driven issuance: Using TLM as the strict, single gateway for every certificate issued

We stopped treating renewals as emergency projects and started treating them as a routine utility.

The new operating model that emerged

Rebuilding our internal certificate operations forced structural changes, not incremental ones. Renewal moved from a high-stakes event to a continuous, background process. Ownership became explicit and enforced through policy. Automation was standardized around protocol-first methods. Connectors and agents were treated as production infrastructure, with monitoring and health signals aligned to our operational review cycles.

Across DigiCert’s production environment, more than 99% of eligible certificates now renew through automation. Manual intervention is rare and usually tied to third-party system limitations rather than internal gaps. As renewal frequency increases, outcomes remain consistent. That consistency is what allows a 47-day cadence to function without increasing operational volatility.

Stay tuned for part two, where we’ll dive into the business value of Customer Zero—exploring how this transformation drove measurable ROI, radical risk reduction, and the true cost of automation in the 47-day era.

Subscribe to the blog