Published 2026-04-28 — v1.1

Observation methodology

This page describes how CipherCue captures, records, and presents observations of externally visible organisation infrastructure. Our outputs are grounded in observed public fact, public technical metadata, and source attribution. We track observations over time and surface changes.

CipherCue reports what is externally observable, with a source recorded alongside the observation. When an observation matches a published standard, catalogue, or authority record, we cite that record. We do not perform intrusive testing and we do not assert unsupported security conclusions about an organisation.

What we observe

Our observation surface is publicly reachable systems and public metadata. Typical sources include, and are not limited to:

Public DNS records. Including but not limited to A, AAAA, MX, NS, and TXT records such as SPF, DMARC, DKIM, MTA-STS, BIMI, as well as CAA records and DNSSEC state.
Certificate Transparency log entries. For host discovery and certificate lineage via public CT logs.
TLS handshake metadata. Issuer, subject, validity window, fingerprint, and similar certificate metadata observed during a standard TLS handshake to a publicly reachable endpoint.
TCP service identification. Banner and protocol-response observation on publicly reachable ports, used to identify the service software in use.
Public HTTP responses. One or more requests to publicly advertised resources on a host, including the root document and well-known paths such as /.well-known/security.txt, /robots.txt, and trust pages where they exist. Responses are size-capped.
Public technical artefacts. Other publicly published technical records relevant to infrastructure identification, such as WHOIS metadata, ASN and BGP data from public sources, and public registry or catalogue entries.

The list above is illustrative. We may add or adjust sources over time, within the scope of publicly observable information.

What we do not do

Access private, authenticated, or credentialed endpoints.
Attempt exploitation, vulnerability validation, or payload fuzzing against any service.
Submit credentials, attempt authentication, or attempt to bypass access controls, bot protection, or WAF rules.
Decrypt, intercept, or otherwise interfere with traffic. All TLS metadata is obtained from standard handshakes with the target.
Collect or store personal data about named individuals. Published contact records that form part of the public observation surface, such as security.txt contacts and WHOIS abuse addresses, are treated as organisational metadata.

Recording observations

Each observation is stored with, at minimum:

The class of observation (for example, TLS certificate metadata, HTTP fingerprint, DNS policy record, or a match against a named authority catalogue).
The observed host or domain identifier.
The observation payload.
The observation timestamp.
A source attribution describing where the observation came from (for example, "public DNS query", "TLS handshake observation", or a named authority record such as "CISA Known Exploited Vulnerabilities catalogue").

Observations may be deduplicated or reconciled within an observation pass to avoid redundant records of identical state.

Change tracking

We compare a current observation against the most recent prior observation of the same class for the same host. Where the observed value has changed in a material way, we record a change event. We may suppress trivial or noisy diffs (for example, normalisation-only whitespace changes) to keep change records meaningful.

A change record is phrased as observed fact with source attribution:

DMARC policy observed as quarantine on 2026-03-15; observed as reject on 2026-04-21. Source: public DNS query.

We do not characterise a change as improvement, degradation, failure, or regression. A change record presents the prior value, the new value, the observation dates, and the source.

Source attribution and cited authorities

When an observation matches a published catalogue, standard, or authority record, we record and present the attribution to that authority. For example, when a software identification matches an entry in the CISA Known Exploited Vulnerabilities catalogue, the observation is presented with the catalogue reference and the catalogue entry date. We do not restate authority descriptions as our own conclusions.

Confidence

Where relevant, an observation carries a detection-confidence indicator. Detection confidence reflects how strongly the underlying signals match a known fingerprint or record. It is not a security score, risk score, or composite grade for an organisation. We do not publish a composite organisational score.

The detection-confidence model may evolve over time as our matching rules are refined. Model changes are recorded in this document's changelog.

Blocked observation attempts

Where an observation attempt does not complete (for example, a connection is refused, DNS resolution fails, a TLS handshake does not complete, or a request times out), we record the attempt and its outcome. A blocked or failed attempt is a record about our observation, not a statement about the security of the target.

Frequency

Observation is periodic, not continuous. Cadence is informed by change detection and customer watchlist state. See /scanning for operational pacing.

For a class of observations involving a match against a published authority catalogue, our coordinated disclosure practice applies: observations of this class are held back from customer-facing surfaces for a silent window before release, to allow responsible coordination with the affected organisation. Details and the current window length are in /disclosure-policy.

Informed by

Our operating practice is informed by the following references. We do not claim audited compliance, certification, or formal endorsement against any of them.

RFC 9359 — Reliable Operation of IP Reputation Services. Informs our posture of a documented programme, identifiable origin, and a contactable operator.
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment. Informs our distinction between passive observation and active testing. We stay within observation.
RFC 9116 — security.txt. We read published contacts for coordinated disclosure routing.
CERT/CC coordinated disclosure guidance and ISO/IEC 29147. Inform the structure of our coordinated disclosure practice.

Correction

If a specific observation about your organisation is incorrect, email corrections@ciphercue.com from an address at a domain you control, identifying the observation in question. We investigate and, where the observation is verified incorrect or no longer current, correct, annotate, or remove the record. Correction turnaround is typically within seven days of acknowledgement.

Opt out

See /opt-out. Two independent channels, either sufficient on its own.

Changelog
v1.1 — 2026-04-28 — Softened absolute claims ("every claim", "every negative assertion") to outcome-focused wording. Broadened observation-source list to include NS records, WHOIS, ASN/BGP, and other public technical artefacts. Clarified that confidence is detection-confidence, not a security score. Replaced internal database column names with generic wording. Reframed the disclosure-window line to reference the disclosure policy rather than hard-coding 48 hours. Restated standards section as "informed by" with a disclaimer against claimed compliance. Added noise-suppression allowance to change detection. Reworded privacy scope to exclude personal data collection rather than permitting any "beyond published contact records".
v1.0 — 2026-04-23 — Initial publication.