Live Scans vs Cached Results: Why Freshness Changes Everything

TL;DR: A cached result describes your website as it was when somebody last crawled it; a live scan describes it as it is right now. OnScanner connects to your infrastructure fresh on every single scan, which is why its findings can be acted on without re-verification. Caching has legitimate places in security tooling, but never between you and the current state of your own target.

In security scanning, "when did you look?" matters as much as "what did you find?" A finding is a claim about your infrastructure, and the claim is only as good as the moment of observation behind it. This post is the product-side view of that principle: what actually happens during a live OnScanner scan, what changes between crawls, and, honestly, where cached data is perfectly acceptable. The business-risk side of the argument, what stale findings cost and how attackers exploit the gap between crawls, is covered on the Byte Optimizer blog in Why Cached Vulnerability Data Is Putting Your Business at Risk.

What is the difference between a live scan and a cached result?

Some security services work like a search engine: they crawl large parts of the internet on their own schedule, store what they saw, and when you look up your domain they serve you the stored snapshot. The answer arrives instantly because the work already happened, possibly days or weeks ago. What you receive is a historical document.

A live scan inverts this. Nothing exists until you ask; when you start the scan, the scanner connects to your actual infrastructure at that moment and builds the result from what it observes. The timestamp on the report is the timestamp of the observation, not of some earlier crawl. That single property, observation time equals report time, is what the word "live" means, and it is the difference between a finding you can act on directly and a finding you first have to re-verify.

What actually happens during a live scan?

When you start an OnScanner scan, a stack of specialist engines runs in parallel against the target, and every one of them works from fresh observations:

• DNS is resolved at scan time, returning the records your authoritative servers answer with right now, not the records from the last crawl.
• TLS is negotiated fresh with your servers, capturing the protocols, cipher suites, and certificate they present this minute, including a certificate that expired an hour ago.
• HTTP requests are made live, so headers, redirect chains, and content reflect the deployment currently running.
• Services are fingerprinted from live banners, and the resulting product-and-version matches are evaluated against current CVE intelligence, with EPSS scores and CISA KEV status as they stand at scan time, plus patch-status and end-of-life checks.
• Email posture is checked with live lookups: the SPF, DKIM, and DMARC records your DNS serves at that moment.
• Pages are loaded to observe trackers actually firing in the browser, across 40+ categories, rather than inferred from a stored copy of your HTML.

Each finding carries the evidence observed at scan time, so every result traces back to a response, header, or record that existed when you asked. The full engine-by-engine breakdown is in the methodology, and the feature overview lists what each one covers.

What actually changes between crawls?

Two clocks tick against a stored snapshot: your site changes, and the threat landscape changes even when your site does not.

The last two rows are the ones teams underestimate. Your risk can change dramatically while nothing about your website changes at all: the software is the same, the configuration is the same, and yet a CVE published this morning, or a KEV addition overnight, has redrawn your priority list. Only a fresh evaluation catches that.

When is cached data actually acceptable?

A fair question deserves an honest answer: caching is not a dirty word, and three uses of stored data are entirely legitimate.

Your own scan history. Past results should absolutely be kept. That archive is your timeline: it powers trend lines, proves remediation to auditors, and catches regressions when a fix quietly comes undone. The key distinction is that history is a record of past observations, not a substitute for a new one.

Upstream vulnerability intelligence. CVE data from NVD, EPSS scores, and the KEV catalog are published datasets that update on their own schedules. Every scanner, and every attacker, works from synchronized copies of them. Freshness there means a recent sync, which is a different thing from re-observing your target. Intelligence about software in general can be a well-maintained local dataset; the observation of your specific target is what must be live.

Broad research. Studying internet-wide patterns across millions of sites does not need a fresh scan per query, and stored crawl data is the only practical way to do that kind of work. It stops being acceptable the moment the question becomes "is this site safe to leave as-is tonight?", because that question is about one target, right now.

The rule of thumb: cache the record of what you saw; never cache the act of looking when a decision depends on it.

How do you monitor for drift?

If a live scan is one fresh observation, monitoring is a series of them. OnScanner's scheduled monitoring reruns the full live scan on a cadence you choose, and because each run is a genuine observation rather than a cache refresh, every difference between two reports is a real change: either your surface moved, or the threat intelligence did. Both are worth knowing about, and both are actionable.

A practical cadence combines the two triggers: scan after every meaningful deployment, because that is when your surface changes by your own hand, and on a fixed schedule, because that is how you catch the changes nobody announced. Step six of our guide How to Scan a Website for Vulnerabilities covers where monitoring fits in the wider process.

Frequently asked questions

Does live scanning take longer than a cached lookup?

Yes, and that is the honest trade. A cached lookup is instant because the work already happened, possibly long ago; a live scan takes the time needed to actually observe your target, kept short by running specialist engines in parallel. What the wait buys is a result you can act on immediately, without first re-verifying whether it still describes your infrastructure.

Is OnScanner's CVE data live too?

The observation of your target is live on every scan. The vulnerability intelligence it is evaluated against, NVD data, EPSS scores, and the CISA KEV catalog, comes from authoritative datasets that publish updates on their own schedules, which is true for the entire industry. What matters is that your freshly fingerprinted versions are matched against that intelligence as it stands at scan time, not against a result computed weeks earlier.

How often should you rescan a website?

After every meaningful deployment, and on a recurring schedule regardless of deployments. The first trigger catches changes you made; the second catches everything else, from certificate expiry and DNS drift to new CVE publications and KEV additions against software you never touched. Scheduled monitoring automates the second trigger so staleness never depends on someone remembering to press a button.