Skip to main content
A Periphery result is evidence from a public provider hostname. It tells you what matched and what Periphery observed; it does not, by itself, prove who operates the app or what its current state is.
The console and API expose search signals, not attributed ownership. Attribution work is performed by Periphery as part of the managed service on the Pro plan: Periphery investigates matched apps and attributes them to their owners.
Use four separate questions when you triage a result.

​
1. Why did the app match?

A domain search can match because the provider hostname contains the domain, an email address uses the domain, or the page text mentions it. Copied footers, support addresses, documentation examples, partner integrations, and impersonation can all create matches. Do not interpret these matches as Periphery attribution. On Pro, the managed service performs the ownership investigation and attribution.

​
2. How fresh is the evidence?

The screenshot, extracted text, emails, credential findings, and raw HTML come from the most recent successful snapshot. Last seen is broader: it records the most recent check that treated the hostname as alive. A fallback liveness check can refresh it without replacing the snapshot artifacts. A recent last seen value can therefore sit next to older evidence. See Reading an app page for the full behavior.

​
3. What does a credential finding mean?

A finding means the page source contained a string that matched a credential detector.
  • Verified means Periphery confirmed the credential with its issuer at snapshot time.
  • Unverified means the format matched, but Periphery did not confirm it. It may be revoked, malformed, a placeholder, or a false positive.
  • Neither state tells you whether the credential is valid now.
If you own the credential, revoke or rotate it before fixing the public page. Do not use a surfaced credential to test a system you are not authorised to access. See Emails and credentials.

​
4. What does a favicon match mean?

A favicon hash is a similarity pivot. Identical icons often appear across forks, templates, redeployments, and phishing kits, but also across unrelated apps using a framework or product default. Use a favicon match to find candidates, then compare the hostname, page text, branding, and other evidence. Do not classify an app as a clone or impersonation from the favicon alone. See Finding clones.

​
A practical triage order

  1. Record the hostname, provider, and last seen value.
  2. Identify the matching signal. Work out whether it is a hostname, email, page-text, credential, or favicon lead.
  3. Separate matching from attribution. Search results show candidate matches. On Pro, Periphery’s managed service performs the attribution work and maps matched apps to their owners.
  4. Read the snapshot evidence. Note that the artifacts can be older than last seen.
  5. Handle credentials first. If you own an exposed credential, revoke or rotate it before removing the page.
  6. Pivot only as far as the evidence supports. Use filters and favicon searches to find related candidates, then validate them individually.
For concrete response paths, continue to Respond to findings.
Periphery indexes the supported provider suffixes, not every public hostname on the internet. An empty search means there is no current indexed match in that scope.