Notifications
Clear all
Topic starter
25/06/2026 10:34 pm
TL;DR: Google’s requirement that EV certificates issued after 1 January 2015 include Certificate Transparency proofs changes how browsers validate public trust, and certificates without the required logged evidence will no longer show Chrome’s green address bar, according to DigiCert. The governance lesson is that certificate lifecycle controls now have to account for public logging, not just issuance and renewal.
NHIMG editorial — based on content published by DigiCert: Certificate Transparency Required for EV Certificates to Show Green Address Bar in Chrome
Questions worth separating out
A: Teams should treat Certificate Transparency as a mandatory lifecycle control, not an optional enhancement.
Q: Why do certificate lifecycle issues matter more when browsers enforce transparency logs?
A: Because the certificate can be valid cryptographically and still fail the browser trust test if it lacks the required transparency proof.
Q: What do security teams get wrong about EV certificate management?
A: They often focus on validity dates and renewal timing while ignoring the logging evidence that browsers now rely on.
Practitioner guidance
- Audit EV certificate inventories for CT readiness Classify each EV certificate as public or internal, then verify whether it can carry the required CT proofs before the next renewal cycle.
- Gate issuance on proof availability Require the CA or certificate workflow to confirm that the correct number of logged proofs is present for the certificate validity period before deployment to production.
- Separate browser trust from cryptographic validity Update runbooks so operations teams check both certificate chain validity and CT log evidence during acceptance, incident triage, and renewal review.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific Chrome policy change and the EV certificate timing rules that determine when CT proofs are required.
- The operational distinction between embedded CT proofs and OCSP stapled proofs for certificate deployment.
- The migration guidance for existing publicly accessible EV certificates versus internal or non-public certificates.
- The CA-side implementation details behind DigiCert's default CT handling for newly issued EV certificates.
👉 Read DigiCert's explanation of Chrome's certificate transparency requirement →
Certificate transparency for EV certificates in Chrome: what changes?
Explore further
25/06/2026 11:10 pm
Certificate Transparency turns certificate issuance into an auditable non-human identity control. The article shows that browser trust is no longer anchored only in possession of a valid EV certificate, but in whether that certificate has been logged and can be independently verified. That is a machine identity governance shift, because the lifecycle now includes public accountability as part of the trust decision. Practitioners should treat CT as an inventory and assurance control, not a browser-facing feature.
A few things that frame the scale:
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility, according to The Critical Gaps in Machine Identity Management report.
- 57% of organisations lack a complete inventory of their machine identities, which makes proof-based lifecycle governance harder to enforce.
A question worth separating out:
Q: Who is accountable when an EV certificate no longer shows the expected trust signal in Chrome?
A: Accountability should sit with the team that owns the certificate lifecycle, including issuance coordination, logging verification, and renewal oversight. Browser policy is external, but the operational failure is internal. In practice, PKI, web operations, and security governance must share a documented control owner.
👉 Read our full editorial: Certificate transparency for EV certificates: what Chrome changes mean
