Capability

Remediation verification

A closed ticket is a claim. A re-check is evidence, and the two are recorded separately.

Who this is for

MSPs reporting to customers

You are asked whether the thing you billed for actually fixed anything, and a ticket status is not an answer.

Anyone running a monthly patch cycle

You need to know which of last month's fixes silently regressed.

The problem it addresses

Remediation is usually recorded as done when somebody marks it done. The exposure is not re-tested, so a patch that failed to apply, a service that came back on reboot and a change that was reverted all look identical to a fix that worked.

How Exploit Hound handles it

1
The exposure is re-checked, not the ticket
Verification targets are derived from the asset record rather than from the request, and the check is the same non-destructive one that found the exposure.
2
Partial verification is its own state
Where the re-check ran but could not reach everything it needed, that is recorded as partial rather than rounded up to verified or down to failed.
3
Findings are never deleted for falling out of a scan
Every transition is kept, so a finding that reopens is visibly a reopen rather than a new discovery.

What the result rests on

The stored artefact from the original detection, and the artefact from the re-check
The lifecycle state the platform recorded at each transition, with timestamps
Configuration state re-read after the change, for exposures a probe cannot re-test directly
Where an action was dispatched to an endpoint tool, that tool's own result where it publishes one

The words this page uses are defined on the resources page: detected, high confidence and safely validated mean different things, and a claim is never stronger than the evidence behind it.

What is generally available, and what is Beta

Read from the same registry as the integrations page, so this table cannot disagree with it. Implemented and tested, including against recorded provider behavior, but not yet validated against a live vendor tenant.

Capability	Status	Notes
Remediation verified by re-checking	Generally Available
Change detection	Generally Available
Fix First prediction accuracy	Generally Available	Measures predictions somebody acted on, after the exposure graph is rebuilt. Where other remediation was in flight at the same time the paths are reported gone without attributing which change removed them, and no financial value is estimated.
RMM remediation orchestration	Beta	Beta ×4 — NinjaOne, Datto, Syncro, N-able
PSA / ITSM ticketing	Beta	Beta ×5 — HaloPSA, ConnectWise, Autotask, Jira, ServiceNow

In the console

sniff.exploithound.com/remediationDemonstration data · v2.58.16

Remediation verification in the Exploit Hound console: an action, the re-check that followed it, and the exposure state afterwards

The interface is the running application. The data in it is invented — every hostname, finding and customer name shown is fabricated for demonstration, and none of it describes a real estate. The full product tour walks every screen.

See it against your own estate

A guided evaluation runs Exploit Hound against a scope you choose and authorize, and produces a measured result rather than a demonstration.

Request a guided evaluation Pricing Trust Center Integration status Product tour