By Kapil Raval · August 2026 · 4 min read
A buyer sees a badge on a reseller’s website and reads it as a statement about competence. The vendor who issued it was measuring something else entirely. Both are behaving reasonably, and that is the problem.
I wrote recently that trust in enterprise technology has always been carried by the intermediary rather than by the certificate. A reasonable follow-up question is what a vendor is supposed to do about it.
Most vendors already have the instrument. It is the partner program. The difficulty is that almost all of them were designed to drive revenue, and are being read by buyers as though they were designed to convey assurance.
Think about what typically moves a partner from one tier to the next. Revenue attainment. Number of certified individuals on staff. Deal registrations. Marketing commitments. Sometimes a customer satisfaction score, usually collected by the partner.
Every one of those is a reasonable thing for a vendor to want. Not one of them tells a buyer whether this particular firm will configure the system sensibly, explain its limitations, or still be reachable in eighteen months.
Our industry has run this experiment before, at the individual level rather than the firm level.
In the 1990s, the MCSE was a genuine signal. Then demand outran supply, exam content leaked, and a market in brain dumps appeared. Within a few years, hiring managers had learned to discount the credential entirely. Nothing about the curriculum had got worse. What changed was that the certification stopped being scarce.
The CCIE went the other way and held its value for decades, because the lab exam was expensive, slow and genuinely difficult to pass. Cisco constrained supply and the market kept believing the signal.
That is the uncomfortable part for anyone running a partner program. A badge that is easy to earn, and that the vendor benefits commercially from issuing, is structurally the same instrument as self-certification. The vendor is attesting to the quality of its own distribution.
The pattern that separates trust mechanisms that survive from those that become paperwork is whether they lower cost for both the party disclosing and the party receiving. SOC 2 passed that test. Most compliance regimes did not.
Run a partner requirement through the same test and it becomes reasonably easy to tell which ones are worth adding.
A pass-through disclosure obligation passes. Whoever configures the system hands the customer the developer’s documentation plus a short statement of what they changed. That costs the partner a template and ten minutes. It gives the buyer something they cannot obtain any other way. Cheap to produce, valuable to receive.
Another certification exam usually fails. It costs the partner real time and money, and it tells the buyer almost nothing they did not already assume. Cost up on one side, value flat on the other.
Machine-readable attestation, on its own, fails for the mid-market. Cryptographically verifiable evidence is a genuine advance for a counterparty already equipped to consume it. A 200-person manufacturer is not that counterparty. For them, a proof surface is a cost increase on the receiving side, not a reduction. That is the same reason software bills of materials are produced at scale and ingested by almost nobody.
Four changes, none of which require new technology.
Tier on delivered outcomes, not on inputs. Verified customer references, deployments still running after twelve months, renewal rates on partner-sold accounts. Harder to administer than counting exams, and far harder to game.
Make disclosure pass-through a contractual requirement, not a best practice. If it lives in an enablement deck, it is optional. If it lives in the partner agreement, it is not.
Give the buyer somewhere to complain. An assurance nobody can invoke produces no accountability. New York City mandated independent bias audits of hiring tools and published results; a study of 391 employers found fewer than twenty had posted one, and the city’s comptroller later found most complaints never reached the enforcing agency. A partner program with no escalation path outside the partner has the same defect.
Say plainly what the badge does and does not mean. The cheapest fix on this list. If Gold means revenue and training investment, publish that. A buyer who understands the badge is a buyer who will not feel misled later.
For most of the last thirty years, a partner misreading a product meant a deployment underperformed. Increasingly, it means a system makes decisions about people using settings the buyer never saw and the developer never sanctioned.
Regulators are starting to look at the whole chain rather than at the developer alone. When they arrive, vendors will be asked what their partner program actually certifies. The honest answer today, for most programs, is revenue.
The instrument is already built. It just needs to be measuring something a buyer would recognise.