Detecting cert-issuance anomalies without making public claims about anyone.

Cert Activity Watch flags statistically anomalous certificate issuance velocity (≥3σ above baseline) on the domains a customer monitors. This page documents the baseline math, the threshold rationale, the false-positive sources we know about, and the editorial line that defines who gets notified — and who never does.

What this tool measures

Cert Activity Watch operates over Certificate Transparency (CT) log data, which is public. For each monitored domain it computes a rolling baseline of:

• Issuance velocity — number of new certificates issued for the apex + subdomains, per 7-day window.
• Issuer diversity — count of distinct CAs issuing across the trailing window.
• SAN expansion rate — new hostnames added per cert vs. typical.
• Key-rotation cadence — fraction of new certs using a new public key vs. reusing prior keys.

The "anomaly" event is a current-window measurement that exceeds 3 standard deviations above the trailing-90-day baseline on any of the four signals.

How we measure it

Our existing CT-log mining pipeline (used for key-reuse detection in the core scan) is reused. We monitor the major public CT logs (Google Argon/Xenon, Let's Encrypt Oak, Cloudflare Nimbus, DigiCert Yeti, Sectigo Mammoth) via certstream-style live ingestion and per-domain query.

For each monitored domain (apex), we maintain a per-day rolling counter table for ~90 days of history. The baseline (μ, σ) per signal is recomputed daily. A current-window anomaly fires when:

currentSignal_7d > μ + (3 × σ)

The 3σ threshold is the standard. Empirically we tune by signal type — issuance velocity uses 3σ, SAN expansion uses 2.5σ (lower variance baseline), key-rotation uses a categorical change-point detector rather than σ.

How it scores

Anomaly events are not scored continuously; they fire as discrete alerts. Each alert includes:

• Signal: which of the four was triggered.
• Magnitude: how many σ above baseline (e.g. "5.4σ — issuance velocity 18 vs. baseline μ=3.2, σ=2.7").
• Context: what changed in the cert pool (new issuer? new SAN pattern? sudden many short-lived certs?).
• Confidence band: high / medium / low based on signal magnitude + cross-correlation with other signals + presence of known-benign patterns.

The alert is delivered via the customer's chosen channel (email, signed webhook) within minutes of detection.

What this tool does NOT claim

• An anomaly is not a breach. 3σ above baseline is a statistical event. The most common cause of cert anomalies in our data is benign infrastructure work — not security incidents.
• An anomaly is not a public claim. Alerts are private to the asset owner. We do not publish "alerts fired this week" lists, even anonymized to date but identifiable in retrospect.
• An anomaly score is not a prediction. We do not compute a "this domain is likely to be breached" probability. Cert Activity Watch is descriptive, not predictive.
• An anomaly is not actor attribution. The signal does not identify who issued the certs or why; it only flags that the issuance pattern changed.
• An anomaly does not require a response. Alerts are informational; many will resolve as known-benign on customer review (planned migration, scheduled rotation, etc.).

Known false-positive sources

Cert anomalies frequently arise from non-incident causes. Customers should expect — and Cipherwake alerts are calibrated to — the following benign sources:

• Infrastructure migration. Moving services across CDNs, cloud providers, or load balancers reissues certs in bursts.
• M&A integration. Acquisition activity often consolidates or fragments cert estate over weeks.
• Cert-lifetime policy compression. The industry shift toward 47-day certs (2026-2029) increases all baselines; a single policy change at one CA can trip anomalies for that CA's customers.
• Staging / preview-environment rollouts. Vercel, Netlify, and similar PaaS routinely create per-PR certs.
• ACME automation deployment. First rollout of automated cert lifecycle frequently generates a one-time burst.
• CT-log policy changes. Issuers occasionally change which CT logs they submit to, creating apparent volume changes that are actually visibility artifacts.

Customer-side review is the gating step. We surface signal; we do not adjudicate cause.

Permitted use cases

1. Self-monitoring. A team monitoring its own domains for unauthorized cert activity (a classic ATT&CK T1553.004 indicator).
2. Vendor-portfolio monitoring. Monitoring a list of vendor domains for anomalous activity that may inform vendor-risk posture.
3. M&A diligence. Monitoring a target's cert estate during diligence + integration windows.
4. Incident-response support. Cross-checking cert activity against known incident timelines for the customer's own assets.

Disallowed use cases

• Adversarial monitoring of competitors with intent to publish — refused. Customer agreements explicitly prohibit publication of Cipherwake-derived signal about third parties.
• Pre-disclosure trading signal — refused. We will refuse a customer who appears to be using anomaly alerts as a market-timing input on public companies they don't own.
• Bulk monitoring of unrelated domains — abuse risk. Volume caps + portfolio-coherence checks at signup.

Limitations + edge cases

• Cold-start window. A newly-monitored domain has 0 baseline; we require ~30 days of CT history before firing the first alert.
• Sparse baselines. Domains with very few historical certs have noisy σ estimates; we widen thresholds (4σ instead of 3σ) until baseline mass exceeds a floor.
• CT-log coverage. If a CA submits to a log we don't ingest, we will miss issuance events. We cover the major public logs but not exhaustively all logs.
• Wildcard SAN ambiguity. A wildcard cert covers an unbounded subdomain set; "SAN expansion" signal may understate true coverage.

Try it

• Single-domain free preview: scan any domain on cipherwake.io — current cert state appears in the report (no monitoring).
• Pro tier (private monitoring): coming soon. Pricing $99-299/mo bundled with vendor portfolio.
• Public retrospectives (post-confirmed only): methodology + /post-mortems.