Notifications
Clear all
Topic starter
25/06/2026 10:34 pm
TL;DR: Google’s CT2 log retirement does not affect DigiCert certificates because issued certificates are posted across multiple, segmented logs, while the CT2 key exposure was limited to one log’s infrastructure, according to DigiCert. The event underscores that certificate transparency depends on resilient log diversity and operational separation, not a single trusted path.
NHIMG editorial — based on content published by DigiCert: Moving forward: What DigiCert’s CT2 log retirement means for you
By the numbers:
- 66% say their current tooling is not adequate to manage the scale of machine identities they now have.
- Only 38% have automated certificate lifecycle management in place.
Questions worth separating out
Q: How should teams govern certificate transparency when a log is retired?
A: Teams should treat log retirement as a governance event, not a routine maintenance item.
Q: What breaks when certificate transparency depends on one logging path?
A: What breaks is resilience.
Q: Why do PKI teams need lifecycle governance for transparency logs?
A: Because logs change over time even when certificates continue to function.
Practitioner guidance
- Map certificate transparency dependencies end to end Inventory which certificates rely on which CT logs, which monitoring tools watch them, and where any shared infrastructure creates a common failure domain.
- Separate issuance, logging, and monitoring ownership Assign different operational owners to CA issuance, log operations, and alerting so one team can validate another’s assumptions.
- Refresh certificate lifecycle runbooks before log changes Update runbooks to show which certificates need reposting, which logs remain trusted, and how to confirm SCT evidence after a retirement notice.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- The exact CT2 deprecation timeline and the read-only to retirement sequence for certificate transparency operations.
- DigiCert’s explanation of why existing certificates continue to work and which SCT handling conditions matter after the change.
- The infrastructure separation details behind CT1, Yeti, Nessie, and the core CA systems.
- The company’s stated rationale for moving issued certificates toward newer CT logs and modernised PKI operations.
👉 Read DigiCert’s explanation of the CT2 log retirement and certificate transparency impact →
CT2 log retirement and certificate transparency resilience: what changes?
Explore further
25/06/2026 11:09 pm
CT2 retirement shows that certificate transparency is a resilience problem, not just a logging problem. The control only works when the ecosystem can lose one log without losing the ability to verify certificate issuance. That shifts the practitioner question from whether a log exists to whether trust evidence survives infrastructure change. The implication is that certificate transparency should be governed as a distributed assurance model, not a single platform dependency.
A few things that frame the scale:
- Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
- Certificate expiry is the leading cause of outages for 45% of organisations, according to The Critical Gaps in Machine Identity Management report.
A question worth separating out:
Q: Who is accountable when certificate transparency monitoring misses a retired log?
A: Accountability sits with the teams that own PKI governance, log monitoring, and certificate lifecycle controls. The issue is not only whether a log was retired, but whether the organisation updated its assurance model in time. Frameworks such as the NIST Cybersecurity Framework 2.0 support this kind of shared operational responsibility.
👉 Read our full editorial: CT2 log retirement shows why certificate transparency needs resilience
