To Verify or Not to Verify... Is That the Question?

We spend an enormous amount of energy finding and ranking exposures, and almost none confirming whether any of it is real or whether our fixes actually worked. It happens because validation is the hardest and most expensive part of the job. You can automate discovery and prioritization across your whole environment, but proving that a specific exposure is genuinely exploitable, or that a specific fix actually held, takes real effort, real tooling, and often real people. So when time and budget run short, validation is the first thing to get cut. That's a real problem. Validation is what tells you whether your program is actually lowering risk or just generating activity.

If you've spent any time around exposure management, you've seen Gartner's CTEM framework: scoping, discovery, prioritization, validation, and mobilization, running as a continuous loop. It's a good model. But the single validation stage hides something. Validation isn't one activity. It happens at two different moments that answer two different questions. I think of them as pre-remediation validation and post-remediation validation.

Gartner's forecast for how many organizations will adopt exposure validation has climbed from 40% to 60% in just a couple of years. In other words, it's going from something only the leaders do to something everyone is expected to do. The market is consolidating around it too. Gartner recently folded breach and attack simulation, automated pen testing, and continuous red teaming into a single category: adversarial exposure validation (AEV).

Adversarial exposure validation (AEV) is the practice of actively confirming whether exposures are reachable and exploitable before remediation, and whether remediations actually neutralize them after.

The real signal there isn't about any one tool. It's that validation should be thought of as a capability inside a broader exposure management program, not a set of siloed point products you buy and run on the side. The right question stops being "which validation tool do I need" and becomes "how does validation feed off my prioritized attack paths, and feed back into what I remediate." Either way, you're really asking two things:

• Can it prove what's actually exploitable?
• Can it confirm a fix worked?

Those are the two questions we’ll examine in this blog.

Pre-remediation validation: is this actually exploitable?

The first question comes before you spend a dollar fixing anything. You have a prioritized list of exposures, often a long one, and the temptation is to start working it top to bottom. The problem is that a prioritized list is a list of what looks dangerous, not what is dangerous. A critical CVSS score doesn't mean a path to it exists in your environment. A vulnerability buried behind three other controls may be unreachable in practice.

Pre-remediation validation answers a simple question. If an attacker tried this, would it actually work in my environment? You're confirming that the exposure is real, reachable, and exploitable in your specific environment before you commit a remediation project to it. Done well, this does two things. It kills the false positives and unreachable findings that would otherwise eat your team's time, and it sharpens scope on the ones that survive, so the work you do take on is work that matters.

This is also where the attack-path view earns its place. A single vulnerability in isolation might be uninteresting, but the same vulnerability sitting on a chain to a domain controller or a data store is a different animal. Pre-remediation validation is how you tell those two apart, by tracing whether the exposure actually connects to something worth protecting. There's a second payoff here that practitioners feel immediately. A validated "this is genuinely exploitable, and here's the path" is a far stronger case for a maintenance window or funding than any severity score, because you're showing real risk instead of a theoretical one.

Post-remediation validation: did the fix actually hold?

The second question comes after you've acted, and it's the one almost nobody asks honestly. You applied a patch, or more often these days a compensating control. You closed the ticket. But did the fix actually neutralize the attack path, or did it just feel like it did?

This matters more than it used to, for two reasons. First, with the volume of vulnerabilities and zero days we're now dealing with, more remediation is happening through compensating controls than through clean patches, and a misconfigured control gives you false confidence rather than real protection. Second, a fix that closes the path you knew about can leave an alternate path wide open, so "we remediated it" and "the risk is gone" are not the same statement.

Post-remediation validation closes that gap. You re-run the same test you used to prove the exposure was real, and you confirm the attack no longer succeeds. If it still gets through, the ticket isn't done, no matter what the change record says, and it goes straight back into the remediation queue with an owner. That feedback loop is where a lot of programs quietly break, because a closed ticket feels like a closed risk, and the two aren't the same.

It's also worth saying that post-remediation validation isn't a one-time check. Environments drift. A control that validated clean in March can be misconfigured by June, or a new path can open around it. So this isn't a single event at the end of a project. It's a recurring check that runs as the environment changes, which is exactly what the continuous part of continuous threat exposure management is supposed to mean.

How to actually implement both

The good news is that the same techniques serve both phases. The difference is when you run them and what you're asking. Here's how I'd put it into practice.

Start by using your attack-path and vulnerability analysis to scope validation projects, rather than trying to validate everything. You can't, and you shouldn't try. Pull the exposures that sit on paths to your crown-jewel assets, the ones tied to known exploited vulnerabilities, and the ones reachable from a plausible entry point. That set becomes your validation backlog, and it's far smaller and far more useful than your raw findings list.

Then match the method to the target. A few options, roughly from most manual to most automated:

1. Red teams are the deepest form of validation. A skilled human adversary will find the creative, chained, environment-specific paths that nothing else will, and there's no substitute for that on your highest-value targets. The tradeoff is cost and frequency. You can't run a red team continuously, so reserve them for your most critical paths and your highest-stakes assumptions.
2. Automated penetration testing fills the gap between red team engagements. It runs far more often, covers far more ground, and is a genuinely good fit for the narrow, falsifiable question both validation phases ask: with this exposure present, or with this control in place, can the attack still get through? The newer agentic tools can follow chained paths that older scanners miss, which makes them increasingly capable for attack-path validation specifically.
3. Breach and attack simulation, or BAS, is built for the continuous, repeatable case. BAS safely replays known attacker techniques against your environment on a schedule, which makes it well suited to post-remediation validation in particular, because you can re-run the exact same simulation after a fix and watch whether the result changes. It's how you turn validation from a one-time event into an ongoing control.

The important thing is to treat these as one capability, not three competing tools. The strongest programs blend all of them: red teams for depth on the crown jewels, automated pen testing for breadth and frequency, and BAS for continuous regression checking that your controls still hold. And to be clear, this isn't about AI replacing your testers. It's about letting automation handle the scale and the repetition so your people can spend their time on the creative, high-context work only they can do. The model that wins is the one that hands each task to whoever, or whatever, does it best.

So, to verify or not to verify?

It was never really the question. Of course you verify. The real question is when, and how rigorously, and against which exposures. Split validation into its two moments, scope it with your attack paths instead of trying to boil the ocean, and treat red teams, automated pen testing, and BAS as one capability you point at the job in front of you.

A finding you haven't validated is a guess. A fix you haven't validated is a hope. In a world where attackers are getting faster and remediation is leaning ever harder on compensating controls, neither one is good enough. The best programs won't treat validation as the final box to check, they'll treat it as the step that proves everything before it actually worked.

FAQs