When “nothing found” gets mistaken for “safe”
A security lookup can return no adverse findings and still leave an important question unanswered: do we know enough to trust this interaction?
A member of your finance team receives a link to a supplier’s new payment portal.
Before opening it, they check the domain using a security tool. No threats detected. No warnings. A reassuring green indicator.
They proceed.
But what did that result actually establish?
Perhaps the domain has been examined extensively and no harmful behaviour was observed. Perhaps it has only just appeared. Perhaps the service checked a reputation database with no record of it. Perhaps part of the analysis could not be completed.
Those are materially different situations. Presenting them as the same reassuring outcome can turn a gap in knowledge into confidence the evidence does not support.
A negative result depends on the test
“Nothing found” can be useful information. Its meaning depends on what was checked and how likely that check was to identify the relevant threat.
A current, thorough examination of a specific page provides different assurance from finding no match for its domain in a list of previously reported threats.
Both checks can contribute to a decision. They answer different questions.
This distinction is already reflected in some technical systems. VirusTotal’s URL documentation separates a “harmless” assessment from “undetected”, which it defines as a scanner having no opinion about the site.
The problem arises when those distinctions disappear as information moves from a technical result into a dashboard, browser warning or business workflow.
No adverse evidence found is a finding about the checks performed. It is not a universal statement about safety.
How false reassurance develops
Consider a fictional supplier-payment scenario.
An attacker creates a portal that imitates a legitimate supplier. A message directs a customer to use it for an upcoming invoice.
The customer checks the domain against a reputation service. The service has no adverse record and returns that result accurately.
The interface translates it into “Safe”.
The customer interprets that as confirmation that the portal belongs to the supplier.
Three different conclusions have been compressed into one:
The service found no adverse record.
The website is safe to use.
The supplier authorised this payment destination.
Only the first conclusion was established by the lookup.
The error can occur even when the underlying search works exactly as designed. It happens in the interpretation of the result.
Why an adverse finding might be absent
There are several reasons a check might return nothing concerning.
The activity has not yet been observed.
A reputation service needs relevant evidence before it can report it. A newly encountered threat may not yet have generated that evidence.
The check has a different scope.
An assessment of a domain does not necessarily examine every page, download or interaction associated with it. VirusTotal notes that URL scanners and file scanners can reach different results because they assess different things, even when operated by the same vendor.
The available observation is old.
A result describes the evidence available at a particular time. The site or its use may have changed since then.
The check could not complete.
A timeout, unavailable source or inaccessible page limits the assessment. That should remain distinguishable from a completed check with no adverse findings.
The threat sits outside what was checked.
A genuine email address may carry an unauthorised request. A legitimate file-sharing service may host a deceptive document. Assessing the address or platform alone cannot establish the legitimacy of the request.
The right response to these limitations is to represent them accurately and use other evidence where the decision requires it.
Risk and confidence are different dimensions
A system may identify little evidence of risk while also having little information on which to base its assessment.
That is different from having substantial, relevant evidence supporting a lower-risk conclusion.
These examples illustrate the distinction:
Situation- A recent check observed clear credential theft on a specific page. (A strong adverse finding about that page)
- Relevant checks completed without identifying harmful activity. (Some reassurance within the scope and time of those checks)
- A domain has little available history and no adverse reports. (Limited knowledge; the absence of reports alone provides weak reassurance)
- The required checks failed or timed out. (An incomplete assessment)
A score or colour can help someone interpret a result quickly. It should preserve the difference between a favourable assessment and insufficient evidence.
If both appear identical, users have no way to adjust their decisions.
Uncertainty does not mean everything should be blocked
Treating every unknown domain as malicious would create another problem. New businesses, services and legitimate communications would encounter unnecessary barriers.
A useful response depends on what the person is about to do.
Reading a public information page, entering corporate credentials and changing a supplier’s payment details have different consequences. They should not require identical evidence.
Where information is limited, a system can recommend a proportionate next step:
For an unexpected sign-in request, navigate through the organisation’s established portal.
For a new payment destination, confirm the change through a previously verified supplier contact.
For a sensitive document transfer, check that the destination is approved for that information.
For an incomplete assessment, make the failure visible and follow the organisation’s policy for the intended action.
The objective is to help the user resolve the uncertainty that matters.
The interface is part of the security decision
Wording influences behaviour.
“Safe” can reasonably be read as permission to proceed. “No known threats found” is narrower, although it still needs context about coverage and freshness.
Where evidence is limited, a message such as this is more informative:
No adverse intelligence found. Limited history is available for this domain. Verify the destination before entering credentials or payment information.
Where a check failed, the message should say so:
Assessment unavailable. The required checks could not be completed.
These are examples of how a product could communicate results. The precise wording should reflect the checks it actually performs.
A useful interface should make three things understandable: what was found, what remains uncertain and what action is appropriate.
It should also avoid overwhelming people with routine warnings. The NCSC’s phishing guidance advocates layered protection and recognises that asking staff to examine every email in depth is impractical.
High confidence applies to reassurance too
Security providers should be able to justify adverse findings. They should apply similar discipline to reassuring ones.
That means asking:
What evidence supports this conclusion? How current is it? What does it cover? Did the checks complete? What could the user mistakenly infer from the label?
This matters particularly when intelligence is integrated into automated workflows. If “no match” automatically becomes “approve”, a system has converted an information gap into a business decision.
That may be an intentional policy for some low-consequence activities. It should be a conscious choice, with the limits understood.
What this means for ThreatPrevent
At ThreatPrevent, our focus is high-confidence intelligence that helps people make better decisions about the digital entities they encounter.
That principle carries a responsibility to be clear about the limits of an assessment. A favourable result should inform the decision alongside the context, the proposed action and any required verification.
The standard we believe trust intelligence should meet is straightforward: conclusions should be proportionate to the evidence, and uncertainty should remain visible where it affects the decision.
Before treating “nothing found” as reassurance, ask what the system had a meaningful opportunity to find.