Portable credentials, honest practices.

Credentials stay portable. They are signed to open standards, held by recipients, and verified publicly. We also summarize how we protect accounts and issuer data, without claiming unfinished certifications.

Practices summarized on this page. Last updated: September 1, 2026.

Portability and verification

Open standards, recipient custody, and a public check. Proof travels with the person, not one vendor.

Open standards

Credentials are issued as Open Badges v3 / W3C Verifiable Credentials. Verification can be performed by any compatible tool, not only OpenCredia. For a plain-language take, see Open Badges 3.0 credentials.

Key custody

Each organization has its own signing key, stored encrypted, used to sign credentials and status lists. Self-serve key rotation is not built yet.

Recipient portability

Recipients claim into a hosted wallet and can download the signed credential as JSON or JWT plus the badge image. Any Open Badges 3.0 / W3C VC tool can read those files.

Public verification

Every issuance can expose a public verification URL and a summary JSON endpoint intended for integration and manual checks.

Trust without overclaiming

Practices we operate today, stated plainly. Credentials can outlast any one vendor.

Data protection

Traffic uses TLS in transit. Providers encrypt data at rest; we also protect signing secrets at the application layer, and passwords are hashed. MFA is available, and organizations can require it for Issuer console access. See Privacy and Subprocessors.

Security in how we build

Dependency and CI controls reduce supply-chain risk. Rate limits and audit logs cover public surfaces and security-relevant events. Report issues to [email protected]. This is engineering practice, not a certification.

Security and privacy practices

What we operate and document today for design partners. For privacy roles and sharing detail, see the Privacy Policy.

Roles

OpenCredia acts as a Data Processor for issuer-supplied recipient, badge issuance, credential artifact, and evidence data, and as a Data Controller for account, sign-in, inquiry, and platform-security data we decide how to process.

Encryption

Traffic uses TLS in transit. Database and object storage rely on provider at-rest encryption as configured for production. OpenCredia also applies application-layer AES-GCM to signing keys, SSO secrets, TOTP setup material, and MFA backup codes. Passwords and API keys are stored as hashes, not as recoverable plaintext.

Access and MFA

Multifactor authentication is available for accounts. Organizations can require MFA for Issuer console access. Passwords must be at least 12 characters and include a letter and a number.

Subprocessors

We use third-party vendors to host and operate the service. The current list is published on our Subprocessors page and may change as production infrastructure evolves.

Availability

Live uptime and incident updates are published on our status page. We do not publish a numeric uptime SLA on this site.

Backups

Production data is backed up through our infrastructure providers.

Vulnerability reporting

Report security issues to OpenCredia at [email protected]. Include enough detail for us to reproduce the issue. We aim to acknowledge new reports within 72 hours.

Related policies

Agreements and privacy documents that sit alongside this page.

Terms of service

The rules for using OpenCredia: accounts, issuance, APIs, and public credential features.

Learn more

Privacy Policy

How we collect, use, and share personal data for accounts, issuers, and recipients.

Learn more

Subprocessors

Vendors that process data on our behalf to host and operate the service.

Learn more

Cookies Policy

How we use cookies and similar browser storage for auth, security, and preferences.

Learn more

Accessibility

Our accessibility goals, current approach, known limits, and how to report barriers.

Learn more

Questions we hear

Need something this page does not cover? Email us.