Certificate Transparency logs are updated in near real-time: a newly issued certificate from a major CA typically becomes searchable within 1 to 5 minutes — sometimes in as little as 10 to 30 seconds — while the standard guarantees permanent inclusion only within the Maximum Merge Delay of 24 hours. The gap between "seconds" and "24 hours" is not a contradiction; it reflects two different moments in the CT pipeline. When a Certificate Authority submits a certificate, the log instantly returns a Signed Certificate Timestamp (SCT) — a cryptographic promise to include it. The certificate is then merged into the log's tamper-evident Merkle tree later, and every log commits to doing so before its MMD deadline. In practice, well-run logs merge in minutes; the 24-hour figure is a ceiling for outages and spikes, not the number you should plan around.
That's the summary an AI Overview gives you. Here's what it can't show you: where the time actually goes across the five stages of the pipeline, why your search tool can lag the log itself, and how to pick a monitoring cadence that matches your threat model. The animated timeline below traces a single certificate from issuance to searchability, and the tables that follow turn "near real-time" into concrete numbers per log operator.
Try our free Certificate Transparency Lookup to see the latest certificates in CT logs for any domain right now.
The Short Answer: Near Real-Time Updates
Certificate Transparency logs are updated in near real-time. When a Certificate Authority issues a new SSL/TLS certificate, it is logged within seconds to minutes. This rapid update cycle is a fundamental design feature of the CT ecosystem, enabling timely detection of certificate issuance.
However, the complete picture is more nuanced, involving several technical processes and timing considerations that security professionals should understand.
The Certificate Transparency Logging Process
To understand update frequency, it's helpful to know the complete CT logging process and where time is consumed:
Step 1: Certificate Issuance (Milliseconds)
When a Certificate Authority receives a certificate request that passes validation, they generate the certificate. This process typically takes milliseconds from a technical standpoint (though validation itself may take longer).
Step 2: CT Log Submission (Seconds)
Immediately after certificate generation, the CA must submit the certificate (or precertificate) to one or more CT logs. This submission happens in real-time as part of the certificate issuance workflow.
Timeline: Certificate is submitted to CT logs within seconds of generation.
Step 3: Log Acceptance and SCT Issuance (Milliseconds to Seconds)
The CT log server receives the submission, validates the certificate format, adds it to a pending queue, and returns a Signed Certificate Timestamp (SCT). The SCT is a cryptographic promise that the certificate will be added to the log within a specified Maximum Merge Delay (MMD).
Timeline: SCT is issued within milliseconds to a few seconds of submission.
Key Point: The SCT is returned immediately, but the certificate isn't yet permanently merged into the log's Merkle tree.
Step 4: Merging into the Merkle Tree (Up to 24 Hours)
After issuing the SCT, the log operator must permanently merge the certificate into the log's cryptographically-assured Merkle tree structure within the Maximum Merge Delay. RFC 6962 introduced the MMD as a per-log parameter, and operators have effectively standardized on 24 hours. RFC 9162 (CT version 2.0) keeps MMD configurable rather than mandating a lower ceiling — 24 hours remains the near-universal value — but modern log infrastructure merges far faster in practice, usually within minutes.
Timeline: Certificate must be permanently merged within 24 hours of SCT issuance.
Practical Reality: Most major CT logs merge certificates much faster than the maximum allowed time—typically within minutes to an hour.
Step 5: Availability in Public Queries (Minutes)
Once merged into the Merkle tree, the certificate becomes discoverable through CT log APIs and search tools. The indexing process for search interfaces may add a small additional delay.
Timeline: Certificates typically become searchable within minutes to an hour of issuance.
Maximum Merge Delay: The Technical Standard
The Maximum Merge Delay (MMD) is a critical CT log parameter that defines how quickly certificates must be permanently added to the log:
| Standard | MMD treatment | What it means in practice |
|---|---|---|
| RFC 6962 (original) | Introduces MMD as a per-log parameter; operators set 24h | The 24-hour figure you see quoted everywhere is convention, not a hard-coded constant |
| RFC 9162 (CT v2.0) | MMD stays configurable; no mandated reduction | 24h is still the ceiling; the standard leans on operators to merge faster voluntarily |
While the technical standard allows up to 24 hours, this is a maximum limit, not typical behavior.
Why 24 Hours?: The MMD exists to accommodate unexpected issues:
- High volume spikes
- Technical problems
- Maintenance windows
- Geographic distribution delays
In normal operation, logs perform much better than the maximum allowed delay.
Real-World Update Frequency: What to Expect
Based on monitoring major CT logs, here's what security professionals can expect in practice:
For Major Certificate Authorities
Certificates from major CAs (Let's Encrypt, DigiCert, Sectigo, etc.) appear in CT logs:
- Fastest observed: 10-30 seconds
- Typical: 1-5 minutes
- Maximum: Within 24 hours (MMD compliance)
For Different Log Operators
Different CT log operators have different performance characteristics:
| Log operator | Example log families | Typical merge delay | Notes |
|---|---|---|---|
| Argon, Xenon | 1–3 min | Very fast merging, high uptime; historically the reference for CT reliability | |
| Cloudflare | Nimbus | 2–5 min | Global anycast infrastructure, good geographic distribution |
| DigiCert | Yeti, Nessie | 2–5 min | Consistent, enterprise-focused reliability |
| Let's Encrypt | Oak | 1–5 min | Optimized for extreme automated volume (millions of certs/week) |
| Sectigo | Sabre, Mammoth | 2–5 min | Widely trusted, broad browser acceptance |
Note that log families rotate: operators shard logs by certificate expiry year (e.g., "Xenon 2026," "Oak 2026h1"), retiring old shards and standing up new ones. Monitoring systems should track the currently accepting logs rather than hard-coding names.
Factors Affecting Update Speed
Several factors influence how quickly certificates appear in CT logs:
Log Volume and Load
CT logs processing high volumes of certificates may experience slightly longer delays during peak times. Let's Encrypt, for example, issues millions of certificates weekly, requiring robust infrastructure to maintain fast merging.
Geographic Distribution
CT logs are often geographically distributed with multiple servers. The distance between the CA submitting the certificate and the nearest log server can introduce network latency, though this is typically negligible (milliseconds to seconds).
Log Operator Infrastructure
Different log operators have different infrastructure capabilities. Well-resourced operators with modern infrastructure generally provide faster merging times.
Certificate Type
Domain Validated (DV) Certificates: Fastest processing—automated validation and immediate logging.
Organization Validated (OV) Certificates: May involve slightly more processing, though CT logging itself is the same speed.
Extended Validation (EV) Certificates: Similar to OV—validation takes longer, but once issued, CT logging occurs at the same speed.
Precertificates vs. Final Certificates
Modern CT implementations log precertificates, which are logged before the final certificate is issued. This means the CT entry may appear before the certificate is delivered to the requestor—enabling even earlier detection.
Implications for Security Monitoring
The near real-time nature of CT logs has significant implications for security monitoring:
Rapid Threat Detection
Phishing Campaigns: When attackers register a phishing domain and obtain a certificate, you can potentially detect it before they finish building the phishing site or sending emails.
Unauthorized Certificates: Detect mis-issued or unauthorized certificates for your domains within minutes, enabling rapid response.
Time Window: The detection window is often measured in minutes to hours, not days or weeks.
Monitoring Frequency Recommendations
Based on CT log update frequency, here are recommended monitoring intervals for different use cases:
| Cadence | Method | Best for (which should I use?) | Effective response time |
|---|---|---|---|
| Continuous | Real-time streaming (CertStream / native log tailing) | Major brands, banks, high-profile phishing targets | Minutes |
| Hourly | Scheduled API polling of logs/aggregators | Standard corporate monitoring and brand protection | Hours |
| Daily | Once-per-day batch check | Certificate inventory, compliance auditing | ~24 hours |
| Weekly/Monthly | Manual review | Small orgs, low-threat environments | Days to weeks |
Rule of thumb: since well-run logs merge in minutes, the bottleneck on your detection speed is almost always your polling interval, not the log. Only step up to continuous streaming when minutes actually matter for your response playbook — otherwise hourly polling captures nearly the same threats with a fraction of the alert noise.
Alert Fatigue Considerations
While near real-time monitoring is technically possible, it's important to balance detection speed with alert fatigue:
Real-Time Streaming: Can generate high alert volumes for organizations with frequent legitimate certificate issuance. Requires sophisticated filtering and risk scoring.
Batch Processing: Hourly or daily checks provide a reasonable balance between timely detection and manageable alert volumes.
Risk-Based Alerting: Only alert on high-risk indicators (typosquatting, suspicious patterns) rather than all certificate issuance.
Technical Approaches to Real-Time Monitoring
Security teams can implement CT log monitoring at different levels of sophistication:
1. Periodic API Polling
The simplest approach involves regularly querying CT log APIs or aggregators:
Advantages:
- Easy to implement
- Low infrastructure requirements
- Predictable alert volumes
Disadvantages:
- Detection delay equal to polling interval
- May miss rapid-fire attacks
Best For: Small to medium organizations with standard monitoring needs
2. CertStream Real-Time Streaming
CertStream is an open-source project that provides a real-time stream of CT log updates:
Advantages:
- True real-time detection
- No polling delay
- Single WebSocket connection
Disadvantages:
- Requires constant connection
- High volume requiring filtering
- More complex infrastructure
Best For: Organizations requiring fastest possible detection, security researchers
3. CT Log Native Streaming
Directly connecting to CT log streaming APIs:
Advantages:
- Most direct approach
- Full control over filtering
- Can query specific logs
Disadvantages:
- Most complex implementation
- Requires understanding CT log protocols
- Need to handle multiple logs
Best For: Large enterprises, security vendors, advanced threat intelligence
4. Commercial CT Monitoring Services
Managed services providing CT monitoring and alerting:
Advantages:
- No infrastructure management
- Pre-built analytics and filtering
- Expert threat analysis
Disadvantages:
- Ongoing costs
- Less customization
- Vendor dependency
Best For: Organizations without dedicated security engineering resources
Building an Effective Monitoring Strategy
To leverage CT log update frequency effectively:
1. Define Monitoring Objectives
What are you trying to detect?
- Unauthorized certificates for your domains
- Phishing domains targeting your brand
- Shadow IT certificate issuance
- Competitor intelligence
How quickly do you need to know?
- Minutes: Real-time streaming required
- Hours: Hourly polling sufficient
- Days: Daily batch processing acceptable
2. Establish Baselines
Before implementing alerting, establish baselines:
- How many certificates are issued for your domains daily?
- Which CAs do you use?
- What's your typical certificate lifecycle?
- Which naming conventions do you use?
This baseline helps filter out legitimate activity and focus on anomalies.
3. Implement Tiered Alerting
Create different alert levels based on risk and frequency:
Immediate Alerts (respond within minutes):
- Typosquatted domains with high similarity scores
- Unauthorized CAs issuing for your exact domains
- Known phishing patterns
Priority Alerts (respond within hours):
- Suspicious domain patterns
- Unusual certificate characteristics
- First-time certificate issuance for your domains
Informational Alerts (review daily/weekly):
- All certificates for your domains
- Brand name mentions in other domains
- Certificate expiration notifications
4. Automate Response Where Possible
For highest-priority threats, consider automated responses:
- Automatic ticket creation
- Notifications to security teams
- Triggering of investigation workflows
- Integration with takedown services (for confirmed threats)
5. Regular Refinement
CT monitoring requires ongoing refinement:
- Review false positive rates monthly
- Adjust detection rules based on new attack patterns
- Update domain lists as your infrastructure evolves
- Incorporate lessons learned from incidents
Log Availability and Reliability
CT logs are designed for high availability, but it's important to understand reliability:
Multiple Logs for Redundancy
Browsers require certificates to be logged in multiple CT logs (typically 2-3 depending on certificate lifetime). This redundancy ensures that even if one log has issues, the certificate still achieves CT compliance.
Security Benefit: You can query multiple logs to ensure comprehensive coverage. If one log is delayed, others may already have the certificate.
Log Monitoring Status
CT log operators publish status pages and performance metrics. Major logs maintain 99.9%+ uptime with minimal disruption to certificate processing.
Best Practice: Monitor multiple CT logs rather than relying on a single source.
Log Retirement and Evolution
CT logs occasionally retire (reach maximum capacity) and new logs are introduced. The ecosystem is designed to handle this gracefully, but monitoring systems should track which logs are active and adjust accordingly.
Future Trends in CT Log Updates
The CT ecosystem continues to evolve:
Faster MMDs: Discussion of reducing Maximum Merge Delay below 24 hours as infrastructure improves.
Better Streaming APIs: Enhanced APIs for real-time monitoring with improved filtering capabilities.
Machine Learning Integration: AI-powered analysis of CT log streams for anomaly detection.
Standardized Alerting: Industry standards for CT log alert formats and interoperability.
Conclusion
Certificate Transparency logs provide near real-time visibility into certificate issuance, with typical update times of 1-5 minutes and a guaranteed maximum of 24 hours. This rapid update frequency enables organizations to detect unauthorized certificates and phishing threats within the critical window where preventive action is possible.
The key to effective CT log monitoring isn't just understanding update frequency—it's implementing appropriate monitoring strategies that match your security needs and risk profile. Whether you choose real-time streaming for critical assets or daily batch checks for routine monitoring, the rapid update cycle of CT logs provides the visibility needed for proactive security.
For security teams, the near real-time nature of CT logs represents a shift from reactive incident response to proactive threat detection. By monitoring certificates as they're issued—not after they're used in attacks—organizations can stay ahead of threats and maintain better control over their certificate landscape.
Ready to start monitoring certificates in near real-time? Use our free Certificate Transparency Lookup tool to discover current certificates for any domain and understand what's visible in CT logs right now.