By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: GlobalSignPublished August 15, 2025

TL;DR: Certificate Transparency turns certificate issuance into a public, auditable record, allowing domain owners and CAs to detect misissued SSL/TLS certificates faster and meet browser policy requirements, according to GlobalSign. For identity and access teams, the shift matters because certificate governance is part of non-human identity control, not just PKI administration.


At a glance

What this is: Certificate Transparency is an open framework for monitoring SSL/TLS certificate issuance and detecting misissued certificates before they become a user-facing trust problem.

Why it matters: It matters because certificate visibility, revocation speed, and issuance oversight are foundational controls for NHI, workload identity, and broader identity governance.

By the numbers:

👉 Read GlobalSign's explanation of Certificate Transparency and SSL governance


Context

Certificate Transparency is a public logging model for SSL/TLS issuance that changes certificate trust from a closed process to an observable one. In practice, it gives domain owners, CAs, and browsers a way to see whether a certificate was issued when, where, and for whom, instead of relying only on the CA process.

For identity and access practitioners, the governance lesson is broader than web PKI. Certificates are non-human credentials, and the same visibility problem appears in service accounts, API keys, workload identities, and other machine identities when ownership, inventory, and revocation are weak. CT is a useful reminder that trust depends on auditability, not just issuance.

The article’s starting point is typical of the period when browser policy changes forced certificate governance teams to look at public transparency as an operational requirement rather than an optional control.


Key questions

Q: What breaks when certificate transparency is not enforced for a domain?

A: Without Certificate Transparency, a domain owner can miss misissued or unauthorised certificates until they appear in production, which increases the window for impersonation or interception. The failure is not only technical. It is also governance related, because the organisation loses timely evidence that a certificate was created, logged, and exposed for review.

Q: Why do certificates create governance issues for non-human identities?

A: Because certificates are often attached to devices, servers, APIs, and service accounts that do not behave like people. Those identities can outlive their intended use, accumulate privilege, and remain difficult to track unless lifecycle controls and ownership are explicit. The governance problem is not the certificate itself, but the unmanaged identity it represents.

Q: How do security teams know if certificate lifecycle management is working?

A: Certificate lifecycle management is working when every certificate has a clear owner, renewal is automated or tightly managed, and expiry cannot occur without escalation. Teams should also verify that dependent controls keep operating during renewal events. If certificates still depend on ad hoc admin tracking, the process is not mature enough.

Q: Who should be accountable when certificate abuse leads to domain compromise?

A: Accountability should sit with the teams that govern identity trust, template policy, and privileged enrolment, not only with Windows administrators. AD CS compromise is an identity governance failure because it converts a certificate decision into domain-level authority.


Technical breakdown

How certificate transparency logs enforce public issuance visibility

Certificate Transparency uses append-only logs, so once a certificate or precertificate is recorded, it cannot be quietly removed or altered. Logs issue signed certificate timestamps, or SCTs, that prove the certificate was submitted. Browsers use SCT presence as evidence that a certificate has been publicly logged. This matters because it shifts issuance assurance from private CA records to an independently verifiable trail. The model does not stop a CA from making a mistake, but it narrows the window in which an unlogged certificate can remain hidden.

Practical implication: Practitioners should treat log coverage and SCT delivery as governance controls, not optional browser compatibility settings.

Precertificates, SCT delivery, and browser trust enforcement

A precertificate is a certificate-shaped object that includes a poison extension, making it unusable while still allowing the CA to obtain SCTs before final issuance. Those SCTs can then be embedded in the final certificate, sent through the TLS handshake, or stapled through OCSP responses. Each method has different operational trade-offs. Embedded SCTs are the most reliable because they travel with the certificate itself, while TLS and OCSP delivery depend on server configuration and runtime behaviour. Browser policy then determines whether the certificate is trusted.

Practical implication: Teams should align certificate issuance workflows with the SCT delivery method their browsers and server stack can actually sustain.

Why certificate transparency matters to NHI governance and workload identity

Although the article is about SSL certificates, the governance pattern maps directly to non-human identity management. Certificates are machine credentials with lifecycle, ownership, and revocation requirements, just like keys and tokens. Without inventory and public visibility, organisations struggle to detect misissuance, expired credentials, and unauthorised trust relationships. That is why CT sits alongside the broader shift toward workload identity governance, where the key question is not only whether a credential exists, but whether it can be observed, audited, and revoked before it becomes a trust gap.

Practical implication: Identity teams should fold certificate telemetry into their NHI inventory, ownership, and lifecycle controls.


Threat narrative

Attacker objective: The attacker objective is to establish a trusted certificate path that can impersonate a legitimate domain or support covert traffic interception.

  1. Entry occurs when a certificate is issued without proper oversight or for a domain the owner did not authorise.
  2. Escalation happens when the certificate is trusted by browsers or downstream systems before the misissuance is detected.
  3. Impact follows when users are exposed to deceptive or malicious TLS trust relationships that can enable impersonation or interception.

NHI Mgmt Group analysis

Certificate transparency is a governance control, not just a browser requirement. The article shows that public logging exists because closed certificate issuance processes were too easy to misread, mis-handle, or exploit. For identity programmes, that is the same structural problem seen in machine identity sprawl: if a credential cannot be inventoried and audited, it cannot be governed with confidence. The practitioner conclusion is that certificate lifecycle management belongs inside identity governance, not beside it.

Public visibility changes the risk model for non-human credentials. Certificate Transparency compresses the time between issuance and detection, which is exactly what machine identity programmes need when credentials can be created at scale. That aligns with the broader NHI problem that 96% of organisations store secrets outside secrets managers in vulnerable locations, making issuance and oversight inseparable from access control. The field should treat visibility as a prerequisite for revocation discipline, not a reporting feature. The practitioner conclusion is to govern credentials by observability first.

Certificate governance now sits at the intersection of PKI, workload identity, and browser trust. The article’s focus on SCT delivery, precertificates, and browser enforcement shows how identity assurance is increasingly distributed across systems rather than enforced in one control plane. This is where the named concept of issuance visibility gap applies: organisations often know a credential exists only after it becomes operational. The practitioner conclusion is to collapse the gap between issuance, logging, and revocation into one accountable process.

Browser policy pressure often reveals weak internal ownership before it reveals technical weakness. Google’s deadline is not the real story. The real story is whether the organisation can prove who owns certificate issuance, who monitors it, and who acts when a certificate appears unexpectedly. That is the same accountability issue that appears in machine identity management, where ownership gaps and manual tracking drive exposure. The practitioner conclusion is to assign explicit ownership for certificate monitoring and revocation.

CT is a template for how the market should think about machine identity trust. The direction of travel is toward logged, observable, short-lived, and policy-bound credentials across both human and non-human systems. That does not eliminate trust failures, but it makes them easier to detect, investigate, and constrain. The practitioner conclusion is to expect certificate governance and NHI governance to converge on the same lifecycle disciplines.

What this signals

issuance visibility gap: certificate governance teams should expect browser policy, logging requirements, and automation pipelines to converge into a single operational control plane. The organisations that struggle most are usually the ones treating certificates as a procurement or web operations problem instead of a lifecycle and ownership problem. That is the same pattern seen in broader non-human identity governance, where hidden credentials create hidden risk.

The practical signal for security leaders is that certificate transparency is becoming a model for other machine identity controls. If your programme cannot tell you who owns a certificate, where it was issued, and whether it was logged, it will struggle with similar questions for service accounts, API keys, and workload identities. The direction of travel is toward evidence-based identity operations, not periodic review.

For teams building identity controls across human and machine estates, the key metric is shrinking the time between creation, visibility, and removal. That is where policy, monitoring, and revocation need to meet. The stronger programmes will use certificate governance as the test case for broader NHI lifecycle discipline.


For practitioners

  • Inventory certificate issuance paths Map every CA, registration authority, automation flow, and server-side process that can produce SSL/TLS certificates for your domains, including third-party teams and delegated environments. Tie each path to an owner and a monitoring control so unexpected issuance is visible quickly.
  • Verify SCT delivery across all certificate profiles Test whether embedded SCTs, TLS extensions, or OCSP stapling are actually present in the certificate types you issue and the browsers you support. Do not assume a policy-compliant certificate is trustworthy if the delivery path fails in production.
  • Fold certificate visibility into NHI governance Treat certificates as machine identities with lifecycle state, ownership, revocation responsibility, and audit evidence. Connect certificate monitoring to your broader inventory of service accounts, API keys, and workload identities so the organisation is not managing non-human credentials in separate silos.
  • Set alerting for unexpected or duplicate domain certificates Alert on certificates issued for domains that are not in the approved portfolio, especially where business units, subsidiaries, or external providers can influence issuance. Use monitoring to catch misissuance before browser trust decisions expose users to the problem.

Key takeaways

  • Certificate Transparency turns SSL/TLS issuance into an auditable trust process rather than a hidden CA event.
  • The operational lesson for identity teams is that certificates behave like non-human credentials and need ownership, inventory, and revocation controls.
  • Browser enforcement will keep exposing weak certificate lifecycle governance, so monitoring and SCT validation should be treated as core controls.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01CT supports visibility and governance for machine credentials.
NIST CSF 2.0PR.AC-1Certificate trust and issuance visibility map to access control governance.
NIST SP 800-53 Rev 5IA-5IA-5 governs authenticator management, which includes certificate lifecycle discipline.
MITRE ATT&CKTA0006 , Credential Access; TA0010 , ExfiltrationMisissued certificates can support credential abuse and covert access patterns.

Tie certificate monitoring to your NHI inventory and ownership model so issuance can be audited end to end.


Key terms

  • Certificate Transparency: Certificate Transparency is a public logging system for certificates issued by major certificate authorities. It helps investigators link public keys to issued certificates, but it is a discovery layer, not a remediation control, and it does not revoke compromised material by itself.
  • Signed Certificate Timestamp: A Signed Certificate Timestamp is proof that a certificate or precertificate has been submitted to a Certificate Transparency log. Browsers use it as evidence that the certificate was publicly recorded, which helps enforce trust policy and reduces the chance of hidden misissuance.
  • Precertificate: A precertificate is a temporary certificate form used to obtain Certificate Transparency logging before final issuance. It contains the same core certificate data as the final certificate but includes a poison extension so it cannot be used as a real trust credential.
  • Machine Identity: A machine identity is a non-human credential such as a certificate, key, token, or service account used by software, workloads, or automated systems. It needs the same governance disciplines as human identity, including ownership, inventory, lifecycle control, and revocation evidence.

What's in the full article

GlobalSign's full post covers the operational detail this post intentionally leaves for the source:

  • How SCTs are embedded in certificates versus delivered through TLS or OCSP stapling.
  • The practical differences between precertificates and final certificates in the CT workflow.
  • The browser policy logic behind CT compliance deadlines and trust decisions.
  • The server configuration changes needed to support SCT delivery reliably.

👉 GlobalSign's full post covers SCT delivery methods, precertificates, and browser policy details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a shared framework for lifecycle control across human and non-human identities.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org