TL;DR: Certificate transparency still leaves practical visibility gaps because CT is enforced by client behaviour, not the CA/Browser Forum baseline, and many non-browser clients ignore it, according to Red Sift. That means certificate misissuance can remain undetected unless teams monitor logs and use CAA to constrain issuance.
At a glance
What this is: Red Sift argues that certificate transparency is widely assumed to be mandatory, but it remains optional in practice and only protects organisations that actively monitor CT logs.
Why it matters: This matters because public PKI control is incomplete without log monitoring and issuance constraints, and identity and platform teams need to treat certificate visibility as an operational control rather than an assumed default.
Context
Certificate transparency is a control for public certificate issuance, not a guarantee of safety by itself. It creates a public record of certificates so organisations can detect unexpected issuance, but its value depends on monitoring, client enforcement, and how consistently the broader ecosystem supports it.
The governance gap is that many practitioners assume CT protects every certificate path, when in reality browser enforcement does most of the work and non-browser clients often do not participate. That leaves API traffic, server-to-server TLS, and other machine-facing use cases outside the strongest part of the control. For identity and PKI teams, the issue is not just certificate issuance, but who can observe and constrain it.
The article’s starting position is typical of modern public PKI estates: strong controls in one channel, partial or absent protection in others.
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 does certificate transparency still need monitoring if it already logs certificates?
A: Because logging creates visibility, not response. CT only helps when someone is actively searching for unexpected certificates and can investigate quickly when a new entry appears. Without monitoring, the log becomes historical evidence rather than an operational control, and misissued certificates can remain in circulation for long periods.
Q: How should teams reduce certificate issuance risk in public PKI?
A: Use CAA to restrict which certificate authorities are permitted to issue for your domains, and pair that with CT monitoring to detect anything that still slips through. The control combination matters because one reduces the issuance path while the other reveals exceptions and abuse after issuance.
Q: What is the difference between CT and CAA in certificate governance?
A: CT is a visibility control that makes issuance public and searchable, while CAA is an authorisation control that limits who may issue in the first place. They solve different governance problems, and organisations need both if they want to reduce unauthorised issuance and detect the cases that still occur.
Technical breakdown
Why certificate transparency depends on client enforcement
Certificate transparency works by requiring CAs to log issued certificates and by having clients reject certificates that lack sufficient proof of logging. That means CT is not only a CA-side process. Its security effect depends on whether the validating client actually checks for CT evidence. In browser ecosystems, enforcement is common. In many other TLS consumers, especially libraries used for service-to-service communication, that enforcement is absent, which removes the practical protection even when the certificate itself appears valid.
Practical implication: Treat CT as a conditional control and inventory which certificate consumers actually enforce it.
How misissuance becomes visible only if logs are monitored
CT exposes misissued certificates by placing them into public logs, where organisations can search for unexpected issuance against their own properties. But logging alone does not create security value unless someone watches those logs and can act on what appears there. That is why CT changes the detection model rather than the issuance model. It reduces concealment and increases accountability, but it does not stop a certificate from being issued in the first place.
Practical implication: Build monitoring and response around CT logs, not just issuance workflows.
Why CAA closes a different part of the control gap
Certification Authority Authorisation lets a domain owner publish policy that restricts which CAs may issue certificates for its names. Unlike CT, which is about visibility after issuance, CAA is about limiting who can issue in the first place. It is enforced by all CAs and can be scoped per CA account, which gives organisations a direct governance lever over issuance paths. The two controls are complementary: one constrains issuance, the other reveals what slipped through.
Practical implication: Use CAA to reduce unauthorised issuance paths and CT to detect what still gets through.
Threat narrative
Attacker objective: The objective is to impersonate a trusted property or intercept traffic while remaining hidden in plain sight.
- Entry occurs when an attacker or unauthorised issuer obtains a certificate for a domain or service they do not own.
- Escalation happens when that certificate is accepted by clients that do not enforce CT, allowing trusted-looking traffic interception or impersonation.
- Impact follows when the forged or misissued certificate is used for interception or spoofing without immediate detection.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CT visibility is not equivalent to CT control: the industry often treats certificate transparency as a universal safeguard, but enforcement is fragmented across clients and protocols. Browser ecosystems get the strongest protection, while API traffic and server-to-server TLS frequently do not. The practical conclusion is that public PKI governance still depends on where enforcement actually exists, not where policy language says it should.
Visibility without monitoring creates a false sense of coverage: CT logs only matter when somebody is watching them with an operational response path. That makes CT a detection and accountability control, not a prevention control. For identity and PKI governance, this is a familiar pattern: records are necessary, but they do not substitute for lifecycle oversight or actionability.
Issuance restriction belongs at the domain level, not just the certificate level: CAA gives organisations a way to control which CAs may issue for their names, which is the governance layer CT cannot provide. That distinction matters for public PKI estates where multiple issuance paths, subcontractors, and automation flows can all widen exposure. Practitioners should treat issuance policy and issuance observability as separate control objectives.
Machine-facing TLS is the weak point in the CT model: the article correctly highlights that non-browser clients often ignore CT, and that is where many identity-adjacent workloads live. API servers, SMTP, and other service-to-service channels are therefore not protected in the same way as browser endpoints. The broader lesson is that machine identity governance cannot assume protections designed for human web browsing will transfer cleanly to workload communications.
Transparency alone does not solve certificate supply-chain trust: the post-quantum transition and future certificate formats may change the mechanics, but not the governance problem. Organisations still need a durable way to prove who can issue, who can observe, and who responds when issuance goes wrong. That makes certificate lifecycle control a standing requirement, not a one-time hardening exercise.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
CT visibility gaps are really machine-identity governance gaps: the weak point is not the existence of logs, but the mismatch between public PKI assumptions and the clients that actually enforce them. When machine-facing TLS does not verify CT, the control degrades from prevention to after-the-fact detection, and that shifts the governance burden onto issuance policy and monitoring.
Certificate issuance needs two separate controls, not one: CT tells you what happened, while CAA limits who may make it happen. That separation matters for identity programmes because visibility, authorisation, and revocation are distinct governance tasks that should not be collapsed into a single certificate management workflow.
Only 5.7% of organisations have full visibility into their service accounts. The same pattern shows up here: once assets move out of browser-centric workflows and into service-to-service channels, visibility becomes the exception rather than the norm. The practical response is to inventory enforcement gaps and treat them as governance defects, not edge cases.
For practitioners
- Audit client-side CT enforcement Identify which browsers, SDKs, TLS libraries, and service-to-service clients actually enforce certificate transparency, then mark every non-enforcing path as a blind spot.
- Monitor CT logs for your properties Set up continuous alerting for unexpected certificates issued to your domains, subdomains, and IP addresses, with a clear escalation path for misissuance.
- Publish restrictive CAA records Use CAA to limit issuance to trusted certificate authorities and, where appropriate, specific CA accounts so unauthorised issuance paths are reduced.
- Verify CA logging commitments Ask each certificate authority for an explicit statement on whether it logs all issued certificates to CT, and document the answer in your PKI governance record.
Key takeaways
- Certificate transparency is useful, but it is not a universal safeguard because many clients do not enforce it outside browser environments.
- Misissued certificates can remain hidden until someone actively monitors CT logs and responds to what appears there.
- CAA and CT solve different parts of the problem, so public PKI governance needs both issuance restriction and log visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CSA Cloud Controls Matrix, NIST SP 800-57 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Public PKI issuance and CA authorisation are identity governance concerns in cloud-connected estates. |
| Recommendation — Apply IAM governance to restrict who can issue and validate certificates across your estate. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article addresses certificate issuance, logging, and lifecycle trust in public PKI. |
| Recommendation — Manage certificate lifecycle governance with explicit issuance, monitoring, and revocation controls. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Misissued certificates can enable trusted interception and movement across service channels. |
| Recommendation — Map certificate abuse scenarios to credential access and lateral movement detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CAA and issuance policy are authorisation controls over who may obtain certificates. |
| Recommendation — Use PR.AA-05 to formalise certificate issuance permissions and restrict authorised CAs. | ||
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.
- CAA: Certification Authority Authorisation is a DNS-based policy control that tells certificate authorities which issuers are allowed to issue certificates for a domain. It reduces unauthorised issuance by constraining the approval path before a certificate is created.
- Internal PKI: Internal PKI is the private certificate infrastructure an organisation uses for internal services, workloads, and trusted communications. It often carries more hidden dependency than public TLS because ownership, renewal paths, and exception handling may be less visible and less automated.
- Misissuance: Misissuance happens when a certificate is issued without proper validation of the requester’s authority over the domain. It is a trust failure in the issuance pipeline, and it can force revocation, distrust, or emergency replacement after the fact.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for teams that need stronger control over identity-bound infrastructure. It is designed for practitioners building governance across cloud, platform, and security programmes.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org