Security
How Incredify protects the credentials, identities, and data entrusted to us by institutions and their learners.
Last updated: June 2026
Security Overview
Incredify is a digital credentialing platform built on the Open Badges 3.0 and W3C Verifiable Credentialsstandards. Every badge is cryptographically signed with an Ed25519 key tied to the issuing institution's domain. Security is embedded in the architecture: credential integrity does not depend on trusting Incredify — it depends on math anyone can verify.
This page describes the technical controls we have implemented. It is written for institutional procurement teams, information security officers, and technical evaluators. We state what is implemented as fact and what is planned as aspiration — we do not overstate our posture.
Data Protection
Signing key encryption
Each institution's Ed25519 private signing key is encrypted with AES-256-GCM before being written to the database. The encryption key is derived from a secret not stored alongside the ciphertext. Keys are service-role access only — no client-side RLS policy exposes them.
Recipient data
Recipient email addresses are stored and used only to deliver badge notifications and to identify issuances within an institution's account. Recipients never need to create an Incredify account and are not marketed to. Badge claim pages are public URLs, but they contain no PII beyond what the issuer explicitly includes in the credential.
Encryption in transit
All traffic to incredify.net and its subdomains is served over TLS 1.2 or higher with HTTP Strict Transport Security (HSTS) enabled. Connections over plain HTTP are redirected to HTTPS.
Encryption at rest
Database storage is encrypted at rest by our infrastructure provider (Supabase / AWS). Signing keys receive an additional application-layer encryption pass (AES-256-GCM) before storage — so a database-level breach alone cannot expose usable signing material.
Authentication & Access Control
OTP email authentication
Issuer staff log in via a one-time code sent to their email address. There are no passwords to phish, reuse, or breach. OTP codes are short-lived and single-use.
SAML SSO (Enterprise)
Enterprise institutions can configure SAML 2.0 single sign-on with their existing identity provider (Okta, Azure AD, Shibboleth, etc.), enforcing their own MFA and session policies.
Role-based access control
Members are assigned Admin or Issuer roles per institution (and optionally per sub-organization). Issuers cannot modify institution settings or manage other members. Super-admin access is restricted to Incredify operations staff and gated by an allowlist.
Row-level security tenant isolation
Every table in the Incredify database enforces PostgreSQL Row-Level Security (RLS). Institution data is isolated at the database layer — a session authenticated as Institution A cannot read or write Institution B's rows, even if application logic were bypassed.
Recipients require no account
Badge recipients never authenticate to Incredify. Claim pages are publicly accessible by URL. This eliminates a large class of account-takeover risk for the learners institutions serve.
Infrastructure
Hosting: Vercel
The Incredify application runs on Vercel's edge network. Vercel provides automatic TLS provisioning, DDoS mitigation, and global CDN distribution.
Database: Supabase (AWS)
Incredify uses Supabase, which runs on AWS infrastructure, for Postgres, authentication, and file storage. Supabase is SOC 2 Type II certified.
HTTP security headers
Responses include Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, and Strict-Transport-Security headers to reduce browser-based attack surface.
Rate limiting
Authentication endpoints and the issuance API are rate-limited to reduce the risk of brute-force and enumeration attacks.
Vulnerability Management
We accept responsible-disclosure reports at security@incredify.net. Our full disclosure policy is in SECURITY.md and at /.well-known/security.txt.
Acknowledge
Within 2 business days of receipt.
Triage
Severity and scope decision within 5 business days.
Disclosure
Coordinated with the reporter after remediation.
In scope: incredify.net and all subdomains, the badge claim and verification endpoints, and the issuer dashboard. Out of scope: third-party services (Supabase, Vercel, Stripe, Postmark), social engineering, and physical attacks.
We will not pursue legal action against researchers who follow this policy in good faith.
Compliance Readiness
Honest status as of June 2026
Incredify has not completed an independent security audit or penetration test. We hold no current certifications (SOC 2, ISO 27001, or similar). The controls described on this page are implemented and operational, but they have not been independently verified. We describe them as facts about what we have built, not as claims of certification.
SOC 2
We are building toward SOC 2 Type II readiness. No audit has been initiated or completed. We plan to engage an accredited auditor once we reach the appropriate operational maturity.
HECVAT
We are working through the Higher Education Community Vendor Assessment Toolkit (HECVAT) self-assessment. A completed HECVAT has not yet been published. Institutions that need it for procurement should contact us directly.
FERPA
Incredify is designed to minimize PII storage: recipients need no account, and badge claim pages contain only what institutions explicitly include in the credential. Institutions issuing badges that may implicate student records should evaluate their own FERPA obligations. Incredify has not undergone FERPA-specific legal review.
Penetration testing
No independent penetration test has been conducted. We intend to commission one as part of our path to SOC 2 readiness.
If your institution has specific compliance questions or needs documentation for a procurement process, email security@incredify.net. We will respond honestly about our current posture and roadmap.
Subprocessors
Incredify uses the following third-party subprocessors. Each processes data only as necessary to provide the services described.
| Subprocessor | Purpose | Location |
|---|---|---|
| Supabase (AWS) | Database, authentication, file storage | United States |
| Vercel | Application hosting and edge delivery | Global CDN |
| Stripe | Payment processing (plan subscriptions) | United States |
| Postmark | Transactional email (badge notifications, OTP) | United States |
This list reflects our current subprocessors as of June 2026. We will update it when we add or remove subprocessors.
Contact
Security questions or reports
Email security@incredify.net for vulnerability reports, compliance documentation requests, or any security-related question. A member of the Incredify team will respond.
For general questions: hello@incredify.net