Certificate lifecycle operations need a 47-day trust model

At a glance

What this is: DigiCert’s Customer Zero programme shows how certificate operations shift when TLS lifecycles shorten to 47 days, with automation and observability becoming the controlling factors.

Why it matters: This matters because certificate lifecycle failure now behaves like an identity governance problem, affecting NHI, workload identity, and adjacent human access programmes that depend on trusted infrastructure.

By the numbers:

• 99% of eligible certificates now renew through automation, automation across DigiCert’s production environment.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read DigiCert's Customer Zero blog on the 47-day trust lifecycle

Context

The 47-day TLS certificate lifecycle turns certificate management into a continuous trust governance problem rather than a periodic renewal task. In practice, that means inventory quality, ownership, automation, and monitoring determine whether the programme scales or becomes a recurring outage risk across identity and workload environments.

DigiCert’s Customer Zero story is less about product adoption than about operating-model change. For IAM, NHI, and trust teams, the useful question is how certificate lifecycle controls behave when manual renewal is no longer an acceptable fallback and the same discipline has to apply across infrastructure, services, and machine identities.

This is a familiar pattern in mature identity programmes: once the validity window compresses, exceptions become the failure point. The organisations that survive the shift are the ones that treat certificates as governed identities with explicit ownership, telemetry, and lifecycle enforcement.

Key questions

Q: How should teams govern certificate lifecycles when renewal windows shrink to 47 days?

A: Teams should move certificate governance into a continuous operating model with authoritative inventory, explicit ownership, and automated renewal paths. The key is to reduce exception handling before the expiry window matters. If a renewal process still depends on manual rescue, the lifecycle is too brittle for a short-lived trust model.

Q: Why do short-lived certificates expose weaknesses in identity and access programmes?

A: Short-lived certificates expose the same control failures that appear in NHI governance: poor ownership, duplicate records, stale entitlements, and weak observability. When the lifecycle compresses, those issues surface faster and with less room for remediation. That makes certificate management a governance problem, not just a technical maintenance task.

Q: What breaks when certificate automation depends on custom scripts and legacy systems?

A: Custom scripts and legacy-only dependencies create renewal drag, inconsistent error handling, and delayed failure detection. They can work at longer intervals, but they become unreliable when renewal cadence tightens. The practical failure mode is not just missed renewal. It is silent drift between what the system believes is valid and what the endpoint actually trusts.

Q: Who should be accountable when certificate renewal fails in production?

A: Accountability should sit with the teams that own the inventory, renewal policy, and operational telemetry, not with whoever notices expiry first. Governance frameworks such as NIST Cybersecurity Framework 2.0 and zero-trust models expect explicit control ownership. If no team owns the trust lifecycle end to end, the programme is relying on luck.

Technical breakdown

Why short certificate lifecycles expose inventory debt

A shortened TLS lifecycle compresses every weakness in certificate inventory. When certificates are tracked in spreadsheets, scripts, multiple consoles, or inconsistent ownership records, renewal logic cannot reliably distinguish live assets from revoked, duplicate, or orphaned ones. That creates conflicting alerts, failed renewals, and blind spots that look like automation problems but are really data-quality problems. The deeper issue is that lifecycle management depends on an authoritative system of record before any renewal workflow can be trusted.

Practical implication: Practitioners need a single source of truth for certificate ownership before they increase renewal cadence.

Protocol-first automation for certificate renewal

Automation at 47 days only works when the renewal path is protocol-led rather than custom-script-led. Standards such as ACME, SCEP, EST, and API-based connectors reduce the amount of manual intervention needed across server, device, and endpoint estates. Where those standards are absent, renewal work becomes brittle and scale-dependent, because each special case adds configuration drift, extra coordination, and delayed failure detection. In identity terms, the automation layer is only as strong as the protocols it can enforce consistently.

Practical implication: Teams should map certificate populations to supported renewal protocols and isolate the legacy tail that still needs bespoke handling.

Observability is now part of certificate governance

Short-lived certificates do not just require faster issuance. They require operational signals that show whether discovery, renewal, and endpoint deployment are all succeeding in time to matter. Stalls that were tolerable in a one-year cycle become outages in a 47-day cycle, especially when rate limits, pending states, or notification fatigue hide the problem until expiry. At that point, certificate management is no longer a back-office function. It is a production control plane with service-level consequences.

Practical implication: Security and platform teams should monitor renewal success, stalled jobs, and sensor health as first-class governance metrics.

NHI Mgmt Group analysis

Certificate lifecycle management has crossed from administration into identity governance. A 47-day certificate model leaves no room for informal ownership or ad hoc renewal habits. Once validity windows shrink, certificate control becomes a question of policy enforcement, authoritative inventory, and operational accountability. Practitioners should treat certificates as governed identities, not as background configuration.

Inventory quality is the real control plane behind renewal automation. The article shows that duplicates, revoked artefacts, and unowned certificates create the conditions for renewal failure long before any protocol is invoked. That makes inventory debt the dominant operational risk in compressed lifecycles. The practitioner takeaway is that automation cannot outrun bad discovery data.

Protocol standardisation now determines whether certificate operations can scale at all. ACME, SCEP, EST, and API-driven connectors turn renewal into a repeatable control, while legacy-only systems turn it into compounding drag. This is not a tooling preference. It is a governance boundary around what can be managed safely at 47 days. Teams should classify legacy exceptions as structural risk, not temporary inconvenience.

47-day operations expose the limits of the hero model. The article’s strongest insight is cultural: once renewal frequency increases, emergency intervention becomes an operating anti-pattern. Human rescue cannot be the default recovery mechanism when the cycle repeats every few weeks. Security leaders should replace exception-driven trust operations with standards-driven lifecycle discipline.

Lifecycle compression debt: the shorter the trust window, the less value manual exception handling delivers and the more every unresolved ownership gap compounds. That concept explains why certificate programmes fail when renewal cadence outpaces governance maturity. The implication for practitioners is that compressed lifecycles punish anything not already visible, owned, and automated.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
• For the governance pattern behind this article, see NHI Lifecycle Management Guide for a practical lifecycle-oriented view of ownership, rotation, and offboarding.

What this signals

Lifecycle compression changes the programme shape. Once trust assets expire in weeks instead of months, certificate operations start to resemble NHI governance: ownership, rotation discipline, and visibility become the decisive controls. Teams that still treat certificates as periodic maintenance will struggle to keep pace with the operational rhythm of modern trust.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations, the broader identity lesson is that unmanaged trust objects rarely fail in isolation, and certificate estates are no exception.

The next maturity step is not more manual review. It is a control model that links inventory, policy, and renewal telemetry so the trust lifecycle can be governed as a production dependency.

For practitioners

• Consolidate certificate inventory into one authoritative system of record Map every certificate, owner, business unit, and renewal path into a single control plane before shortening validity windows. Remove duplicate records, revoked artefacts, and unowned entries so automation can make clean decisions.
• Standardise renewal paths by protocol support Use ACME where possible, then separate SCEP, EST, and API-managed populations from the legacy tail that still depends on scripts or manual coordination. Treat unsupported systems as exceptions that need a remediation plan, not a permanent operating model.
• Instrument renewal operations like production services Track renewal success rate, stalled jobs, sensor health, and notification fatigue as operational metrics. Escalate failures before expiry, not after, and make pending states visible in the same review cycle used for other production controls.
• Retire hero-based recovery as a primary control Replace last-minute manual rescue with policy-driven issuance, explicit ownership, and automated rollback paths for failed renewals. If a certificate can only be saved by a senior engineer, the lifecycle model is already too fragile.

Key takeaways

• A 47-day certificate model turns renewal into continuous identity governance, not a periodic administrative task.
• Inventory errors, duplicate records, and unowned certificates become the primary failure modes once renewal windows compress.
• Teams that want to scale certificate trust need a single control plane, protocol-first automation, and production-grade observability.

Key terms

• Certificate Lifecycle Management: Certificate lifecycle management is the governed process of issuing, tracking, renewing, and revoking certificates across an environment. In modern programmes, it is an identity control because trust depends on knowing what is valid, who owns it, and whether renewal and revocation happen before exposure.
• Authoritative System Of Record: An authoritative system of record is the single place where ownership and status are treated as the source of truth. For certificates, it prevents duplicate, stale, or orphaned entries from driving renewal decisions and gives automation a reliable foundation.
• Protocol-First Automation: Protocol-first automation uses standard renewal and issuance methods before custom scripts or manual workarounds. It matters because protocols create repeatable control, while bespoke handling increases drift, delays, and the risk that a trust object expires without a clear failure signal.
• Renewal Observability: Renewal observability is the ability to see whether trust assets are discovered, renewed, and deployed successfully in time to remain valid. It extends beyond logging by making stalled workflows, sensor health, and operational latency visible enough for governance decisions.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity strategy or security operations, it is worth exploring.

This post draws on content published by DigiCert: Inside Customer Zero: Building Trust Ops for the 47-Day Era. Read the original.