What a Competitor's Login Page Will Tell You If You Ask It Nicely

Sometimes a SaaS vendor publishes their entire customer list without meaning to, and never notices. It shows up in the plumbing of how their product logs people in.

There's one competitor in particular whose customer list I wanted for our revenue team. You can't buy that, and the usual ways of figuring out who uses what came up empty. BuiltWith and the other technographic tools, job postings that name the tool, website fingerprinting. None of it was reliable here. So I came at it from another direction, and their own login page told me.

The one thing enterprise buyers always leave behind

When a big company buys enterprise software and rolls it out org-wide, they don't hand employees a username and password. They wire it into their own single sign-on, the same corporate login they use for everything else. At that size SSO isn't optional. Security and IT mandate it before a tool gets anywhere near the org, and vendors keep it behind the enterprise tier. So when a company has SSO switched on, it means they went through procurement and security review and deployed the tool across the whole org. Those are also the accounts hardest to displace once they're in.

And because of how SSO gets wired up, every one of those customers leaves a small public marker with their own name on it. Find the marker and you've confirmed the customer. The vendor's own login infrastructure tells you.

How the confirmation works

This competitor runs their login on Keycloak, a common open-source identity system. When they turn SSO on for a customer, Keycloak creates a broker entry for that company, addressed by the company's own name in a URL, roughly:

/auth/realms/prod/broker/<company>/endpoint

Only the company part of that URL changes from one customer to the next. So confirming an account is a single request: put a company's name in that slot and read the response code.

• A real customer returns a 400 (sometimes a 502). The entry exists, it just won't talk to you without credentials.
• A company with no account returns a 404. Nothing there.

That's the whole tell. One code for yes, one for no. No login attempt, no password, no data touched. You're loading a public URL and reading what comes back, the same as opening a login page in a browser. Run it down a list and the list sorts itself into customers and non-customers.

I found this by accident, before I had any tooling. I saw the login ran on Keycloak, took one company I knew was a customer and one name I made up, and hit both. 400 and 404. Once a known-good and a known-bad come back different, the rest is just running it against a list. I didn't invent this. Once it worked I asked around and got pointed to Jordan Crawford at Blueprint GTM, who turned this whole class of technique into a discipline years before I stumbled into it.

The specific trick here is Keycloak, but the shape of it is general. Any vendor that supports enterprise SSO has to publicly expose how it routes each customer to their own login, and that routing is the customer list. Some vendors give every customer their own subdomain, like company.zendesk.com or company.atlassian.net, and those you don't even have to guess. You can pull the whole tenant list straight out of public DNS and certificate logs. Others put up a login page that asks for your email first, then sends you to your own company's identity provider. Submit a customer's email domain and watch where it redirects. If it hands you off to that company's Okta or Azure AD or ADFS, they're a federated customer, and you've also just learned what identity stack they run. It looks different from vendor to vendor, but the underlying thing is always the same.

Leaning on work other people already did

I didn't build the probing harness from scratch, and I don't think you should either. Someone in a GTM engineering group I'm in pointed me at an open-source repo (github.com/getaero-io/gtm-eng-skills). What I appreciated is that it doesn't prescribe one method. It hands you a few different ways in, and you pick the one that fits the target:

• Passive harvesting. Pull a vendor's tenants straight out of public subdomain and certificate logs, no company list needed at all. Works when each customer gets their own subdomain and the vendor hasn't wildcarded it away.
• Active slug-probing. Take a list of companies, generate name variations for each, and probe them one at a time against the login endpoint.
• Fingerprinting helpers. crt.sh to read what certificates a vendor issues, and Browserbase to watch a login page's network traffic and see which SSO provider it quietly hands you off to.
• The meta-move. Grab 10–20 companies you already know are customers, hand them to Claude as ground truth, and let it work out which of the above actually gets traction on this particular vendor.

Which of those is useful depends entirely on the vendor you're pointed at, and that's the real lesson. For my target the passive routes were dead ends. It's path-based and runs a wildcard SSL certificate, so there's nothing in DNS or the cert logs to harvest and crt.sh comes back empty. What earned its keep was the active prober: it let me run thousands of guesses at scale without babysitting, turning a manual afternoon into a background job. Point the same toolkit at a vendor that hands each customer a subdomain and the passive route does the whole job instead.

Open source is one of the few unambiguously good things in software, and I lean on other people's work before I write my own. But a repo doesn't know how this specific vendor's customers name themselves. That part I had to build.

Why it comes down to guessing a name

There's one dependency the entire method rests on: the name in that URL has to be human-readable. That's the pre-flight question for any vendor you point this at. Readable slug, you're in business. An opaque internal ID, a random string, or one that rotates on every request, and there's nothing to guess. This competitor used readable names.

The useful part is how you guess. Fuzzing spellings and separators is a waste of time. I never once cracked a company by getting clever with punctuation. The slug is either the obvious form of the name or you don't find it by messing with the name at all. What rescues a miss is trying a different identity the company uses for itself. I ran three passes, each a different identity rather than a different spelling, and stopped the moment one hit:

1. The straightforward name. Domain prefix, or the name with the spaces stripped out. This is the bulk of the hits, a bit over 60%. If it isn't this, tweaking the spelling won't save you. You have to change identities.
2. The first word only. Multi-word companies very often use just their brand name. Its own rung, worth roughly another fifth of the hits.
3. The stock ticker. The one that mattered most. A slice of big public companies use their exchange ticker as the slug, short, unique, already their shorthand. These were completely invisible to name-based guessing. No spelling of the name would ever have found them. The ticker also cleaned up my false positives: a two-letter slug I'd have pinned on a beverage giant turned out to be a chemicals company whose ticker was those exact two letters.

I fed it lists grouped by whatever seemed worth testing — stock indices country by country, then verticals — and let it run.

What it actually said

Two things jumped out, and both changed how I think about competitive research generally.

The first: going after the right vertical beats going broad by about ten to one. When I probed the Fortune 500 as a flat list, the hit rate was around 5 to 6%. When I probed one specific profession — the kind of firm that translates documents all day, contracts and filings and cross-border work — the hit rate was around 67%. Ten times higher. The adjacent advisory field was around half. The lesson isn't complicated once you see it: don't ask "who might use this," ask "for whom is this a daily necessity," then go find those people. The vertical is the signal. The index sweep is noise with a few hits in it.

The second: a vendor's real customer base clusters around wherever they started. This vendor is German, and the map showed it. Their SSO footprint was densest across German-speaking Europe — 15 to 25% hit rates on the home indices — thinned out across the rest of Europe, and then had one big surprise: an unexpectedly strong showing in Japan, second only to the home region. That tracks with their early history there, but I'd never have guessed it from their marketing. Meanwhile the US, their biggest addressable market on paper, sat at around 5%. Southern and Eastern Europe were close to zero. A company's real penetration follows its go-to-market history.

The important caveat: this only works when the plumbing lets it

The whole thing depends on the vendor giving every customer their own addressable surface with the customer's name on it, sitting on public infrastructure. Take that away and there's nothing to enumerate.

The next competitor I tried had taken it away, probably without meaning to. Everyone logs into one shared portal backed by a single central identity server. The only place a customer identifier shows up is an encrypted token that changes on every request, useless as a key. There was no per-customer surface to probe at all. I spent real time confirming it, poking at subdomains and login flows and SAML metadata, and the answer was that this one just isn't enumerable this way. For a vendor like that the signal lives somewhere else, in public contract records, job postings that name them, or their own case studies.

So this is a specific technique that exploits a specific infrastructure choice, and when that choice isn't there, you need a different approach and the discipline to notice quickly and switch.

The outcome

What I ended up with is the thing I wanted: a verified list of companies paying for our competitor's enterprise tier, each one confirmed one request at a time. Every name on it is a hard confirmation.

Why it's worth trying

It's worth trying on whoever you compete with. Run your whole ICP list through the same probe and you find out which of your target accounts are already paying your competitor. Those are the accounts worth going after first, confirmed for you by the competitor's own login page.

The best part is that it's genuinely fun. It feels a bit like hacking, even though all you're really doing is reading infrastructure that's already public. And you don't need to buy anything to pull it off, no third-party data tool or subscription.