DigiCert Partner Subscriptions API and the move to 47-day TLS

At a glance

What this is: This is a partner-channel update on DigiCert's Partner Subscriptions API and ACME delivery model for shorter TLS lifecycles, with the central finding that 47-day certificate renewal cycles will make manual administration unsustainable.

Why it matters: It matters because certificate ownership, renewal orchestration, and customer support patterns are becoming governance issues for teams responsible for workload identity, PKI, and service availability, not just procurement or support tasks.

By the numbers:

• TLS certificate lifecycles will drop from 200 days today to 47 days in early 2029.

Context

TLS lifecycle shortening is a certificate governance problem, not just a procurement change. When renewal windows compress, the operational burden shifts from occasional issuance to continuous administration across customers, partners, and automation tooling.

For identity and infrastructure teams, the issue sits in the certificate lifecycle: who owns renewal, how ACME is configured, and how customer-facing workflows absorb the change without creating outages. The article's starting position is typical for the market, because most environments still rely on manual or semi-manual certificate handling.

DigiCert's model shows how partner channels are adapting to a shorter renewal cadence by moving certificate delivery into recurring subscriptions and automation workflows. That does not remove governance responsibility; it redistributes it across the partner, customer, and certificate authority relationship.

Key questions

Q: How should teams prepare certificate operations for 47-day TLS lifecycles?

A: Teams should move from periodic renewal handling to always-on certificate lifecycle governance. That means automated issuance, clear ownership for entitlement changes, and direct visibility into ACME-driven renewal paths. Manual processes that worked for annual certificates will not scale when validity windows shrink and customer expectations shift toward uninterrupted service.

Q: Why do manual certificate processes create more risk as lifespans shorten?

A: Manual processes create risk because the control window collapses faster than human teams can reliably track. When certificates expire every few weeks instead of every few months, even small delays can break authentication, trigger outages, and weaken audit evidence. Automation is the only scalable way to keep lifecycle events aligned with operational reality.

Q: What breaks when certificate issuance is not automated with ACME?

A: What breaks is the assumption that humans can reliably process renewals fast enough to avoid outages. Without ACME, certificate renewal becomes dependent on operator attention, ticket queues, and timing discipline that shorter lifecycles quickly outrun. That creates avoidable availability risk for domains and services that must stay current.

Q: Who should own certificate entitlement changes in a partner subscription model?

A: Ownership should sit with a clearly defined lifecycle authority that can approve creation, renewal, SAN changes, and cancellation. When those decisions are split across support, sales, and engineering, certificate scope becomes hard to audit and even harder to retire cleanly. Governance needs one accountable owner per entitlement.

How it works in practice

Why 47-day TLS changes certificate operations

Shorter TLS lifecycles compress the time available for issuance, installation, renewal, and troubleshooting. A 47-day certificate term reduces the margin for human handling errors and makes periodic renewal windows operationally brittle. In practice, the control problem is not certificate generation alone. It is the repeatability of the full lifecycle across domains, environments, and customer estates. Once renewals become frequent enough, manual steps stop being a control and become a failure point. That is why automation is not an optimisation layer here. It is the only way to preserve availability when certificates expire faster than teams can process exceptions.

Practical implication: Treat certificate lifecycle as an always-on operational process and remove any manual renewal path that cannot scale with shorter validity periods.

How the Partner Subscriptions API changes certificate governance

The Partner Subscriptions API separates management from issuance. The API handles subscription creation, renewal-related administration, account and subaccount handling, and contract management, while ACME performs automated issuance and renewal. That matters because it creates a clear governance boundary between partner orchestration and certificate delivery. The operational question for practitioners is no longer whether certificates can be bought or issued. It is who can create the entitlement, who can bind ACME to the domain, and how that relationship is tracked over time. The model also supports proration and SAN changes, which means entitlement scope itself becomes a lifecycle object.

Practical implication: Document ownership for subscription, ACME registration, and SAN change control so certificate scope cannot drift outside governed processes.

Why ACME becomes the only viable delivery path

ACME is the automation layer that makes short-lived TLS manageable at scale. In this model, the customer or partner configures an ACME client, and EAB credentials bind that client to the managed relationship. That design reduces human intervention but increases the importance of secure API key handling, contract endpoints, and enrollment controls. ACME is not just a convenience mechanism. It is the enforcement point where renewal becomes machine-driven rather than operator-driven. For identity teams, that changes the trust model around certificate issuance, because availability now depends on stable automation rather than individual certificate events.

Practical implication: Harden ACME enrollment and API credentials as lifecycle assets, because their compromise or misconfiguration affects every downstream certificate renewal.

NHI Mgmt Group analysis

Certificate renewal is becoming a lifecycle governance problem, not a ticketing problem. When certificate terms compress to 47 days, manual renewal turns into an unbounded operational burden. That changes the subject from occasional administration to continuous identity lifecycle control. Practitioners should treat certificate renewal as part of workload and service availability governance, not a back-office exception.

The real control boundary is shifting from certificate issuance to entitlement management. The article's subscription model shows that the business object is no longer a one-off certificate, but a named-domain entitlement with changing SAN scope and ACME binding. That means the governance question is who can create, modify, and terminate the certificate relationship, not just who can request a certificate. Lifecycle control moves upstream.

Long-lived certificate handling assumptions are collapsing under shorter TLS validity. The assumption that a certificate lasts long enough for humans to review, renew, and replace it on a schedule was designed for a slower operational tempo. That assumption fails when renewal becomes continuous and automation-driven because access to certificate issuance must persist as a governed machine process, not a sporadic human task. The implication is that certificate governance has to be designed for continuous operation.

Partner-led automation will increasingly shape how enterprises experience PKI governance. As more organizations consume certificates through service providers, the governance question extends beyond internal PKI teams. Partner workflows, customer self-service, ACME client configuration, and subscription entitlements all become part of the trust chain. Practitioners should re-evaluate whether their current operating model can distinguish authority, administration, and automation cleanly enough for short-lived TLS.

47-day TLS readiness: the market is moving toward certificate automation as the default control plane. That does not eliminate the need for oversight, but it does change what oversight must cover. Teams will need visibility into entitlement scope, renewal automation, and exception handling rather than relying on ad hoc renewal ceremonies. The practical conclusion is that certificate lifecycle governance now sits alongside IAM and workload identity operations.

What this signals

47-day TLS readiness: short-lived certificates force organisations to decide whether certificate handling belongs in support workflows or in governed automation. The distinction matters because renewal timing, not certificate volume, becomes the availability risk once validity windows compress.

Partner-led certificate delivery also pulls identity governance closer to operational IT. Subscription entitlements, ACME enrolment, and API credential handling now sit on the same path as certificate issuance, which means certificate management must be reviewed as a lifecycle control rather than a procurement afterthought.

For practitioners

• Map certificate ownership to a named lifecycle owner Assign a single accountable owner for certificate issuance, renewal, SAN changes, and retirement so responsibility does not fragment between partner, customer, and platform teams.
• Move renewals onto automated ACME workflows Use ACME-based renewal paths for customer domains where certificate validity is shortening, and eliminate renewal steps that depend on manual ticket handling.
• Review subscription and entitlement scope Track which domains, subaccounts, and contract terms are covered by each certificate entitlement so scope changes remain auditable during the subscription term.
• Secure API keys and EAB credentials Treat the credentials used to register and configure ACME relationships as high-value lifecycle secrets, with explicit storage, rotation, and revocation controls.

Key takeaways

• Shorter TLS lifecycles turn certificate renewal into a continuous operational discipline, and manual handling becomes progressively less defensible.
• The important shift is not just more issuance, but clearer governance over entitlements, ACME binding, and renewal ownership.
• Teams that cannot automate renewal and control entitlement scope will face higher outage risk as 47-day TLS becomes the norm.

Key terms

• Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
• ACME Automation: A protocol-driven method for issuing and renewing certificates without manual operator handling. It reduces renewal friction but increases the need to govern enrollment, credentials, and client bindings as controlled identity assets.
• Certificate Entitlement: The right to issue certificates for a specific domain or scope under a defined subscription or contract. It is a governance object because it determines who can request, renew, and modify certificate coverage over time.
• EAB Credentials: External Account Binding credentials link an ACME client to a managed certificate relationship. They are high-value secrets because they establish trust between automation tooling and the certificate authority, and must be handled with the same rigor as other lifecycle credentials.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.