Three customer stories show how to keep outdated practices from undermining your CTEM program.
You adopted Continuous Threat Exposure Management (CTEM). So why do the same old vulnerability management habits keep rising from the grave?
AI is adding urgency to a familiar debate: is vulnerability management dead? Discovery, patching, and remediation remain essential. What needs to change is how organizations decide what to fix and establish whether that work reduced exposure.
Yet the way many organizations report progress still rewards the old habits. Reporting day arrives, and there they are: severity scores alone driving priorities, closed tickets standing in for reduced risk, and a smaller backlog passing for proof of security.
Those habits persist because adopting a framework is easier than changing how an organization makes decisions. Completing the work does not prove that it changed what an attacker could achieve.
Throughout this series, we have examined how to operationalize CTEM, why validation matters, and how to measure results. Now comes the practical test: are those principles changing what teams do?
Three customer stories show where to start.
What’s Lurking Behind an Individual Finding?
Remediation queues divide work into individual findings, each with a severity, an owner, and a deadline. That helps organize tasks, but it can separate a weakness from the attack path that makes it consequential.
A major equipment rental company encountered this when an employee started a PHP web server for testing in the root directory. The change exposed SSH key pairs, creating an opportunity for lateral movement. NodeZero® surfaced the issue roughly eight hours after it was introduced.
The problem extended beyond the server configuration. Which systems accepted those keys? What privileges did they provide? What could an attacker reach?
Those answers determine what needs to change. Removing the exposed files, for example, would not address the possibility that someone had already obtained usable keys. Remediation must account for the access those credentials enable.
This matters when security identifies the exposure but infrastructure, application, or identity teams own the fix. Give those teams the attack path, the evidence, and the fix guidance. Each owner should understand how their action contributes to preventing the demonstrated impact.
The same evidence can reveal problems that individual tickets conceal. Repeatedly exposed secrets may point to a deployment practice that needs correction. Repeated privilege escalation may indicate excessive permissions that require broader attention.
That is how one CTEM cycle informs the next. Fix the immediate exposure, then use what you learned to address the conditions that keep producing it.
You Don’t Need to Bury Every Finding to Reduce Exposure
A global investment firm offers a useful challenge to conventional vulnerability reporting.
After remediation, a follow-up NodeZero pentest covering the same scope still identified 46 minor weaknesses. Yet demonstrated impacts fell from 251 to zero. Compromised hosts dropped from 67 to zero, and compromised credentials fell from 52 to zero.
The backlog was not empty. The remediation had still changed what an attacker could achieve in the test.
Vulnerable does not equal exploitable. Exploitable does not equal impact.
For this firm, that distinction was measurable. The same-scope retest demonstrated that the previous compromise outcomes were no longer achievable. The team could show meaningful progress without claiming a flawless environment.
That evidence supports better decisions about the next round of work. Which impacts remain possible? Which critical systems or sensitive data are still reachable? Where would another intervention reduce the greatest exposure?
Remaining findings still need appropriate treatment. Threat intelligence, asset importance, remediation obligations, and changing conditions continue to influence priorities. A test that demonstrates no impact establishes what happened within its scope and conditions. Unresolved weaknesses still need to be tracked and reassessed.
The reporting change is straightforward: explain what the remediation accomplished. If leadership sees only 46 remaining findings, it misses the reduction in demonstrated compromise. If it sees only zero impacts, it may miss the limits of the assessment.
Report both with enough context to support a decision. Track the workload, but measure whether exposure is decreasing.
Did the Fix Work? Will It Hold?
A healthcare software provider demonstrated why remediation needs to include verification.
Initial AWS testing identified 16 weaknesses associated with critical business impacts, including full AWS account compromise and sensitive data exposure. Following remediation, AWS testing identified two low-severity weaknesses that could not be chained into meaningful business impact.
The follow-up test no longer demonstrated the critical compromise outcomes identified initially.
Make that check part of the plan when remediation is assigned. The original attack path shows how the compromise happened. Its associated impact explains why the work matters. Together, they establish what the fix needs to prevent.
Someone still has to own the change, assess operational consequences, and implement it. Someone must also own verification. Agree on those responsibilities before the ticket moves between teams.
If retesting reproduces the original outcome, the work returns with evidence of what remains exposed. If the fix succeeds, the team has a basis for closure.
Then keep testing as the environment changes. New identities, permissions, systems, and connectivity can create another route to the same impact. The next test should establish whether the fix held and whether another path reaches the same outcome.
This is what makes verification useful beyond a single ticket: it tells the organization whether its decisions worked and helps determine where to focus next.
Stop Bringing Old Habits Back to Life
These customers show practical changes teams can make now: connect findings to attack paths, recognize verified improvement despite remaining weaknesses, and carry remediation through verification.
Start with one exposure involving a business-critical system. Review it with the people responsible for making the changes and ask:
- What attack path and impact have we demonstrated?
- Which conditions must change, and who owns those actions?
- What evidence will establish that remediation worked?
- What would trigger testing again?
Then examine what leadership receives. Can the report explain what an attacker could achieve before remediation and what changed afterward? Can it show whether that improvement lasted?
If those answers are missing, use the next CTEM review to change the workflow. Preserve the evidence, assign ownership through verification, and report the result.
Keeping old habits buried takes more than adopting a framework. It takes changing what the organization accepts as proof that security is improving.
Hack. Fix. Verify. Repeat on-demand.
See more in our webinar: Cybersecurity Assumptions Graveyard
Or read more on exposure management here