Buyer's guide

The credentialing platform RFP checklist

A copy-paste RFP template for evaluating digital credentialing platforms. Twenty questions across architecture, pricing, security, integration, and recipient experience that separate serious platforms from the rest.

May 23, 2026 8 min read By Credostar Team

A credentialing platform is a multi-year commitment. The credentials you issue today need to remain valuable to recipients in five years, regardless of how the market evolves. The platform you pick should be evaluated on architecture, not features.

This is the RFP template we wish more buyers used. Twenty questions, grouped into five sections. Send them to every vendor on your shortlist; the answers tell you more than any sales deck.

A. Architecture and standards

These questions establish whether a platform meets the bar of being a real credentialing system or is a polished badge editor.

  1. Are credentials issued as W3C Verifiable Credentials by default? Ask for a sample credential as a downloadable JSON file. The type field should include VerifiableCredential; a proof object should be present.

  2. Does the platform support OpenBadges 3.0 natively? OpenBadges 3.0 is the W3C-aligned badge specification. Vendors that only support 2.0 are working from a 2018 architecture.

  3. What proof type does the platform use? Standard answers are Ed25519Signature2020, DataIntegrityProof, or similar. A proprietary proof type is a red flag.

  4. Can a third-party verifier validate a credential the platform issued? This is the test that proves portability. The platform should be able to point you at an open-source verifier, hand you a credential, and have it validate.

B. Pricing and contract

  1. Is pricing per credential issued, per seat, or per subscription tier? Credit-based pricing (per credential issued) scales with what you actually do. Per-seat pricing scales with your recipient list and bills you for credentials you have already paid to issue. For the full argument, see The hidden cost of per-seat credentialing pricing.

  2. Do credits or licenses expire? They should not. Anything you have paid for should remain available indefinitely.

  3. What is the per-credential price at 1,000, 10,000, and 100,000 annual issuance? Get pricing at three volumes so you can model your three-year cost curve.

  4. What happens when you exceed your annual quota? Some platforms throttle issuance; some auto-charge for overage; some require an upgrade. You want a clear answer in writing.

C. Security and compliance

  1. Is the platform ISO 27001 certified? Is SOC 2 Type II in progress or complete? For any organization that issues credentials to professionals or regulated industries, both are minimums.

  2. Where are credential signing keys stored? Acceptable answers reference a managed Key Management Service (KMS): AWS KMS, Google Cloud KMS, HashiCorp Vault, Azure Key Vault. “In the database” is not an acceptable answer.

  3. Is there a full audit log? What is the retention period? Every issuance, every revocation, every administrative change should be logged with actor, timestamp, and IP. 24 months retention is the floor for any audited industry.

  4. What is the SLA on the verification endpoint? Verification gets hit by hiring managers, accreditation reviewers, third-party background checks. Downtime on this endpoint is invisible to you but blocks every verifier in real time.

D. Integration

  1. How are credentials issued in bulk? CSV upload at minimum; API and webhook integrations for any organization with an LMS, CRM, or learning management database.

  2. What LMS / CRM integrations exist out of the box? Even if you do not need them now, integration count is a signal of how much developer attention the platform attracts.

  3. Can credentials be issued via REST API with idempotency? The right answer includes an idempotency key parameter that lets you retry safely.

  4. Is there a webhook for credential lifecycle events (issued, viewed, revoked, expired)? Lets you trigger downstream actions in your own systems without polling.

E. Recipient experience

  1. Can recipients add the credential to LinkedIn in one tap? LinkedIn has a verification protocol that consumes W3C VCs. Test it: ask the vendor to walk you through the flow on a real LinkedIn profile.

  2. Where does the verification page live? Your domain or the vendor’s? If the recipient shares a verification link, whose URL does the verifier see in their browser bar? Hosting verification on your own domain (or a subdomain you control) keeps your brand in front of the verifier.

  3. What does the recipient portal look like? Walk through the experience as if you were a recipient. The recipient experience is the part of the platform you have the least visibility into; it is also the part that determines whether your credentials actually get shared.

  4. Can recipients export their credentials at any time? A recipient should be able to download the raw VC JSON and use it elsewhere without involving you or the platform.

How to use this list

Paste these twenty questions into your RFP document or your procurement email. Demand specific answers in writing, not in a sales call. Compare the responses across vendors side by side.

The platforms that take this exercise seriously will have well-rehearsed answers. The platforms that get defensive about specific questions are the ones most likely to fail you in production.

If you would like to see how Credostar answers each of these, request access to our Design Partner Program and we will send you the long-form responses in writing.

For comparison-focused reading, see Credostar vs Credly, Credostar vs Accredible, and Credostar vs Sertifier. For foundational standards reading, see What are verifiable credentials?.

Keep reading

Related articles

Be one of the first.

We're onboarding a small group of issuers ahead of our Q3 2026 launch. Help shape the product, get founder-level attention, and lock in launch-day pricing.

Apply for early access