How to Evaluate a Credential Exposure Monitoring Vendor: the RFP checklist

Credential exposure monitoring is the continuous search of breach dumps, criminal markets and infostealer logs for an organization's leaked passwords, session cookies and tokens, so a security team can revoke them before an attacker logs in. Verizon's 2025 DBIR ranked credential abuse the top initial-access vector, present in 22% of breaches. When you evaluate a vendor, the question is not whether it collects data but whether it surfaces your exposure instead of a firehose of generic noise.

What does credential exposure monitoring actually do?

It detects your leaked authentication material before it is used against you. The service ingests breach databases, forum and market listings, closed channels and infostealer stealer-logs, then matches what it finds against assets you own, such as domains, employee emails, passwords, session cookies and API tokens. Verizon's 2025 DBIR put credential abuse at the top of the initial-access list, present in 22% of breaches (Verizon 2025 DBIR). The job of the tool is to turn that exposure into a revoked credential before the login happens.

The high-value data lives in stealer logs pulled off infected devices, not in old public dumps. Flashpoint counted more than 11.1 million devices infected by infostealers, spilling over 3.3 billion credentials, session cookies and cloud tokens into illicit markets (Flashpoint). This is why credential exposure monitoring is narrower and more operational than broad dark web monitoring: it resolves exposure to specific identities and sessions you can act on, rather than reporting general chatter.

The evaluation criteria that actually predict value

Relevance predicts value; raw collection does not. Every serious vendor ingests millions of sources, so volume tells you nothing about whether a feed helps your team. SpyCloud recaptured 53.3 billion distinct identity records in 2024, up 22% year over year (SpyCloud 2025); no SOC can triage a fraction of that without hard scoping. The matrix below weights the criteria that separate a usable feed from a firehose. Adjust the weights to your environment, but keep relevance and session coverage at the top.

Notice where the weight sits. Relevance and session coverage carry 40% between them because they decide whether your team acts on the right exposure fast enough. Speed underwrites the rest: Mandiant's M-Trends 2025 put the global median dwell time at 11 days (Mandiant M-Trends 2025), and IBM measured the average breach lifecycle at 241 days, the shortest in nine years but still long enough for an exposed credential to be sold and reused many times over (IBM 2025).

What should your RFP ask each vendor?

Send the same concrete questions to every bidder so the answers are comparable, not the sales decks. Speed is the outcome you are buying: with median dwell time at 11 days (Mandiant M-Trends 2025), the difference between a same-day alert and a two-week-old one is the difference between a revoked password and an incident. Ask each vendor to answer in writing, with numbers where a number exists:

• When a credential for our domain lands in a stealer log, what is your median time from log trade to our alert? Give the number in hours, not adjectives.
• Do you parse stealer logs for session cookies and auth tokens, or only passwords? Show a redacted sample record.
• How do we verify domain ownership, and can we scope results to assets we own without sending you any passwords, cookies or tokens?
• For a single record, can you show origin, collection date and a chain of custody or hash so our IR and legal teams can trust it?
• In a typical tenant, what share of alerts name an asset the customer owns versus generic combolist noise, and how do you measure that?
• How do findings reach our stack: native SIEM (Splunk, Sentinel), SOAR, ticketing (Jira, ServiceNow), plus a documented API and webhooks?
• How do you dedupe and age records so we are not re-alerted on the same exposure week after week?
• For MSSPs or multi-brand groups, how do you separate tenants, and can one analyst work many tenants without data bleed?
• Where is our data stored and for how long, and what is your deletion process for GDPR and LGPD requests?
• Do you collect first-hand, or resell another vendor's feed? Name any upstream providers.
• Can we run a two-to-four-week proof of value seeded with our real domains before we sign?
• Is pricing per seat, per domain, per alert or per tenant, and what changes at renewal?

How do you run a proof of value against your own assets?

Seed each tool with your real domains and measure two things: how many alerts name assets you own, and how fast they arrive. A vendor demo on a canned tenant proves nothing about your exposure. Verizon found 54% of ransomware victims had credentials sitting in infostealer logs before the attack (Verizon 2025 DBIR analysis), so a proof of value that surfaces even one live corporate session for your domain has already paid for the exercise.

Score the pilot against the matrix, not against gut feel. Track the on-asset alert ratio, the count of live session cookies found (not just leaked passwords), the median time-to-alert, and whether verification worked without you handing over credentials. A low-noise, asset-scoped and session-aware approach, such as Ashetrace's, should show a high on-asset ratio and cookie coverage in the pilot; a firehose will bury the same signal under generic combolists. Write the numbers down for each bidder and let the matrix rank them.

Red flags to watch in a vendor pitch

Watch for pitches that optimize the demo rather than your outcome. With 3.3 billion credentials, cookies and tokens circulating in illicit markets (Flashpoint), any vendor can show you a scary-looking hit; the test is whether the hit is yours, provable and actionable. The following patterns should lower a vendor's score:

• The pitch leads with source count ("we monitor a million sources") instead of how many alerts will actually name your assets.
• Coverage is passwords only, with no parsing of session cookies or tokens from stealer logs.
• You are asked to upload employee passwords or cookies so the vendor can match exposure.
• A record has no provenance: no origin, no collection date, no way to verify it before you act.
• Alerting is email-only, with no SIEM, SOAR, ticketing connector or documented API.
• The proof of value runs only on the vendor's demo tenant, never on domains you own.
• One shared inbox covers all your business units or clients, with no tenant separation.
• The vendor is vague about where data is stored, how long it is kept, or how deletion works.