TL;DR: The CA/B Forum has approved a phased reduction in public SSL/TLS certificate validity to 47 days by 2029, with DCV reuse shrinking to 10 days by 2028, according to GlobalSign. The shift makes manual certificate handling increasingly untenable and turns automation, inventory, and lifecycle governance into core identity controls.
Editorial analysis by NHI Mgmt Group, based on content published by GlobalSign: “Vorbereitung auf die Zeit der 47-tägigen Gültigkeit von SSL/TLS-Zertifikaten Ein Leitfaden mit Fragen und Antworten für Unternehmen”.
By the numbers:
- DCV reuse will shrink to 10 days by March 2028.
- A 398-day certificate issued before 15 March 2026 can still be trusted until it naturally expires.
Key questions
Q: What breaks when certificate lifetimes shrink to 47 days?
A: Manual certificate processes break first, followed by renewal consistency, deployment timing, and outage tolerance.
Q: Why does shorter SSL/TLS certificate validity reduce security risk for digital trust systems?
A: Shorter validity reduces the window in which a stolen or compromised private key can be abused.
Q: What are the signs that certificate lifecycle processes are not working properly?
A: Common warning signs include delayed renewals, unnoticed expirations, inconsistent revocation, slow onboarding for new users or devices, and poor visibility into certificate status.
Practitioner guidance
- Map every certificate to an owner and service Build a current inventory that ties each public and internal certificate to a named service, team, and renewal path.
- Automate renewal and deployment workflows Use ACME where it fits, but extend automation to renewal triggers, installation, validation, and rollback so expiry does not depend on a human calendar reminder.
- Set policy for DCV reuse and validation cadence Align governance rules to the shortened DCV reuse window so domain ownership checks are repeated on schedule and exceptions are explicit.
Bottom line: Certificate policy changes are compressing the trust window around public SSL/TLS certificates, which makes lifecycle visibility a governance requirement rather than a technical preference.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
47-day certificates turn certificate lifecycle into identity governance: the core issue is not simply shorter validity, but the collapse of any operating model that treats certificates as infrequent maintenance objects. Once renewal windows compress, inventory accuracy, ownership, and revocation discipline become the control plane. Organisations that still manage certificates as ad hoc infrastructure will find that trust now depends on machine identity governance.
A question worth separating out:
Q: How should security teams govern IoT device certificates at scale?
A: Security teams should govern IoT device certificates with a single lifecycle process for issuance, renewal, revocation, and retirement. The practical test is whether every device identity is visible enough to be renewed before expiry and revoked when the device leaves service. If not, certificate management has become an uptime risk as well as a security risk.
👉 Read our full editorial: Certificate lifetimes are shrinking to 47 days: IAM implications