Methodology

What a scan does

A scan runs a fixed set of independent checker modules against the target URL. Before those modules run, the scanner follows the target's full redirect chain (so every module inspects the address a visitor actually lands on, not the first URL entered), and revalidates every hop along the way. The modules that run against the resolved target are:

• SSL/TLS
• HTTP security headers
• Redirect behavior
• Cookie attributes
• DNS configuration
• Technology detection (informational)

Each module runs independently and is time-bounded. If a module fails or times out against a particular target, that failure is logged and the scan continues with the remaining modules — a module that could not complete is not treated as a passing (or failing) result for that category. See "What ‘Not measured’ means" below.

Categories checked and their weight

Every finding belongs to a category. Each category has a maximum number of points it can cost the overall score, regardless of how many individual findings land in it. The weights below sum to 100 and reflect the categories' relative security impact, as encoded directly in the scoring engine:

Any category outside this fixed list falls back to a default cap of 10 points.

Severity model

Every individual finding is assigned one of five severity levels, and each severity carries a fixed point deduction:

How the score is calculated

The calculation is a fixed arithmetic rule, run the same way for every scan:

1. Start from a base score of 100.
2. For every finding, add its severity's fixed point deduction to a running total for that finding's category.
3. For each category, cap that category's total deduction at the category's maximum (the table above). A category cannot cost the score more than its cap, no matter how many findings it produced.
4. Subtract the sum of all capped category deductions from 100. The result is clamped between 0 and 100.

This means the score is driven entirely by how many findings exist, in which categories, and at what severity — nothing about traffic, reputation, industry, or history factors into it.

Why fixing an issue can leave the score unchanged

Because deductions are capped per category, a category that produces many findings (headers checks several distinct headers, for example) can rack up more raw deduction than its cap allows. When that happens, the score already reflects the cap, not the raw total — so resolving one issue in an over-the-cap category can leave the score exactly where it was, because the cap was already absorbing the difference. The score only moves once the category's raw deduction drops back under its cap. This is a known, deliberate property of the capping design, not a bug — it keeps one noisy category from single-handedly sinking a score that is otherwise clean.

Grade thresholds

The final score maps to a letter grade using fixed thresholds:

What "Not measured" means

If a check could not be completed against a target — a module timed out, or failed for a reason specific to that target — it is not scored as if it had passed, and it is never rendered as a zero or a default value standing in for a real result. It is labelled "Not measured" instead, so a scan report never implies certainty the scan does not actually have. This is the same convention already used across Nivaronix's reporting: a value the platform did not observe is always disclosed as unmeasured, never guessed or defaulted.

Scan scope and limitations

• A scan describes the target at the moment it ran. It is a point-in-time snapshot, not a continuous measurement — a site's configuration can change at any time after a scan completes.
• The scanner checks external, observable configuration (SSL/TLS, HTTP headers, redirects, cookies, DNS, and detectable technologies). It does not test application logic, authenticate into the target, attempt exploitation, or perform any form of penetration testing.
• A scan requests the target's homepage once, plus robots.txt and sitemap.xml, and reads up to 5 MB of the response body to check meta and canonical tags and fingerprint detectable technologies. It does not follow redirects and it does not crawl beyond that page; broken-link checking, which does follow links across a site, runs only on a verified asset you have put under monitoring. We keep the findings rather than a copy of the page, though a finding quotes the specific tag or link it is about, so short excerpts of markup are retained as evidence.
• A finding's absence means the check ran and found no issue at that severity — it does not mean the target has no security issues outside what this scanner is built to check for.
• Each scan is bounded by a fixed timeout. A target that is slow or unreachable within that window produces "Not measured" results for the affected checks rather than a false pass or fail.
• Monitoring detects and alerts; it does not fix anything on the target. Findings come with remediation guidance — steps for a person to take — not an automated fix applied to your infrastructure. A governed, approval-gated remediation capability exists in the product for select providers, but as of this writing it has not been exercised against a live customer environment end to end, so it is not described here as a delivered detection mechanic. See how to verify a fix actually worked once remediation guidance has been acted on.
• An optional AI explanation layer, where enabled, restates an already-detected finding or incident in plain language. It runs after detection, is clearly attributed as AI-generated, and never itself decides whether a check passed, what severity a finding carries, or whether an incident is open or resolved.

Evidence and reports

Findings and scores shown in a Nivaronix report are reproduced directly from the stored scan record — nothing in a report is estimated, extrapolated, or filled in with a default value. Where evidence is available (for example the hops of a followed redirect chain), it is attached to the relevant finding so a result can be independently verified rather than taken on faith.

What "external" and "agentless" mean here

Nivaronix checks are external: every check runs from Nivaronix's own infrastructure against what is publicly reachable on the target — the same certificate, DNS records, and HTTP responses any visitor or resolver on the internet would see. Nothing runs inside the target's network or environment.

Monitoring is agentless and read-only: there is no software, credential, or agent installed on the target. A check is a small number of outbound requests on a schedule — a certificate handshake, a DNS query, an HTTP GET — read operations that request and observe, and do not write to, log into, or modify the target. That is a real but small footprint, not none: a scheduled request still reaches the target and can appear in its own access logs like any other visitor traffic. We describe this as read-only or low-footprint, not as "zero impact" or "completely passive," because those phrases claim more than a system that actively issues requests can support. See agentless vs. authenticated scanning for what this approach can and cannot see.

Moving a domain from a one-off scan to ongoing monitoring requires proving you control it: a one-time DNS TXT record you add to the domain. That verification step, not an installed agent, is what Nivaronix checks before it will monitor a domain unattended.

Continuous monitoring

Beyond a one-off scan, Nivaronix re-runs the same checker modules described above against a verified, monitored asset on a recurring schedule, using the identical scoring rule — monitoring does not use a different or weighted methodology from a manual scan. See what continuous website security monitoring is for how this differs from a one-off scan and what triggers an alert.

There are two kinds of scheduled check. A monitor actively rechecks an asset's certificates, DNS, headers, cookies, redirects, and availability. A heartbeat checkworks the opposite way: it is a dead man's switch for a scheduled job you run elsewhere (a backup, a cron task) — your job pings a URL each time it finishes, and if a ping does not arrive within the configured interval plus grace period, that silence is what opens the incident. A heartbeat check never sees the job's logs, output, or exit code — only whether it reported in on time.

Monitor recheck intervals are bounded by plan, not freely configurable below a floor: every 15 minutes on Free and Starter, every 5 minutes on Pro and Studio. Saving a monitor with a shorter interval than your plan's floor is rejected, and a check runs at or shortly after its due time rather than on the exact second. Heartbeat checks are never polled by Nivaronix — the expected interval and grace period you configure (minimum 60 seconds, whole numbers only) describe when a missing ping counts as overdue, not a poll schedule.

A scan and a monitor check are the same underlying operation run in a different context: a scan is a one-off invocation you trigger, a monitor is the identical set of checks invoked automatically on the interval above. Everything on this page about categories, severities, the scoring formula, and "Not measured" applies identically to both.

Findings vs. incidents

A finding is a single check result — one row of evidence about one thing the scanner observed, scored by severity as described above. An incidentis a different object: it opens when a monitored check's result changes for the worse compared to its previous recorded result, or when a heartbeat check misses its deadline. A clean scan with several low-severity findings is not, by itself, an incident — an incident specifically marks a detected change or a missed heartbeat, not a static state.

Once opened, an incident is alerted (email, webhook, or a configured Slack incoming webhook) and follows a lifecycle: open, then acknowledged, then resolved, then closed. Acknowledging an incident attaches a name and a time and does not overwrite whoever responded first. If nobody acknowledges an incident within the threshold you set for its severity, it escalates once — never repeatedly — to the same recipients and webhooks; maintenance windows suppress that escalation. Resolving an incident requires a written root cause from a person, kept as a separate record from any AI-generated hypothesis about the same incident — Nivaronix does not resolve incidents on its own. The one exception is a heartbeat: if a ping finally arrives while its incident is still open, that incident is resolved automatically, with a root cause recorded stating the job reported in and recovered on its own.

An optional, request-only AI layer can restate an already-recorded finding or incident in plain language after the fact. It runs after detection, never instead of it, its output is stored separately from the deterministic result it describes, and it never changes a score, a severity, or whether an incident is open or resolved.

Change detection and recovery

"Changed for the worse" is a comparison between a check's current result and its own previous recorded result for that same asset — not a comparison against some external baseline or industry average. A newly introduced finding, a severity increase, or a category result that regresses is what triggers the comparison; the identical category weights and severity deductions used for scoring apply to that comparison.

Recovery is symmetric: when a rechecked result improves back to (or past) its prior state, that is recorded the same way a regression is — as a change, backed by the same recorded observation, not a self-reported claim. For a monitor, a human still records the incident's resolution and root cause, as described above. For a heartbeat, recovery from a missed check closes the incident automatically, since a ping arriving is itself the recorded proof of recovery.

Verification

A domain must be verified before Nivaronix will monitor it unattended: add a domain you own, operate, or are explicitly authorized to assess, then prove control of it with a one-time DNS TXT record. A one-off scan does not require this — anyone can scan any public domain's external configuration without verifying it. Verification is only the gate for turning a domain into a recurring, scheduled monitor.

Frequently asked questions

Related pages

• What is a website security score? — what the score means and how grades map to it.
• How is a website security score calculated? — a shorter, search-focused guide.
• Run a free website security scan