How to evaluate and choose a digital credentials platform
A complete due diligence framework — technical audit, functional validation, blockchain verifiability, master evaluation form, and comparative matrix for universities and educational institutions.
Core idea
Comparing demos, commercial claims, or feature lists is not enough. An institution must demand verifiable evidence: implemented standards, active certifications, functional tests, proven integrations, data architecture, privacy controls, operational continuity, and a real verifiability audit of the credential.
Table of contents
01 · Objectives, scope, and principles
A rigorous evaluation, not a commercial demo.
This document enables universities to evaluate digital credentials platforms with technical, operational, legal, and functional rigor before signing a contract. It can be used as a market guide, internal committee document, due diligence checklist, RFI/RFP form, pilot test basis, or comparison matrix across multiple vendors.
The institution is not just buying a tool to issue visually attractive badges or certificates. It is choosing critical infrastructure for digital reputation, verification, portability, traceability, privacy, employability, academic integration, and future continuity.
Six guiding principles
Prioritize interoperability and portability
The institution must avoid being locked into a vendor or a proprietary viewer.
Distinguish standard, implementation, and certification
Saying a platform 'supports' a standard does not equal demonstrating a real, verifiable implementation.
Evaluate the full product, not just issuance
Analyze issuance, verification, revocation, corrections, recipient experience, integrations, analytics, operational governance, and future exit.
Demand evidence, not just claims
Every relevant claim must be backed by documents, tests, sandbox, logs, certificates, reports, or verifiable references.
Compare against real use cases
Validation must cover concrete scenarios: diploma, micro-credential with skills, stackable badge, LMS/SIS integration, public verification, and revocation.
Decide with weighted criteria
There must be a scoring system, minimum thresholds, and discard red flags.
Ten domains of minimum scope
02 · Recommended selection process
Seven phases. Skipping steps is expensive.
Skipping phases usually results in purchases based on commercial pitch, hidden costs, and painful migrations.
| Phase | Objective | Deliverable | What it validates | Progress signal |
|---|---|---|---|---|
| 1. Internal definition | Align academic, technical, legal, and employability objectives | Prioritized use cases, success criteria, and owners | What you want to issue and why | The institution knows exactly what it needs |
| 2. Initial RFI | Filter vendors that don't meet minimums | Documentary response and evidence | Seriousness, standards, certifications, integrations, and support | Only viable vendors remain |
| 3. Guided demo | Compare real flows under the same script | Demo record with observations | Commercial claims and real UX | Claims are validated against actual product |
| 4. Due diligence | Review security, privacy, architecture, and compliance | Full checklist with traffic-light status | Hidden risks not visible in a demo | Structural weaknesses are detected |
| 5. Controlled pilot | Test with real institutional data and processes | Pilot results and feedback | Real operation, timelines, and adoption | It works in institutional context |
| 6. Economic and contractual review | Understand total cost and future exit | TCO, SLA, DPA, exit plan | Hidden costs, lock-in, and continuity | Economic comparison is realistic |
| 7. Decision and implementation | Choose and start with clear governance | Final matrix and rollout plan | Overall vendor maturity | Start with owners, KPIs, and scope defined |
Practical recommendation
The vendor should not see the full weighting before responding. Evidence first; then the institution applies the scoring. This prevents “optimized” answers without real substance.
03 · What to request from the vendor
The minimum evidence package.
If the vendor cannot or will not provide it, that is already a risk signal.
| Document / evidence | Why it matters | Acceptable if… |
|---|---|---|
| Technical product sheet and architecture | Understand real scope, limits, modules, dependencies, and data model | Describes environments, architecture, main flows, modules, APIs, and dependencies |
| API documentation + sandbox | Validates real integrability | Includes endpoints, auth, examples, rate limits, versioning, and test environment |
| Supported standards matrix | Prevents vague claims | States exact standard, version, scope, and conformance evidence |
| Active certifications list | Proves maturity | Includes body, validity, scope, and audit date |
| DPA/DPSA and privacy policy | Reviews legal obligations | Clarifies roles, sub-processors, international transfers, and data subject rights |
| Sub-processors list | Shows the data treatment chain | Includes vendor, function, country, and contractual safeguards |
| SLA and support scheme | Allows service enforcement | Defines times, channels, severity levels, escalation, and coverage hours |
| Continuity / disaster recovery plan | Evaluates resilience | States backups, RTO, RPO, and periodic testing |
| Pentest report or executive letter | Measures real security | Recent, by independent third party, with documented remediations |
| Reference customers | Contrasts claims with real use | Cases comparable to the institution |
| Exit plan | Prevents lock-in | Explains export, verification continuity, revocations, and exit costs |
merahki.ai + pok.tech
Already know what to ask. We already have the answers.
merahki.ai, powered by pok.tech, delivers the complete evidence package this guide requires: open standards, active ISO 27001, blockchain-verifiable credentials, documented APIs with sandbox, and a clear exit plan.
See the certification solution04 · Evaluation dimensions and required evidence
Ten pillars. Each with documentable evidence.
Information security
- Mandatory MFA for administrative and issuer profiles.
- Role management with least-privilege principle and immediate access revocation.
- Encryption in transit with TLS 1.2+ and encryption at rest, ideally AES-256.
- Auditable logs for access, permission changes, issuance, revocation, export, and critical events.
- Vulnerability scans, external pentests, secure SDLC, code review, and dependency management.
- Incident response plan, clear owners, and notification SLA.
How to validate it
Request a live demo of user creation, role change, and revocation; ask for logs; request evidence of encryption policies and an executive summary of security audits.
Open standards and interoperability
- Open Badges 3.0 implemented natively, not just mentioned commercially.
- W3C Verifiable Credentials when the product claims to issue verifiable credentials aligned to that model.
- CLR when the project needs a broader longitudinal or academic record.
- LTI 1.3, OneRoster, CASE, or other frameworks when the institution needs formal academic integrations.
- European Learning Model (ELM) and Europass compatibility for alignment with the European ecosystem, academic mobility, semantic portability, or issuance of European Digital Credentials for Learning.
- Ability to export in standard formats and validate with independent tools.
How to validate it
For any standard: exact version, concrete scope, issued examples, documentation, external validators, and where it exists, certification or presence in official directories.
Regulatory compliance and certifications
- Active ISO/IEC 27001 for information security management.
- SOC 2 Type II where applicable, covering Security, Availability, Confidentiality, Processing Integrity, and Privacy.
- Compliance with GDPR, LGPD, CCPA, LFPDPPP, FERPA, or other relevant regulations.
- Clear DPA/DPSA, identified sub-processors, and international transfer mechanisms.
How to validate it
Do not accept generic responses like 'we comply with GDPR'. Request contractual roles, policies, data subject rights flows, data map, and concrete mechanisms for deletion, export, and incident response.
Blockchain and verifiability
- Precise statement of which blockchain is used and what function it serves.
- Exact explanation of what is recorded on-chain vs. off-chain.
- Confirmation that no personal data is stored on-chain.
- Public validator and ability for independent verification on an explorer.
- Ability to audit hash, timestamp, status, and traceability of a credential.
Technical product features
- Individual and bulk issuance.
- Templates, branding, multi-language, academic units, and role-based permissions.
- Skills, competencies, outcomes, evidence, rubrics, pathways, stackability, and credential relationships.
- Revocation, expiration, renewal, reissuance, controlled correction, and versioning.
- Recipient wallet or locker, sharing, download, public verification, accessibility, and mobile experience.
- Operational analytics and reports useful for academic and employability management.
Integrations and APIs
- Documented APIs with clear auth, sandbox, examples, rate limits, versioning, and backward compatibility.
- SSO with SAML 2.0, OAuth 2.0, or OpenID Connect as applicable.
- LMS, SIS, CRM, ERP, HRIS, assessment platforms, and messaging.
- Webhooks or events for issuance, revocation, claim, expiration, or other flows.
- LTI 1.3 and other edtech frameworks when applicable.
Privacy and data management
- Exact map of personal and academic data: required, optional, and derived.
- Data location by environment and by customer.
- Retention, deletion, correction, anonymization, export, and right of access.
- Explicit consent when applicable and auditable record of that consent.
- Ability to separate verification continuity from personal data deletion.
Cloud infrastructure
- Hosting region or country.
- Redundancy, backups, high availability, and multi-tenant or single-tenant architecture.
- RTO, RPO, operational continuity, and disaster recovery testing.
- Secrets management, key management, and separated environments.
Monitoring and audit
- Log retention period and detail level.
- Security alerts and traceability of administrative actions.
- Log integrity, exportability, and forensic analysis support.
- Monitoring panels or reports available to the institution.
Operational sustainability
- Clear and consistent product roadmap.
- Support team and real implementation capacity.
- Business viability and vendor continuity.
- Community, partnerships, references, and service stability.
05 · How to validate declared features
Two vendors can say “yes” to the same thing and offer radically different products.
A feature should only be considered available if it was both documented and demonstrated end-to-end.
- Require a demonstration based on a common script prepared by the university.
- Request temporary access to a sandbox or test tenant.
- Ask for documentation, screenshots, short video, or walkthrough for each critical feature.
- Use an institution-specific test case with real or semi-real data.
- Verify the feature end-to-end: configuration, issuance, student experience, external verification, post-correction, and administration.
- Record evidence in a record with traffic-light status: available, partially available, requires additional development, depends on partner/professional services, or not available.
- Do not score roadmap, marketplace items, or third-party dependencies as natively available features.
Nine tests with 0–5 score
| Critical feature | Required test | Expected result |
|---|---|---|
| Bulk issuance | Issue a real batch with a test file | Issued correctly with traceability and controlled errors |
| Public verification | Validate credential without login from external link | Clear, public, and consistent verification |
| Revocation | Revoke and re-validate | Status changes correctly and is audited |
| Correction / update | Edit allowed field or reissue per policy | History trace and coherence maintained |
| Skills / competencies | Map skill, level, evidence, and criteria | Structure is visible and verifiable |
| LTI / LMS | Launch from LMS and capture context | Flow works with declared standard |
| Issuance API | Issue via API with test credentials | Issuance works with documented auth and response |
| Analytics | Extract dashboard or useful report | Data is usable for management |
| Export | Download data and credentials | Format is standard and usable |
06 · Technical audit and blockchain verifiability
The word “blockchain” is often used without technical rigor.
Critical warning
This section describes how to audit whether a credential was actually registered correctly and verifiably — or whether the vendor is only presenting a marketing narrative.
6.1 · Seven non-negotiable questions for the vendor
- Which blockchain exactly? Ethereum, Polygon, LACNet, Bitcoin, Solana, Hyperledger, private chain, sidechain, or other.
- Who operates the nodes and whether the network is public, permissioned, or fully private.
- What data is recorded on-chain: hash, identifier, cryptographic proof, contract event, minimal metadata, or the full credential.
- What data is stored off-chain and where it is hosted.
- How is integrity validation performed for a credential and how is revocation proven.
- How does it avoid storing personal data on-chain.
- What is the relationship between the credential viewer, the validation button, and the transaction shown on the explorer.
6.2 · Mandatory on-chain audit procedure (10 steps)
The university must open a real credential from the vendor, validate it using the validation button, then click the hash, icon, or blockchain link shown on the credential, and verify in the explorer that the transaction was correct. The transaction must not be in a failed, reverted, or dropped state.
Open a real credential from the vendor — preferably a public credential issued by a client or by the vendor itself.
Use the credential's validation button. The validator must confirm the credential's status and expose, directly or indirectly, the link to the cryptographic proof or transaction.
Click the hash, icon, or blockchain link shown on the credential or validator. That link should lead to a blockchain explorer or equivalent publicly verifiable reference.
Once in the explorer, verify that the transaction exists and its status is successful. It must not appear as failed, reverted, dropped, cancelled, or equivalent states for that chain.
Review the transaction hash, timestamp, block, address or contract involved, and consistency with the credential's issuance date.
Review all relevant tabs in the explorer: Overview, Logs, Token Transfers, Internal Transactions, Events, or State. Do not stop at the transaction's overview page.
Confirm there is no misleading situation where the explorer shows a failed transaction, no token transfers, or failed internal transactions.
Verify that the recorded data or emitted event is reasonably connected to the audited credential. If the vendor only shows a generic explorer link with no way to connect it, that proof is insufficient.
Repeat the validation on more than one credential if possible: one active, one revoked, and one recently issued.
Document screenshots, URLs, transaction status, and any inconsistencies detected.
6.3 · Explorer review operational matrix
| Element | What should be visible | Red flag |
|---|---|---|
| Status | Success, confirmed, or equivalent. The transaction must exist and have been processed correctly. | Failed, reverted, dropped, cancelled, indefinite pending, or unexplained error. |
| Token Transfers | Only if the model actually implies minting or transfer. Must be consistent with the audited credential. | No transfers when vendor claims minting/NFT; transfers inconsistent with date, contract, or recipient. |
| Internal Transactions | Must be consistent with contract logic, or absent if the architecture doesn't use them. | Failed internal transactions, reverts, or inconsistent traces without sufficient technical explanation. |
| Logs / Events | Contract events or logs that link the on-chain evidence to the credential. | No way to connect the credential to the event, or logs contradict the viewer. |
| Timestamp, block, and contract | Must be consistent with issuance date, network, and contract declared by the vendor. | Relevant time differences, unidentified contract, or different network than declared. |
Not all architectures register a credential as a token transfer. Some only record hashes, events, or cryptographic proofs. Verification is not about “seeing an NFT” — it is about confirming that the real on-chain proof exists, was successful, and is consistently linked to the audited credential.
6.4 · Six minimum practical verifiability tests
Test 1
Test credential generation
Request a test credential, download it or view it in the viewer, and extract its identifiers.
Test 2
Independent hash or txid verification
Use the explorer directly — do not rely solely on the vendor's viewer.
Test 3
Cryptographic signature validation
Or verifiable structure validation where the standard allows it.
Test 4
Revocation
Revoke the test credential and confirm that the status changes in the validator and, when applicable, in the on-chain evidence.
Test 5
Public validator
Confirm a third party can verify the credential without login and without exposing unnecessary data.
Test 6
Portability
Export the credential or its metadata in standard format and confirm it remains usable.
6.5 · Nine blockchain-washing red flags
07 · Red flags and discard criteria
Situations that justify stopping an evaluation.
Unless the vendor can address them with strong, verifiable evidence.
merahki.ai + pok.tech
None of these red flags apply to us.
Full technical documentation. Auditable blockchain trail on public explorers. Active ISO 27001. DPA-ready. APIs with sandbox. A clear exit plan — all verifiable, no commercial pitch needed.
Verify it yourself08 · Master institutional evaluation form
How to score each item.
This battery can be used as an RFI/RFP or due diligence form. Responses should include attached evidence, and each item marked as: Documented · Demonstrated · Certified · Pending · Not available.
Product and functional scope
What types of credentials does the platform issue and manage?
Does it support individual and bulk issuance, renewal, expiration, revocation, reissuance, and versioning?
Does it support skills, competencies, learning outcomes, evidence, rubrics, or alignments?
Does it support pathways, stackability, equivalencies, or relationships between credentials?
Does it support multiple brands, academic units, campuses, languages, and role-based permissions?
Standards and interoperability
Which standards does it support exactly? State version and scope: Open Badges, W3C Verifiable Credentials, CLR, European Learning Model (ELM), Europass / European Digital Credentials for Learning, LTI, OneRoster, CASE, or others.
Can the vendor demonstrate semantic compatibility and/or practical interoperability with Europass or ELM? Attach field mapping, issued examples, validation, and functional evidence.
Which parts of the standard are natively implemented vs. require additional development?
Is there external certification, validation, or presence in official directories?
How is cryptographic verification, revocation, and portability between systems handled?
What dependency exists on proprietary viewers or wallets?
Integrations
What APIs are available? Attach documentation, auth, rate limits, and versioning.
Are there webhooks, queues, scheduled exports, or native connectors?
Which integrations exist with LMS, SIS, CRM, ERP, HRIS, assessment platforms, and SSO?
Does it support SAML, OAuth 2.0, OpenID Connect, or SCIM where applicable?
How are students, courses, results, cohorts, and changes synchronized?
Security
Is MFA required for administrators and issuers?
How is privileged access, tenant segregation, and immediate user revocation managed?
What encryption is used in transit and at rest?
Are auditable logs maintained? For how long? How is integrity and monitoring guaranteed?
How often are vulnerability scans and external pentests performed?
What secure SDLC, code review, dependency management, and CI/CD practices are applied?
What is the incident management and customer notification process?
Privacy and data
What personal and academic data is stored exactly? Separate required, optional, and derived.
Where is data hosted by environment and by customer? State country or region.
Who are the sub-processors and what role do they play?
How are retention, deletion, anonymization, correction, and export managed?
What mechanisms are used for international data transfers?
How is GDPR, FERPA, and applicable local legislation addressed?
Operation and service
What is the standard SLA and what does support include?
What language and time zone does support cover?
How is implementation done, how long does it take, and what depends on the customer?
What training is offered to administrators, issuers, and internal support?
What comparable references can they share?
Contract, costs, and exit
Describe the pricing model and all billable components.
State usage limits: storage, issuers, templates, integrations, wallets, analytics, and environments.
What happens at contract end for verification, hosting, and data export?
Is there a cost for migration, exit, or verification continuity?
Does the university retain ownership and control over its data and metadata?
09 · Demo, pilot, and testing script
Twelve steps of the pilot.
Configure a credential with institutional branding, metadata, criteria, and evidence.
Issue an individual credential and a bulk batch.
Assign skills or competencies and display them in the credential or its detail view.
Perform claim by the recipient and share it externally.
Verify the credential from outside the platform.
Audit the validation button and blockchain/explorer link where applicable.
Revoke a credential and verify the status change.
Correct an allowed field and review the audit trail.
Consume a sample API or webhook.
Show role permissions and segregation by academic units.
Export data, metadata, and relevant evidence.
Test accessibility, mobile experience, and multi-language where required.
10 · Scoring methodology
Scale 0 – 5.
Scoring must only be applied to documented and demonstrated features or controls. Roadmap items do not count as current availability.
| Score | Meaning | Interpretation | Acceptance |
|---|---|---|---|
| 0 | Does not comply | Not implemented or explicitly unsupported | 🔴 Rejection |
| 1 | Very weak / roadmap | Promised or partially conceptual | 🟠 Do not count as available feature |
| 2 | Partial | Exists with significant limitations | 🟠 Requires additional investigation |
| 3 | Adequate | Correctly implemented with sufficient evidence | 🟣 Meets minimum |
| 4 | Solid | Robustly implemented with auditable maturity | 🟢 Very good level |
| 5 | Excellent | Exceptional, transparent, leading implementation | 🟢 Clear strength |
Suggested weighting by dimension
| Dimension | Weight | Min. threshold |
|---|---|---|
| Standards and interoperability | 20% | ≥ 3/5 |
| Product features | 20% | ≥ 3/5 |
| Security | 15% | ≥ 4/5 |
| Privacy and data | 15% | ≥ 4/5 |
| Blockchain and verifiability | 10% | ≥ 3/5 |
| Integrations and APIs | 10% | ≥ 3/5 |
| Operations and support | 5% | ≥ 3/5 |
| Total economics | 3% | ≥ 3/5 |
| Exit plan / no lock-in | 2% | ≥ 3/5 |
Suggested formula
Final score = Σ (dimension score × weight)Interpretation
- ≥ 4.0 · recommended
- 3.0 – 3.9 · acceptable with reservations
- < 3.0 · not recommended
Governance rule
Even if the overall score is high, a vendor should not pass if it does not meet minimums in security, privacy, or verifiability.
11 · Economic, contractual, and exit plan evaluation
Total cost, real TCO, and exit.
- Review pricing per issuer, per student, per credential, per module, per integration, or per storage.
- Identify hidden costs: implementation, branding, APIs, analytics, premium support, migration, wallet, templates, environments, and training.
- Require SLA, DPA, liability limits, sub-processors, continuity, backups, and incident handling.
- Confirm what happens at contract end: data export, revocations, verification continuity, costs, and delivery format.
- Verify that the university retains ownership and control over its data, metadata, and evidence.
12 · Final institutional recommendation
Do not choose based on aesthetics or commercial pitch.
A university should choose a platform based on demonstrated capacity to issue, verify, integrate, preserve, protect, and govern credentials and data with open standards, verifiable evidence, and an understandable total cost.
Best practice is to combine documentary form, guided demo, due diligence, real pilot, weighted scoring, and contractual review. When a vendor truly has the capability they claim, this process strengthens their case. When they don't, this process exposes it.
Every mature evaluation should include the practical audit of a real credential and its validation evidence. If the credential cannot be verified reliably and independently, the promise of verifiability is seriously undermined.
Annex A · Quick discard checklist
Eight traffic-light questions.
If the answer is no to any of these questions and the vendor does not provide evidence of immediate remediation, the platform should move to discard or pause status.
Annex B · RFI / RFP template
Ten blocks of an RFI / RFP.
Annex C · Standards and frameworks references
Official sources consulted.
1EdTech Consortium — Open Badges. Official standard page and implementation resources.
www.1edtech.org/standards/open-badges
1EdTech — Open Badges Certification Process. Official conformance certification process.
www.1edtech.org/certification/open-badges
1EdTech — TrustEd Apps Program. Official directory of products with verified certification/interoperability.
www.1edtech.org/program/trustedapps
W3C — Verifiable Credentials Data Model v2.0. Official recommendation published May 15, 2025.
www.w3.org/TR/vc-data-model-2.0
Europass — European Digital Credentials. Official infrastructure for creating, issuing, storing, sharing, and verifying European digital credentials.
europass.europa.eu/en/european-digital-credentials
Europass — EDC for Learning. Official definition of European digital credentials for learning.
europass.europa.eu/en/european-digital-credentials-learning
Europass — Information for Developers. Technical documentation for the Europass ecosystem.
europass.europa.eu/en/information-developers
Europass — European Learning Model (ELM) Browser. Official European data model for learning and credentials.
europa.eu/europass/elm-browser/index.html
Europass — Latest developments to the European Learning Model.
europass.europa.eu/en/news/latest-developments-european-learning-model
OWASP — Application Security Verification Standard (ASVS).
owasp.org/www-project-application-security-verification-standard
OWASP — Authentication Cheat Sheet.
cheatsheetseries.owasp.org
NIST — SP 800-218 Secure Software Development Framework (SSDF).
csrc.nist.gov/publications/detail/sp/800-218/final
EUR-Lex — Regulation (EU) 2016/679 (GDPR).
eur-lex.europa.eu/eli/reg/2016/679/oj
Etherscan Docs.
docs.etherscan.io
References consolidated from official sources of 1EdTech, W3C, and OWASP reviewed in March 2026. Always verify the validity of certifications, standard versions, and technical evidence directly from official sources at the time of purchase.
Don't buy declarations.
Buy evidence.
merahki.ai · Complete Guide · v1.0 · April 2026
Is your institution evaluating digital credentials platforms?
The merahki.ai team can help you apply this evaluation framework and find the right solution for your use cases.
30-min personalized walkthrough
A tailored demo of the platform matched to your specific use case.
Talk to an expert, not a sales rep
You'll speak with someone who deeply understands education-led growth.
Implementation roadmap included
Walk away with a clear plan for launching your first program.
Used by teams in 8+ industries
From healthcare to SaaS — we've seen and solved your challenges.
