MSP pilot guide
Run a pilot on one customer, and judge it on the result.
Seven steps from an authorized scope to a re-checked fix. Each one says what to do, what to look for, and where a Beta integration means a step runs without it.
1. Define the authorized scope
Pick one customer environment you are authorized to assess, and write down the domains, address ranges and sites in it. That list is the scope: nothing outside it is assessed, and assets are marked authorized before anything runs against them.
Look for: A scope small enough to review by hand. A pilot is judged on whether the result is right, and that is easier to tell on an estate you know well.
2. Discover assets
Start external discovery from the customer's domains; it needs nothing installed. For the internal network, deploy the onsite probe. Add endpoint clients only on the machines you choose.
Look for: Assets you did not know about, and assets you expected that are missing. Discovered assets are never billed; only the ones you enrol as managed are.
Beta Endpoint agent assessment, OS client deployment through your RMM, Intune or Jamf. Endpoint clients and deployment through your RMM, Intune or Jamf can be used in a pilot; the integrations page states what each cannot yet do. External discovery and the onsite probe do not depend on them.
3. Collect findings
Exploit Hound assesses the assets it discovered with its own checks. It does not import findings from another vulnerability scanner. An Nmap host list can be imported through an agent, and a directory export can be assessed for Active Directory posture.
Look for: Findings marked by evidence strength: detected, high confidence or safely validated. A finding whose product or version does not match the asset is not applicable, and is not put in the queue.
Beta Active Directory exposure, Entra ID / Microsoft 365 exposure, Cloud posture (Azure, AWS, Google Cloud). Identity and cloud connections can be added during a pilot. Without them, the pilot covers the network and the hosts, and those areas are reported as unassessed rather than as clean.
4. Review the Fix First recommendations
Open Fix First. Each recommendation is an action a technician can take, with the findings it covers, the modeled attack paths it could remove and the named factors behind its position.
Look for: Whether the top of the list is where your own technicians would have started, and where it is not, whether the stated reasons hold up.
5. Compare it with your existing scanner
Export your current scanner's findings for the same scope, and export the findings table from an Exploit Hound report as CSV. Put them side by side.
Look for: Findings one tool has and the other does not, findings Exploit Hound marked not applicable, and how differently the two order the same work. Asset coverage can also be compared: tool reconciliation reports where discovered assets, agents and connected tool inventories disagree.
Beta Tool disagreement reconciliation. Comparing inventories this way is still being validated, and it compares assets, not vulnerability findings. The CSV comparison above does not depend on it.
6. Choose a remediation
Pick one action from the ranked list and agree it with the customer. Change bundle preview estimates what several actions would remove together. Nothing runs on the customer's systems without authorization.
Look for: An action small enough to complete during the pilot, so the next step has something to check.
Beta Change bundle preview, PSA / ITSM ticketing, RMM remediation orchestration. Raising the ticket in your PSA or running the action through your RMM is not yet validated on your instance. Where it cannot be used, the technician makes the change directly; the recheck does not depend on how the change was made.
7. Recheck the outcome
After the change, the exposure is re-checked with the same non-destructive check that found it, and the graph is rebuilt.
Look for: Which exposure actually disappeared. A recheck that could not reach everything is recorded as partial, and what could not be checked is reported as unverified, never as fixed. A closed ticket or a successful RMM job is not treated as proof.
Beta Verification worklist, Monthly customer review. The recheck itself does not depend on them; these are the views that organize the queue and report the result to the customer.
Training the technicians who will do steps 6 and 7: Exploit Hound: tickets, RMM actions and proof of fix, a gr0wpath course on turning the Fix First list into tickets and RMM actions and closing them on a recheck.
Run the pilot with us
A guided evaluation follows these steps on a scope you authorize.