DEV Community: Brandon Sooknanan

What's new in Varaxon Scan Hub: October 2026

Brandon Sooknanan — Mon, 26 Oct 2026 21:50:11 +0000

Key takeaways

New: a free email and domain check, graded A to F, for your own domain, your clients and their suppliers.
Reports now prove what was fixed since the last scan, with deadlines and a past due list behind them.
Proof packs turn months of that history into evidence for audits, insurers and renewals.
Everything stays evidence-led: code decides the facts, and AI only writes from them.

The short version

This month we built the parts that come after the report: proving the work was done, tracking what is late, recording what the client chose not to fix, and handing all of it to whoever asks. We also added a free check that has nothing to do with scanners at all. Here is everything, with links to the full guides.

Free email and domain check

Can someone send email pretending to be you? The free email check answers in about 20 seconds, with no account. It reads SPF, DKIM, DMARC, MTA-STS and the domain's registry record, looks at about 400 lookalike names, and checks up to three suppliers. It grades the domain A to F by fixed rules and lists only the DNS changes that raise the grade.

Inside Scan Hub it runs for each client at no cost, as a white-label PDF with a fingerprint, and a recheck shows the grade before and after your fixes. Read the full guide.

Proof of fix in every report

Each report now has a Since the last scan section: what was fixed, what came back and what is new, system by system, most urgent first. If a rescan didn't log in, issues are marked not rechecked, never fixed. Read the full guide.

Fix deadlines and signed risk acceptance

Fix deadlines. Every tracked finding has a due date from its priority band, or the CISA KEV due date when that is sooner. Each client has a past due list with days late and an on-time count. You can set deadlines for the whole organization or per client.
Risk acceptance. When a client won't fix something, record why, any compensating control and an end date, or send their contact a one-time link to sign online. Accepted findings stay open but are not past due, and you are reminded before an acceptance ends.

Proof packs

A white-label PDF of a client's last 30 to 365 days: what was fixed and proven by a rescan, what is open, past due or accepted, the tickets sent and the scans used. It can map that evidence to CIS Controls v8, NIST CSF 2.0 and the HIPAA Security Rule, and answer the questions cyber insurers commonly ask, without ever claiming a control is met. A fingerprint lets anyone confirm the facts weren't changed. Read the full guide.

An In progress page

After you upload a scan or click Build report, you no longer have to go back to the client's page to find it. In progress in the sidebar lists every report, proof pack and email check being built across your team, with its current step and a progress bar, plus what finished in the last 24 hours. The sidebar shows a count while anything is building, and a one-line strip at the top of every page links to it.

More evidence behind every ranking

Scan Hub ranks findings by real-world evidence first, not by severity score alone. Each report now shows more of that evidence:

CISA KEV decides the top band, and EPSS exploit likelihood moves a finding up and orders findings within each band. See CVSS vs EPSS vs CISA KEV.
VulnCheck KEV listings are shown next to CISA's, so a CVE reported as exploited elsewhere is not missed.
End-of-life dates for common software and operating systems, so the report says when no patch is coming and what to move to.
A What public threat data adds section at the top of the report sums up what this evidence changed.
For exports that leave CVEs out, Scan Hub now maps the scanner's own check IDs to CVEs. Our second sample report went from no known-exploited matches to 9.

Already in Scan Hub

Scan Hub is scanner-agnostic: upload exports from the network, host and web vulnerability scanners you already run, or connect Microsoft Defender or ConnectSecure. After you review a report, it can push the fixes into ConnectWise PSA or HaloPSA as tickets. Reports are white-label, team members have their own roles with an activity log, and there is a free pre-flight check before you spend anything. Scan Hub is listed on Microsoft Marketplace and the ConnectWise® Marketplace.

We built it for MSPs, and just as much for internal IT, compliance and security teams. Your first three reports are free, with no card needed. Create an account or see sample reports.

Common questions

Do the new features cost extra?

Proof of fix, fix deadlines, risk acceptance, the In progress page and email checks are included. A proof pack is paid for like a report, from your monthly allowance or one credit. See pricing.

Does AI decide what is fixed or how urgent a finding is?

No. Code compares scans, ranks findings from public threat data and builds the facts. AI writes the plain-English report and the proof pack summary from those facts, and its output is checked against them.

Originally published at varaxontech.com. Scan Hub is listed on Microsoft Marketplace and the ConnectWise® Marketplace, and it can push fixes into ConnectWise PSA or HaloPSA as tickets.

Proof pack: evidence of your vulnerability work for audits, insurers and renewals

Brandon Sooknanan — Mon, 26 Oct 2026 21:49:29 +0000

Key takeaways

Every tracked finding now has a fix deadline, and a past due list shows what is late and by how many days.
When a client won't fix something, they can accept the risk by signing online, with a reason and an end date.
A proof pack turns 30 to 365 days of that history into a white-label PDF: what was fixed and proven, what is open, what was accepted.
It maps the evidence to common control frameworks and insurance questions, and it never claims a control is met.

The question every report leaves open

A vulnerability report says what is wrong today. Auditors, cyber insurers and clients at renewal ask something else: "Show me what you did about it." The answer is usually spread across old reports, tickets and email threads, and someone spends a day pulling it together.

We built the proof pack to answer that question from records Scan Hub already keeps. It has three parts that work together: fix deadlines, risk acceptance and the pack itself.

1. Fix deadlines and the past due list

Each finding Scan Hub tracks gets one due date: its priority band's deadline, counted from when it was first seen, or the CISA KEV due date when that comes sooner.

Set deadlines once for your whole organization, and give a client its own when its contract says something different.
Each client's overview shows a Past due list with days late, and how many fixes landed on time in the last 90 days.
Fix these first shows each finding's due date.
A fix counts as on time only when the rescan that proved it ran by the due date. Saying it was patched is not enough.

Not sure what deadlines to use? See how to set remediation SLAs.

2. Risk acceptance with an online signature

Some findings won't be fixed: a legacy system, a vendor that hasn't shipped a patch, a cost the client won't pay. That is the client's decision, and it should be written down. In Scan Hub an owner or admin records it with a reason, an optional compensating control and an end date no more than 12 months away. Then either:

Record an acceptance you already have, from an email or a meeting, or
Ask the client's contact to sign online. They get a one-time link that lasts 14 days, read the exact wording, and sign by typing their name, or decline.

The wording, the signature and the time are kept together. While an acceptance is in force, the finding stays open (it is never counted as fixed) but it is not past due. You get an email 14 days before it ends, so it is reviewed rather than forgotten. See how to document risk acceptance for what a good acceptance says.

3. The proof pack

Pick a client and a period (the last 30, 90, 180 or 365 days), add a cover note if you like, and Scan Hub builds a white-label PDF from the facts:

What was fixed and proven by a rescan, on time or late against its deadline.
What is open, what is past due and what is accepted, with how each acceptance was signed.
The tickets sent to your PSA and the scans the pack is based on.

Code gathers these facts and freezes them in a facts file. Its SHA-256 is the pack's fingerprint, printed in the PDF. You can download the PDF, a CSV of the lists and the facts file itself, so an auditor can recompute the fingerprint and confirm nothing was changed.

Control map and insurance questions

A pack can map its evidence to CIS Controls v8, NIST CSF 2.0, the HIPAA Security Rule and CMMC Level 2. You choose which. Each row prints the evidence the pack holds for that control, or says plainly that it holds none. No row ever says a control is met: that is the auditor's call, not ours.

You can also tick the questions cyber insurers commonly ask, such as how often you scan, how fast you fix and what is still open. Each answer is the evidence from the pack: scans run, fix deadlines and median days to fix, known-exploited issues, what is past due, accepted risks and tickets.

Evidence, not certification. A proof pack is evidence for your own audit, insurance and client work. It does not certify anything or state that a standard, regulation or insurance requirement is met.

Where AI fits, and where it doesn't

AI writes one thing: a short cover summary. It works only from the pack's counts and dates, and every number it writes must point to one of those facts, or the summary is rejected. It is not allowed words like compliant, certified or audit-ready. It never receives the client's name, the reasons for an acceptance or who signed it. If its draft fails the checks twice, the pack uses fixed wording instead. The method page says when AI wrote the summary, and you can turn it off for any pack.

Everything else in the pack comes straight from your records. That is what we mean by evidence-led.

How to start

Set your fix deadlines in Settings, and a client's own deadlines if they differ.
Keep scanning each client with the same settings, so fixes are proven by a rescan. Proof of fix shows the changes in every report.
Record risk acceptances as they happen, not the week before the audit.
Make a proof pack for the period the auditor, insurer or client asks about.

A proof pack is paid for like a report: from your plan's monthly allowance, then one credit. If a pack fails three times, the credit comes back. Your first three reports are free, with no card needed. Create an account or see pricing.

Common questions

Does a proof pack make my client compliant?

No. It is evidence of the work done, mapped to controls so an auditor can find it quickly. Whether a control is met is the auditor's or insurer's decision.

What if the client won't sign a risk acceptance online?

Record the acceptance you already have, from an email or meeting notes, and say where it came from. The pack shows how each acceptance was made.

Can someone check the pack wasn't edited?

Yes. Download the facts file and compute its SHA-256. It must match the fingerprint printed in the PDF.

Originally published at varaxontech.com. Scan Hub is listed on Microsoft Marketplace and the ConnectWise® Marketplace, and it can push fixes into ConnectWise PSA or HaloPSA as tickets.

Can someone fake your email? A free SPF, DKIM and DMARC check, graded A to F

Brandon Sooknanan — Mon, 26 Oct 2026 21:49:28 +0000

Key takeaways

The free email check tells you in about 20 seconds whether anyone can send email pretending to be your domain.
It reads public records only, grades the domain A to F by fixed rules, and lists only the DNS changes that raise the grade.
It also checks up to three suppliers and about 400 lookalike names of your domain.
Inside Scan Hub the same check runs for each client, as a white-label PDF that shows the grade before and after your fixes.

Why this matters

Fake invoices and "we've changed our bank details" emails work because many domains still let anyone send mail in their name. Nothing has to be hacked. The scammer just writes your address in the From line, and if your domain doesn't tell mail servers to refuse it, the email lands in the inbox looking real.

Three DNS records decide this: SPF (which servers may send for you), DKIM (a signature that proves a message really came from you) and DMARC (what receivers should do with mail that fails those checks). We built a free check that reads them and tells you, in plain words, whether fake email in your name is stopped.

What the check looks at

Fake email in your name. SPF and DMARC: whether mail servers are told to refuse, junk or deliver email that pretends to come from you.
Signed email. DKIM keys under the names common mail services use, and whether they are long enough.
Encrypted delivery. MTA-STS and TLS reporting, which make other servers insist on encryption when they send to you.
Domain and DNS. Registration expiry, the registrar lock, DNSSEC and CAA, from the registry's public record.
Lookalike domains. About 400 typo and look-alike names of your domain, and which of them are set up to send or receive email.
Your suppliers. The same spoofing basics for up to three companies you pay, because fake invoices usually pretend to come from one of them.

Every answer shows the record it came from, so you can check it yourself.

How the grade works

The grade follows fixed rules, so the same records always get the same grade:

Grade	What it means
F	Fake email is not stopped, and SPF is missing or broken.
D	Fake email is not stopped: no DMARC record, a broken one, or p=none.
C	Fake email is only partly stopped (for example sent to junk), or something else must be fixed now.
B	Fake email is refused, with smaller items left to improve.
A	Fake email is refused and nothing is left to fix.

Lookalike domains are listed but never change the grade, because they are other people's registrations, not your setup.

Under the grade is How to raise the grade: only the steps that change it, in order, each with the exact record to publish. Each item is labelled Needed for B (or whichever grade it unlocks) or Optional, so you know what to do first and what can wait.

We ran it on our own domain first

varaxontech.com got a D. Our DMARC record was set to p=none, which only asks for reports and stops nothing. We changed it to p=quarantine, so fakes go to junk, and turned on DKIM signing with our mail provider. The next check gave a C, and the before and after report showed exactly what changed.

The last step is p=reject, which tells servers to refuse fakes outright. We are waiting one to two weeks first, reading the DMARC reports to make sure none of our own real email fails the checks. That order (p=none with reports, then quarantine, then reject) is the safe way to roll DMARC out on any domain.

For your clients: a white-label report with before and after

If you look after other companies' IT, the same check runs inside Scan Hub for each client, at no cost:

A white-label PDF with your logo, the grade, the steps to raise it and the evidence behind every answer.
A fingerprint (SHA-256 of the check's facts) printed on the report, so anyone can confirm the facts were not changed.
Since the last check. Run it again after the fixes and the report shows the grade, each finding and each supplier before and after. The client sees the work was done.
Supplier checks for the companies your client pays, which makes a good conversation about invoice fraud.

It sits next to the client's vulnerability reports, so email security, scan results and proof of fix are in one place.

How it's checked, and what it can't see

Only public records: DNS answers read through Google and Cloudflare DNS-over-HTTPS, the registry's public RDAP record, and your published MTA-STS policy file if there is one. We never connect to your mail servers or send any email. On the public page, results are held in memory for ten minutes and then discarded. Nothing is stored or linked to you.

DKIM keys can only be looked for under common names. A key under another name is not visible from outside, so "not found" does not prove DKIM is off.
Lookalike names come from fixed typo and look-alike rules, so some lookalikes may not be in the list.
A DNS change can take up to the record's TTL to show everywhere, so recheck a little later if a fix doesn't appear straight away.

A good grade is not a reason to skip the phone call. Whatever a supplier's grade, confirm any change of bank details by phone, on a number you already have.

Common questions

Is the email check really free?

Yes. The public check at varaxontech.com/email-check needs no account. Inside Scan Hub, email checks for your clients don't use a report or a credit.

What DMARC policy should I use?

End at p=reject. Start with p=none and a reporting address, read the reports for a week or two to find any real senders that fail, fix them, then move to p=quarantine and finally p=reject.

Does the check send email or log in to anything?

No. It only reads public DNS and registry records and the published MTA-STS policy file. It never connects to a mail server.

Originally published at varaxontech.com. Scan Hub is listed on Microsoft Marketplace and the ConnectWise® Marketplace, and it can push fixes into ConnectWise PSA or HaloPSA as tickets.

Proof of fix: show clients what you fixed since the last scan

Brandon Sooknanan — Sat, 24 Oct 2026 19:31:50 +0000

Every month you patch, rescan and send the client a report. And every month the report shows a long list of what is still wrong, while the work your team did is invisible.

Proof of fix changes that. Varaxon Scan Hub reports now open with a Since the last scan section that names what your team fixed.

Key takeaways

Each report compares this scan with the previous scan of the same systems from the same scanner.
It lists every issue that was fixed, came back or is new, with the systems it changed on, most urgent first.
If the rescan did not log in, issues are marked not rechecked, never fixed.
It is in the client's PDF and on the report page in the app, at no extra cost.

What the client sees

At the top of the section are five numbers: fixed, new, reopened, still open and not rechecked. Still-open issues are also split by priority band.

Below that are the lists:

Fixed since the last scan. Each issue by name, with its priority band, a KEV tag if it is on the CISA Known Exploited Vulnerabilities list, and the systems it was fixed on.
Back since the last scan. Issues that were fixed before and have returned.
New since the last scan. Issues this scan found for the first time.

So instead of "we did some patching", the client reads "Zerologon fixed on dc01, OpenSSH fixed on three servers". That is the conversation you want to have at renewal.

The numbers come straight from comparing the two scans. AI does not write or guess them.

When it won't mark something fixed

A wrong "fixed" is worse than no proof at all, so Scan Hub is careful:

The rescan didn't log in. If last month's scan logged in to a system and this month's didn't, issues that need a login to see were not looked for. They show as not rechecked and stay open until a logged-in scan checks again.
A different scanner. Scanners name and check issues differently, so a Nessus scan is never compared with a Qualys scan. The comparison starts with the next scan from the same scanner.
The scanner isn't named. An export that doesn't say which scanner made it is not compared, and nothing is marked fixed.
A system is missing. If a system from last time isn't in this scan, its issues are not counted as fixed or still open. Some sources, such as Defender pulls and some CSV exports, list only systems that still have findings, so the report says so.

In the app (not in the client's PDF), you also get a note when every issue on a system vanished at once. That is usually good news, but it is also what a scan that never reached the system looks like.

How to use it each month

Scan the client with the same scanner and settings as last month. Use a logged-in (credentialed) scan if you can.
Upload the export, or let the Defender or ConnectSecure connection build the report.
Send the PDF. The fixed list is your proof of work. The new and reopened lists are next month's plan.

Proof of fix works with Nessus, Qualys, Rapid7, Greenbone/OpenVAS, Nuclei, Microsoft Defender and the other scanners Scan Hub reads. Your first three reports are free, with no card needed. Try Scan Hub or see sample reports.

Scan Hub is listed on Microsoft Marketplace and the ConnectWise® Marketplace, and it can push fixes into ConnectWise PSA as tickets.

Varaxon Scan Hub is now on the ConnectWise Marketplace and Microsoft Marketplace

Brandon Sooknanan — Fri, 23 Oct 2026 19:12:31 +0000

Varaxon Scan Hub is now listed on the ConnectWise® Marketplace and Microsoft Marketplace.

Key takeaways

Scan Hub connects to Microsoft Defender, and after you review a report it pushes the fixes into ConnectWise PSA or HaloPSA as tickets.
It also reads exports from Nessus, Qualys, Rapid7, Greenbone/OpenVAS, Nuclei and other network, host and web vulnerability scanners.
Your first three reports are free, with no card needed.

What Varaxon Scan Hub does

Varaxon Scan Hub turns vulnerability scan results into client-ready reports for MSPs, MSSPs and security consultants. Upload an export or connect a source. Scan Hub ranks every finding by real-world exploitation and writes a branded report in plain English: what was found, how serious it is and what to fix first.

Each finding is checked against the CISA Known Exploited Vulnerabilities catalog, EPSS exploit likelihood and vendor fixes. Findings are then grouped into the fewest actions that close the most risk. See how the ranking works or browse sample reports.

Why the ConnectWise and Microsoft marketplaces

Most MSPs spend their day in two places: Microsoft 365 and Defender for their clients' devices, and a PSA for their service desk. Scan Hub works with both, so we listed it where MSPs already look for tools.

Microsoft Defender. Connect a client's Defender Vulnerability Management, Defender for Endpoint Plan 2, Defender for Servers or Defender for Business (in Microsoft 365 Business Premium), and build a report without exporting anything.
ConnectWise PSA. After you review a report, Scan Hub opens a ticket for each fix, so remediation lands in the queue your technicians already work from. HaloPSA works the same way.
ConnectSecure. Connect ConnectSecure with an API key and report on one company or several.

Where to find the listings

ConnectWise Marketplace: Varaxon Scan Hub on the ConnectWise Marketplace
Microsoft Marketplace: Varaxon Scan Hub on Microsoft Marketplace. Use the Contact me button and we reply by email.

Plans are bought at scan.varaxontech.com, not through either marketplace.

It still works with the scanner you already run

The marketplaces are a new way to find Scan Hub, not a new requirement. You can still upload a CSV, XML or JSON export from Tenable Nessus, Qualys, Rapid7, Greenbone/OpenVAS, Nuclei and other network, host and web vulnerability scanners. There are guides for Nessus reports and OpenVAS reports.

How to get started

Run the free pre-flight check on one of your exports. It needs no account and shows what Scan Hub can read.
Create an account. Your first three reports are free.
Connect Defender, ConnectSecure or your PSA when you're ready, or keep uploading exports.

Common questions

Is Varaxon Scan Hub on the ConnectWise Marketplace?
Yes. It is listed as a security reporting integration that creates ConnectWise PSA tickets from reviewed reports.

Is Varaxon Scan Hub on Microsoft Marketplace?
Yes, as a SaaS app. Use the Contact me button on the listing and we reply by email.

Does Scan Hub work with Microsoft Defender for Business?
Yes, along with Defender for Endpoint Plan 2, Defender Vulnerability Management and Defender for Servers.

Do I need ConnectWise or Microsoft to use Scan Hub?
No. You can upload exports from your vulnerability scanner without connecting anything.

How much does it cost?
Your first three reports are free with no card needed. After that, plans start at $49 a month, or you can pay $9 per report. See pricing.

Originally published at varaxontech.com. ConnectWise is a registered trademark of ConnectWise, LLC. Microsoft is a trademark of the Microsoft group of companies. A marketplace listing is not an endorsement by either company.

A Critical CVE Just Dropped. What MSPs Should Do in the First 48 Hours

Brandon Sooknanan — Thu, 22 Oct 2026 22:36:44 +0000

It happens a few times a year. A vulnerability in a VPN appliance, a firewall, a file-transfer tool or a widely used library gets announced, it's rated critical, and within hours there are reports of attacks. Clients start emailing. Your team wants to know where to start.

The MSPs that handle these well aren't faster typists. They follow the same short routine every time.

Hour 0 to 4: confirm what you're dealing with

Before touching anything, answer four questions from reliable sources (the vendor advisory, the CVE record, and CISA if it has commented):

What exactly is affected? Product, versions and configurations. Many critical flaws only apply when a specific feature is turned on.
Is it being exploited? Check whether it's on CISA's Known Exploited Vulnerabilities catalog, and look at its EPSS score, which estimates how likely exploitation is in the next 30 days.
Is it reachable from the internet? An internet-facing VPN portal and an internal-only admin console are very different emergencies.
Is there a fix or a workaround? A patched version, a configuration change, or a vendor mitigation to apply until the patch is out.

Write the answers down in a short internal note. It becomes the basis for everything you tell clients.

Hour 4 to 12: find out who's exposed

This is where good asset data pays off. Work from what you already have:

Your RMM and asset inventory: search for the product and version across every client
Your latest scan exports: filter by the product name, CPE or affected port
A targeted rescan: many scanners publish a check for a high-profile CVE quickly; run it against the likely systems rather than waiting for the monthly scan
External exposure: check which clients have the affected service open to the internet

The output you want is a simple list: client, system, version, internet-facing or not, and whether a fix is available.

Hour 12 to 24: fix in order of exposure

Not every affected system needs the same urgency. A sensible order:

Internet-facing systems where exploitation has been confirmed
Other internet-facing systems
Internal systems that hold sensitive data or admin access
Everything else, inside the normal patch cycle

Where a patch isn't available yet, apply the vendor's mitigation, restrict access to the affected service, or take it offline briefly if the client agrees. For edge devices that were exposed before you patched, check the vendor's guidance on signs of compromise, because patching alone doesn't remove an attacker who is already in.

Hour 24 to 48: confirm and tell clients

Patching isn't finished until you've checked it worked. Rescan the affected systems, or verify the version directly, and note the result.

Then send each affected client a short update. Clients who weren't affected appreciate a note too:

"Yesterday a critical vulnerability was announced in [product]. We checked all of your systems. Two were affected; both were updated last night and we've confirmed the fix. No action is needed from you."

Three sentences, no jargon, and a clear answer to the only question they have: are we OK?

Afterwards: keep the lessons

Once things are quiet, spend twenty minutes on what slowed you down. Usually it's one of three things: an asset that wasn't in the inventory, a client whose scans hadn't run recently, or a device nobody had admin access to. Fix that gap and the next one goes faster.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports, with known exploited vulnerabilities at the top. Your first 3 reports are free, no credit card needed: varaxontech.com.

Drafted with AI assistance and reviewed by the Varaxon team.

End-of-Life Software in Vulnerability Reports: What to Do When There's No Patch Coming

Brandon Sooknanan — Thu, 22 Oct 2026 22:36:36 +0000

Most findings in a vulnerability report have a fix: install the update, change the setting, restart the service. End-of-life software is different. When a vendor stops supporting a product, new vulnerabilities in it are still discovered, but nobody ships a patch. The finding will be on every report from now on until the system is upgraded, replaced or removed.

That makes end-of-life (EOL) software one of the most important things a report can point out, and one of the easiest to bury in a long list.

Why EOL deserves its own section

A missing patch is a task. An unsupported system is a decision. Treating it like one more finding causes three problems:

It looks fixable when it isn't. A ticket that says "patch Windows Server 2012 R2" can't be closed, because there is nothing left to install.
The real risk is understated. The scanner can only flag vulnerabilities that are already known. On an unsupported product, every new one found from now on stays open for good.
The fix needs budget. Replacing a server or a line-of-business application is a project, and the client has to approve it. They can only do that if the report says so plainly.

How to spot it in a scan

Most scanners report unsupported software directly, with findings named along the lines of "Unsupported Version Detection" or "End of Life", often at critical severity. Look for them across:

Operating systems: Windows 10 (mainstream support ended October 14, 2025, with paid Extended Security Updates available for a limited time), Windows Server 2012 and 2012 R2 (ended October 2023), and older Linux releases past their vendor's support window
Server software: old versions of SQL Server, Exchange, PHP, Apache, OpenSSL and Java runtimes
Network gear: firewalls, VPN appliances and switches whose firmware line the vendor no longer updates
Applications: older browsers, PDF readers, and line-of-business software tied to an old runtime

Credentialed scans find far more of this than network-only scans, because the installed version is read directly instead of guessed from a banner.

Explaining it to a client

Keep it concrete and short:

"The accounting server runs a version of Windows that Microsoft stopped fixing in 2023. New security problems are still being found in it, and none of them will ever be patched. We recommend moving it to a supported version this quarter."

Then give them the options, not just the problem:

Option	When it fits	What it costs
Upgrade in place	The application supports a newer OS or version	Licence plus a maintenance window
Replace	Hardware is old too, or the vendor offers a newer product	Budget and a project plan
Pay for extended support	A vendor offers it (for example Microsoft ESU) and a short bridge is needed	A yearly fee that usually rises each year
Isolate and accept	The system can't change yet, such as lab or medical equipment	Network changes plus a documented, dated risk acceptance
Retire	Nobody actually needs it anymore	Usually the cheapest option of all

Track it as a roadmap, not a ticket

EOL items move on budget cycles, not patch cycles. A short table at the end of each report works well: system, product and version, support end date, chosen option, owner and target date. Add products whose support ends within the next twelve months too, so the client can budget before the date arrives rather than after.

Then report progress the same way each time. "Unsupported systems: 7 last quarter, 4 now, 2 scheduled for replacement in January" is a line a client can follow, and it shows the work moving even when individual findings don't.

Don't let isolation become permanent

Isolating an unsupported system is a reasonable bridge. It is not a plan. Give every isolated EOL system a review date, check that the network rules are still in place at each scan, and raise it again if anything changes, such as the system becoming reachable from the internet or one of its vulnerabilities appearing on CISA's Known Exploited Vulnerabilities list.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports with prioritized actions. Your first 3 reports are free, no credit card needed: varaxontech.com.

Drafted with AI assistance and reviewed by the Varaxon team.

Your First Vulnerability Scan for a New Client: A Baseline That Sets the Tone

Brandon Sooknanan — Thu, 22 Oct 2026 00:50:39 +0000

The first scan for a new client is different from every scan after it. There's no previous report to compare against, the asset list is probably incomplete, and the results will almost certainly look worse than anyone expected. Handled well, it becomes the baseline every future report is measured against. Handled badly, it becomes the scary PDF that made the client nervous in week one.

Before the scan: agree on scope in writing

A one-page scope note avoids most first-scan surprises. It should cover:

What's in: public IP ranges and hostnames for the external scan; subnets, sites and cloud networks for the internal one
What's out: anything fragile or owned by someone else, such as medical devices, industrial controls or a landlord's network
When: a scan window, and who to call if something misbehaves
Credentials: which accounts the scanner will use, and who created them
Permission: written sign-off from someone authorized to approve scanning, especially for anything hosted by a third party

The sign-off isn't just formality. Scanning systems you aren't authorized to test can breach a hosting contract, and occasionally the law.

Get credentials working before scan day

A failed login silently turns a credentialed scan into a network-only scan, and the results look misleadingly clean. Test the scan account on a couple of Windows and Linux hosts first. On scan day, check the scanner's own authentication results before you trust a single number.

Expect a big number, and say so first

A first credentialed scan of a network nobody has scanned before routinely produces hundreds or thousands of findings. That doesn't mean the previous IT provider did a terrible job. It usually means nobody was looking.

Tell the client before they see the report:

"First scans always look worse than later ones, because they include everything that's built up over the years. Most of it comes down to a small number of fixes."

Setting that expectation turns a shock into a plan.

Present a baseline, not a verdict

The first report should do four things:

Show what was covered. Which hosts were scanned, which had working credentials, and anything that couldn't be reached.
Group findings into actions. Hundreds of findings usually collapse into ten or twenty actions: update a browser everywhere, patch a server, replace an end-of-life machine.
Pick a first wave. Known exploited vulnerabilities and anything exposed to the internet go first. Agree a short list the client can approve in one meeting.
Record the starting point. Total findings by severity, number of known exploited issues and number of hosts covered. Those are the numbers future reports compare against.

Fill the gaps the scan reveals

First scans almost always uncover something about the environment itself:

Devices nobody had on the asset list
Systems the scanner couldn't log in to
End-of-life operating systems that can't be patched
Network segments that weren't in scope because nobody knew they existed

Put these in the report as findings in their own right. An unknown device is a risk, and a host that couldn't be assessed is a gap, not a pass.

Plan the second scan now

The second scan is where the client sees progress. Book it before you leave the first meeting, usually 30 days later, after the first wave of fixes. When the next report shows known exploited issues going from twelve to two, the value of the work explains itself.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports that show coverage and gaps up front. Your first 3 reports are free, no credit card needed: varaxontech.com.

This post first appeared on the Varaxon Blog. Drafted with AI assistance and reviewed by the Varaxon team.

Internal vs External Vulnerability Scans: What Each One Tells You

Brandon Sooknanan — Thu, 22 Oct 2026 00:50:30 +0000

"We scanned your network" can mean two very different things. An external scan looks at the client from the internet, the way any stranger can. An internal scan looks from inside the office or the cloud network, the way an attacker would after getting a foothold. They find different problems, they answer different questions, and mixing them up in a report leads to bad decisions.

External scans: the front door

An external scan runs from outside the client's network against their public IP addresses and hostnames: the firewall, VPN gateway, email server, websites and any cloud services they expose.

It answers: what can anyone on the internet reach, and is any of it vulnerable?

Typical findings:

Remote access services (RDP, SSH, VPN portals) exposed to the internet
Outdated firmware on firewalls and VPN appliances
Weak TLS settings or expired certificates
Admin interfaces that should never be public
Forgotten test servers and old DNS records still pointing at live systems

External findings are usually few in number and high in consequence. Edge devices such as VPN appliances and firewalls show up on the CISA Known Exploited Vulnerabilities list again and again, because they are the easiest way in.

Internal scans: everything behind it

An internal scan runs from a machine or agent inside the network and looks at workstations, servers, printers, switches and everything else that isn't public.

It answers: if someone gets in, how far can they go?

Typical findings:

Missing operating system and application patches
Outdated browsers, PDF readers and office software
Old protocols still enabled (SMBv1, unsigned SMB, legacy TLS)
Default credentials on printers, cameras and network gear
End-of-life systems nobody has replaced

Internal scans produce far more findings, especially when they're credentialed. That is normal: there is much more to look at.

Side by side

	External	Internal
Runs from	The internet	Inside the network
Targets	Public IPs, hostnames, web apps	Workstations, servers, network devices
Main question	What can a stranger reach?	How far could an intruder get?
Finding volume	Low	High
Typical priority	Fix fast; often exposed and exploited	Fix by risk; prioritize known exploited issues
Common requirement	PCI DSS quarterly external scans (by an ASV)	PCI DSS quarterly internal scans, cyber insurance questionnaires

Why you usually need both

An external scan alone tells you the doors are locked but nothing about what's inside. Phishing, a stolen password or a compromised vendor gets an attacker past the edge without touching any of those doors, and then the internal findings decide how bad the day gets.

An internal scan alone misses the most exposed systems entirely, and those are the ones that get hit by automated attacks within days of a new vulnerability being announced.

A sensible baseline for most small and mid-sized clients is an external scan at least monthly and after any firewall or DNS change, and a credentialed internal scan monthly.

Report them separately

The most common reporting mistake is merging both scans into one long list. Three critical internal findings on workstations and one critical finding on the VPN gateway are not the same kind of problem, and a merged table makes them look identical.

Better:

Separate sections for external and internal results, each with its own scope statement (which IPs, which subnets, credentialed or not)
External first, because those findings are reachable by anyone
A clear note when one is missing: "This report covers the internal network only. No external scan was performed this month."

That last line is easy to skip and important to keep. A client who reads "no critical findings" on an internal-only report may reasonably assume their internet-facing systems were checked too.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports with a scope statement up front. Your first 3 reports are free, no credit card needed: varaxontech.com.

This post first appeared on the Varaxon Blog. Drafted with AI assistance and reviewed by the Varaxon team.

Risk Acceptance: How to Document a Vulnerability Your Client Won't Fix

Brandon Sooknanan — Thu, 22 Oct 2026 00:50:22 +0000

Sooner or later a client says no. The finance system only runs on an old version of Windows. The vendor won't support the patch. The fix means a weekend of downtime they can't afford this quarter.

That is a legitimate business decision. The problem is what happens next: the finding stays on every report, someone marks it "ignore" in the scanner, and a year later nobody remembers who decided, or why. If that system is ever the way in, "we knew about it" is a hard conversation to have without paperwork.

Risk acceptance is the paperwork. Done well, it takes ten minutes and protects both you and the client.

When acceptance is the right call

Acceptance fits when fixing the finding costs more than the risk it removes, and the client understands that trade. Common cases:

Legacy systems that a business application depends on
Medical, industrial or lab equipment that the manufacturer must patch
Fixes that need budget or downtime the client has deferred
Findings on systems scheduled for retirement soon

It is not the right call when nobody has looked at the finding yet, or when the real reason is that the ticket got lost. That is a backlog, not a decision.

What a risk acceptance record should include

Keep it short enough that people actually fill it in:

Field	What to write
Finding and systems	The vulnerability, its CVE where there is one, and the exact hosts
Why it can't be fixed now	One or two sentences in plain language
What could happen	The realistic consequence, for example "someone on the internal network could take control of the finance server"
Compensating controls	What reduces the risk in the meantime (see below)
Decision owner	A named person at the client with authority to accept business risk
Accepted on / expires on	Dates. Every acceptance should expire
Review trigger	What reopens it early, such as the finding appearing on the CISA KEV list

The decision owner matters most. Your technician can recommend, but only the client can accept risk to their business. An owner, practice manager or IT lead signing their name is what makes it a decision instead of a shrug.

Compensating controls

Acceptance rarely means "do nothing". It usually means "do something cheaper than the fix":

Move the system to its own network segment and limit who can reach it
Block the vulnerable service at the firewall, or allow it only from specific hosts
Turn off the affected feature if the business doesn't use it
Add monitoring or alerting on that host
Restrict which accounts can log in to it

Write down which ones are in place. They also give you something to check at the next review.

Set an expiry, and reopen early when the risk changes

Six or twelve months is a sensible default. When it expires, ask the same question again: can it be fixed now? Often the answer has changed: a vendor released an update, the budget came through, or the system was finally retired.

Some changes should reopen the decision before the date:

The CVE is added to CISA's Known Exploited Vulnerabilities catalog
Its EPSS score jumps, meaning exploitation has become much more likely
The system becomes reachable from the internet
A compensating control is removed

How accepted risks should appear in reports

Accepted findings should stay visible, just in their own place. A separate "Accepted risks" section, with the owner and expiry date next to each one, keeps the main action list focused on work that will happen, while making it clear nothing has been hidden.

In the summary, one line is enough: "Three findings are accepted risks with compensating controls; the next review is due in March." That sentence tells the client you're tracking it, and it reminds them a decision is theirs to revisit.

This post first appeared on the Varaxon Blog. Drafted with AI assistance and reviewed by the Varaxon team.

False Positives in Vulnerability Scans: How to Verify Them Without Hiding Real Risk

Brandon Sooknanan — Thu, 22 Oct 2026 00:50:13 +0000

Every scan has a few findings that make you squint. The web server is flagged for an Apache flaw, but the box runs nginx. A Windows patch shows as missing on a machine you updated yesterday. A client forwards the report and asks, "Is this real?"

Some of those findings really are false positives. Some are not, and calling them false positives is how real risk quietly leaves the report. The goal is not to make the list shorter. It is to make every finding on it true.

Why scanners get it wrong

Most false positives come from a handful of causes:

Version guessing. Without a login, a scanner reads a service banner and infers the software version. Backported patches (common on Red Hat, Debian and Ubuntu) fix the flaw without changing the version string, so the banner still looks vulnerable.
Leftover files. An uninstalled program can leave an old DLL or executable behind. A credentialed scan sees the file and reports the old version.
Pending reboots. The update is installed but not active until the machine restarts. The scanner is right that the old code is still running.
Shared IPs and load balancers. Two different systems answer on the same address across scans, and findings get attached to the wrong one.
Generic checks. Some checks test for a behaviour rather than a product, and match systems that behave similarly but are not affected.

Notice that two of those (leftover files, pending reboots) are not really false positives. The scanner found something true; it just wasn't what you expected.

A four-step check

Run each disputed finding through the same steps, so two technicians reach the same answer.

Read the evidence, not the title. Scanners include the output that triggered the finding: a version string, a file path, a registry key, a response header. Most disputes are settled here.
Confirm on the host. Check the installed package version, the file on disk or the running service directly. For Linux distributions, look up the vendor's security advisory for that CVE, which tells you which package version contains the fix.
Check the scan type. If the finding came from a network-only check, a credentialed rescan of that host is often the fastest way to settle it.
Decide one of three outcomes: confirmed (keep it), false positive (with proof), or true but different (for example, "patched, reboot pending"). The third outcome deserves its own action, not a dismissal.

Record the proof

A false positive without evidence is just an opinion, and it will come back on the next scan. For each one, keep a short record:

Field	Example
Finding	Apache HTTP Server before 2.4.58 (CVE-2023-45802)
Host	web01 (10.0.4.12)
Reason	Host runs nginx 1.24; Apache not installed. Banner came from an old reverse-proxy rule.
Evidence	`dpkg -l` output, screenshot of server headers
Checked by / date	J. Ortiz, 2026-10-14
Review again	Next quarterly scan

That record does three jobs. It saves the next technician from repeating the check, it lets you suppress the finding in future scans with a reason attached, and it gives you something to show an auditor or a client who asks.

How to show false positives in a client report

Leaving them out entirely makes the report look tidier, but it also makes it impossible to check. A better pattern:

Keep the main findings and actions limited to confirmed items.
Add a short appendix listing findings excluded as false positives, each with a one-line reason.
Mention the count in the summary: "Four findings were reviewed and excluded as false positives; details are in Appendix C."

Clients rarely read the appendix. They notice that it exists, and that is what builds trust.

Watch the trend

If one check produces false positives on every scan, fix the cause rather than re-verifying it each month. That usually means turning on credentialed scanning for that host group, cleaning up the leftover files, or adjusting the scan policy. A false positive you suppress with a documented reason is fine. A whole class of them you dismiss by habit is how a real finding slips through.

Varaxon Scan Hub reads exports from the scanners you already use and turns them into clear, client-ready reports that keep the scanner's evidence next to every finding. Your first 3 reports are free, no credit card needed: varaxontech.com.

This post first appeared on the Varaxon Blog. Drafted with AI assistance and reviewed by the Varaxon team.

How to turn a vulnerability scan export into a client-ready report

Brandon Sooknanan — Tue, 20 Oct 2026 00:52:50 +0000

The short version:

Export the scanner's complete machine-readable format (XML, JSON or full CSV), never its PDF.
Check scope, scan date and credential status before you write a word.
Group findings into remediation actions and rank them by known exploitation first.
Lead the report with decisions; move the raw detail to an appendix.

Step 1: export the right file

Every scanner offers a polished PDF and a raw data export. The PDF is designed to be read, so it summarizes; fields such as CVE lists, plugin output or detection details are often trimmed. The raw export keeps everything, which is what you need to build a report you can defend.

The export to use per scanner

Scanner	Export to use	Avoid for reporting
Tenable Nessus	`.nessus` file (XML)	Executive summary PDF or HTML
Greenbone / OpenVAS	Report downloaded in the XML format, with the filter checked	Classic PDF format (why)
Qualys VMDR	Scan results as XML or CSV, or a VMDR CVE / QID data list	PCI and web application reports
Rapid7 Nexpose / InsightVM	XML Export (version 1.0 or 2.0) report	Document-style PDF reports
Nuclei	JSON or JSON Lines output	Plain terminal output
Anything else	The fullest CSV or JSON export the tool offers	Screenshots and PDFs

Microsoft Defender Vulnerability Management and ConnectSecure have no export file to upload. Connect them to Varaxon Scan Hub directly instead, which keeps the complete record including software inventory. Defender needs Microsoft Defender for Endpoint Plan 2, Defender Vulnerability Management or Defender for Servers.

Step 2: check what the scan could see

Before reading findings, confirm the scan's boundary. A report built on a partial scan should say so on the first page.

Scope. Compare the hosts in the export with the client's asset list. A missing server is a gap, not a pass.
Date and feed age. Record when the scan ran and how current the scanner's checks were.
Credentials. Note which hosts were scanned with working credentials. A failed login quietly drops a host to a network-only view; see credentialed vs non-credentialed scans.
Filters. Some exports apply filters at download time, such as Greenbone's Quality of Detection threshold. Make sure nothing was hidden by accident.

Step 3: group findings into actions

Clients do not fix findings; they perform actions. Forty Windows findings across twenty laptops usually collapse into one action: apply the current cumulative update. Group by the remediation, then list the affected hosts under it. This turns a 600-row export into a list of 15 or 20 things to do, which is a list a client can actually schedule.

Keep the evidence attached When you group, keep each action linked to the scanner evidence behind it: the detected version, the plugin or check output, the CVE list. That is what lets a technician verify the fix and lets you answer the client's "how do you know?"

Step 4: put the actions in order

Rank actions by the strongest evidence of real-world risk first. A defensible order:

Anything in the CISA Known Exploited Vulnerabilities (KEV) catalog, with known ransomware use at the very top.
Critical findings (CVSS 9.0 or above) without a KEV match, especially on internet-facing systems.
Other findings with a CVE and meaningful severity, ordered by severity and EPSS.
Findings without a CVE that still matter, such as end-of-life software or weak remote access configuration.
Low and informational items, as context.

The reasoning behind this order is in CVSS vs EPSS vs CISA KEV. Varaxon Scan Hub applies exactly these six bands with deterministic code, so two reports from the same export always agree.

Step 5: write for the person who decides

The first page is for the business owner or IT manager. Say what was scanned, the three to five actions that matter most, what they protect against and roughly what each involves. Leave raw counts of Highs and Mediums off this page: they alarm without informing.

After the summary come the scope and method, the full prioritized action list with owners and target dates, and a technical appendix with per-host detail. The report template guide lists every section and what goes in it.

Step 6: hand over the work, then track it

A report is only useful if the actions become tickets someone closes. Agree target dates with the client (the remediation SLA guide has a starting matrix), create the tickets, and compare the next scan against this one so the client sees what was fixed and what is still open.

Varaxon Scan Hub covers steps 2 to 6 from the uploaded export: it checks coverage, groups and ranks the actions, writes the report, creates reviewed HaloPSA or ConnectWise PSA tickets and tracks each client between scans. See the sample reports, or try it on your own export with the free pre-flight check.

Common questions

Should I send the scanner's own PDF report to a client?

It is better as an appendix than as the report. Scanner PDFs are organized by finding and host, not by the actions the client needs to take, and some omit fields the raw export contains.

How long should a vulnerability report for a small business be?

Keep the decision part to one or two pages: a summary and the prioritized action list. The technical appendix can be as long as the scan requires, because only technicians read it.

This guide first appeared on varaxontech.com.

I'm building Varaxon Scan Hub. It turns exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7, Nuclei, Burp, Defender and other network, host and web scanners into clear, client-ready reports, and can open HaloPSA or ConnectWise tickets after you review them. Your first three reports are free, and a free pre-flight check shows what it can read from your export first.

— Brandon Sooknanan

Founder, Varaxon Technologies