If you’ve been working with vulnerability scanners for a while, you know the pattern: run a scan, get a giant list, sort by severity, and start chasing reds.
It works—until it doesn’t.
Because the reality in 2026 is this: vulnerability data is exploding, attacker behavior is changing fast, and the scarcest resource in most IT teams is not tooling… it’s time.
That’s why Guardian360 is making two big changes to Lighthouse:
- We are replacing our scanner arsenal (our scanning “engine room”).
- We are introducing a risk-based approach that connects technical findings to business risk—aligned with ISO 27001, NIS2, and other frameworks.
And yes: for many partners and customers, this will raise a fair question:
“Are we going to see fewer vulnerabilities… and is that actually safe?”
Let’s unpack the “why” behind these decisions—and why fewer, more relevant findings typically leads to better outcomes, better insights, and a much more effective use of expensive hours.
1. Why we’re replacing our scanner arsenal
We’re rebuilding the foundation to make scanning:
- More reliable (consistent results, fewer edge-case surprises)
- Faster (less waiting, more continuous visibility)
- Lighter (lower footprint and operational overhead)
And there’s a strategic reason, too:
Moving beyond virtual machines toward an agent
Today, many scanning solutions still rely heavily on virtual machines and heavyweight deployments. Our direction is clear: enable agent-based capabilities, so partners and customers can get coverage without always needing to maintain virtual appliances as the default approach.
This is not change for the sake of change. It’s about building a scanning platform that is ready for the next phase of Lighthouse: continuous insights, lower operational friction, and more actionable results.
2. Why we’re introducing a risk-based approach (and why it fits ISO 27001 and NIS2 better)
Most scanners are built to answer a technical question:
“How severe is this vulnerability?”
But ISO 27001, NIS2, and modern security governance require you to answer a different question:
“So what does this mean for our organization, and what do we do first?”
That shift matters, because technical severity alone doesn’t describe business risk. Business risk depends on context: where the vulnerability lives, what it touches, and what happens if it’s abused.
CIA: the missing ingredient in “severity-only” vulnerability management
A practical way to make that context explicit is the classic CIA triad:
- Confidentiality: would exploitation expose sensitive information (client data, IP, credentials, medical records)?
- Integrity: could exploitation allow tampering (changing data, manipulating transactions, altering configurations, poisoning logs)?
- Availability: could exploitation cause downtime or disruption (ransomware impact, service outage, production stoppage)?
In other words: the same CVE can mean very different things depending on the asset’s CIA profile.
Example: same vulnerability, different business risk
A “high severity” vulnerability on a low-value test server might be annoying—but not business-threatening.
That exact same vulnerability on:
- a system that processes payroll (integrity),
- a customer portal with personal data (confidentiality),
- or a hospital-critical application (availability),
…is suddenly a material business risk.
So rather than treating every finding as equal and sorting purely by CVSS, a risk-based approach asks:
- Which asset is affected?
- How critical is that asset to confidentiality, integrity, and availability?
- Is it reachable / exploitable in this environment?
- What is the real-world impact if it’s abused?
- What’s the most effective next action?
Why this fits ISO 27001 and NIS2 better
ISO 27001 is not a “collect all vulnerabilities” standard. It’s about running an ISMS that identifies, assesses, and treats risk in a controlled, repeatable way. A risk-based approach supports that directly: you can show why you prioritized something, what you did, and how it reduced risk.
NIS2 pushes organizations toward measurable resilience and accountable risk management, not just technical output. A risk-based approach helps partners and customers communicate in business terms—because boards and auditors don’t want “we had 8,000 findings,” they want “we reduced risk to critical services.”
The outcome: better decisions, better evidence, less wasted effort
By linking findings to CIA and business context, Lighthouse can shift from:
- “Here’s a scary list”
to:
- “Here are the issues that endanger what you actually care about—and here is the smartest order to fix them.”
That’s the core of the risk-based approach: not fewer controls, but better prioritization and stronger governance.
3. The uncomfortable truth: not every CVE matters to your environment
Here’s the part that often gets lost in vulnerability management: the CVE universe is enormous, and most of it will never matter to your specific customer environment.
- The National Vulnerability Database (NVD) lists hundreds of thousands of CVEs (over 326k at the time of writing)( https://nvd.nist.gov/general/nvd-dashboard).
- Meanwhile, the CISA Known Exploited Vulnerabilities (KEV) catalog—a practical “this is exploited in the wild” reference—contains around 1,484 entries (end of 2025 reporting)( https://www.securityweek.com/cisa-kev-catalog-expanded-20-in-2025-topping-1480-entries).
That contrast doesn’t mean “ignore everything else.” It means:
Severity is not the same as risk
A CVSS score tells you how bad something could be under certain assumptions. It does not tell you how likely it is to be exploited in the next days or weeks.
That’s why models like EPSS exist: to estimate exploitation probability based on observed signals and patterns. FIRST’s EPSS documentation illustrates how exploitation activity tends to concentrate in a small subset of published CVEs (their example shows ~2.7% with observed exploitation activity in a 30-day window)( https://www.first.org/epss/model).
And threat reporting continues to show that exploitation is a major initial access vector—but again, concentrated where attackers get the best ROI. Verizon’s 2025 DBIR highlights exploitation of vulnerabilities as a leading breach vector (20%) and notes a significant increase year-over-year (https://www.verizon.com/about/news/2025-data-breach-investigations-report).
So yes: vulnerabilities matter. But not equally, and not all at once.
4. Why “fewer vulnerabilities” can lead to better security outcomes
A massive list of findings creates three predictable problems:
1) Noise buries signal
When everything looks urgent, nothing is urgent. Teams burn cycles triaging items that are technically valid but practically irrelevant.
2) Time gets spent on what’s easy, not what’s risky
Without business context, remediation becomes a patching popularity contest: “highest CVSS first,” even if the affected system is non-critical or unreachable.
3) Reporting becomes performative
You end up proving you worked hard, instead of proving you reduced risk.
A risk-based approach flips this:
- Focus on what’s exploitable, reachable, and material
- Tie findings to business impact
- Make remediation measurable, explainable, and auditable
This is how you make vulnerability management sustainable—not heroic.
5. What partners can expect in Lighthouse
With the new scanning foundation and risk-based approach, partners will get:
- Better insight into business risk (in addition to technical severity levels)
- More relevant scan results, reducing wasted effort
- More effective remediation, because actions are prioritized by real-world risk and business context
- Stronger compliance evidence, because decisions and actions can be explained and mapped to governance requirements
This is how we give practical meaning to our mission:
“Digital governance and resilience within reach.”
And our vision:
“Empowering decision makers with insights to secure, comply, and optimize their business.”
6. The bottom line
We’re not aiming to show more findings.
We’re aiming to show the right findings, at the right moment, in the right context—so partners and customers can spend their limited time where it reduces risk the most.
If you’re used to scanners that proudly display “10,000 issues found,” this shift might feel counterintuitive at first.
But in practice, less noise + more relevance = better insight + faster risk reduction.
And that’s exactly where Lighthouse is heading.
