What are verifiable credentials?
A verifiable credential is a digital certificate that anyone can check without calling the organisation that issued it. The issuer signs it once, the person or company it belongs to keeps it, and whoever receives it can confirm on the spot that it is genuine and unchanged. That single shift, from asking the source to checking the signature, is what sets it apart from a PDF or a paper document.
What a verifiable credential is
A verifiable credential is a statement that one organisation makes about a person or a company, written in a form a computer can check. The statement itself is ordinary: this person passed this exam, this company is registered at this address, this driver holds this licence. What is new is the proof that travels with it, a digital signature made by the organisation that issued it.
Because the signature covers the exact contents of the statement, whoever receives it can establish two things without contacting anyone. They know which organisation made the statement, and they know that nothing in it has been altered since. The proof of authenticity sits inside the credential rather than in a phone call or a lookup.
That changes who does the work. Today a party that wants certainty either trusts the document in front of it, or builds an integration with the source of the data and asks it every time. With a verifiable credential the issuer does its work once, at the moment it signs, and every check afterwards takes a fraction of a second and involves nobody else.
None of this requires the person or the company to give up control. They hold the credential, they decide who is allowed to see it, and in most cases they can choose to reveal only the part of it that the question actually needs.
The three roles: issuer, holder and verifier
Every verifiable credential involves the same three parties. An issuer states something it already knows to be true and signs it. A holder receives that statement and keeps it. A verifier asks for it, checks the signature and acts on the result.
Issuer
The organisation that already holds the fact, such as a public register, a school, a bank or a government body. It signs the statement once and does not have to be involved again.
Holder
The person or company the credential is about. They keep it in a wallet, on a phone or as a Business Wallet for an organisation, and decide who gets to see it.
Verifier
Whoever needs the proof, for example an employer, a marketplace or a lender. They check the signature against the published key of the issuer and have an answer in seconds.
The split matters because it removes the direct line between the issuer and the verifier. In the older model, a verifier that wanted certainty had to go back to the source, which meant an agreement, an integration and a running relationship with every issuer it cared about. In the credential model the holder carries the proof between them, so the issuer and the verifier never have to meet.
The holder is not always a person. An organisation can hold credentials too, which is what a Business Wallet is for. It receives credentials about the company, keeps them, and presents them to counterparties when your own systems ask it to, instead of someone downloading a file and attaching it to an email.
A recognisable example is a certificate of good conduct, the extract from the criminal record that many employers ask for before they hire someone. Today an applicant requests it, waits for it to arrive, scans it and emails a PDF that the employer simply has to take on trust. Issued as a verifiable credential it lands straight in the wallet of the applicant, and the employer checks it in the moment it is presented.
The life of a credential, from issuing to expiry
Take a concrete case. A contractor has to prove to a new client that its people are certified for work at height, something the training institute already knows and records. The institute acts as the issuer: it takes the fact out of its own registration, packages it as a credential and signs it.
The credential is then offered to the holder, usually by scanning a code or following a link from the portal where the person is already logged in. It lands in their wallet, on a phone for an individual or in a Business Wallet for a company. From that moment it is stored on the side of the holder, not in a central database that everyone else has to query.
When the client asks for proof, it does not really ask for a document. It asks a question: is this person certified for work at height, and is that certificate still valid today. The wallet shows the holder exactly what is being requested, the holder approves, and only the requested facts leave the wallet.
The verifier then checks the signature against the published key of the training institute, confirms that the credential really belongs to the person presenting it, and confirms that it has not expired. All three checks run on the side of the verifier, in the time it takes the page to refresh.
Credentials are not meant to live forever. Most carry an expiry date, so a certificate that lapses after three years simply stops verifying. When something has to be withdrawn earlier, because a licence was suspended or an employee left, the issuer publishes that in a status list which verifiers consult as part of the check. The list covers many credentials at once, so consulting it does not reveal which one was being checked.
How a verifier knows the issuer is genuine
A signature proves that whoever holds a particular key signed the statement. On its own it does not say that the key belongs to the national vehicle authority rather than to someone who registered a similar sounding name last week. Answering that second question is what trust infrastructure is for.
The simplest answer is a published list. Member States in the European Union already maintain trusted lists of the parties allowed to provide regulated trust services, and the same idea now extends to wallets and the credentials they carry. A verifier that finds the issuer on the relevant list knows it is dealing with a party that was admitted after supervision, not merely with a working key.
Inside a sector, the same role is often played by a trust registry. A network of universities, a group of energy suppliers or an industry association agrees who may issue which credentials and keeps that record somewhere every member can read. The verifier checks the signature first, then checks the registry to see whether this issuer is recognised for this kind of statement.
Around both sits the trust framework: the rules that say what has to be true before an issuer is admitted, how identities were checked, how long credentials stay valid and what happens when something goes wrong. It is mostly legal and organisational work rather than technology, and it is usually the part that takes longest to agree. It is also the part that makes a credential mean the same thing to everyone who receives it.
The EUDI Wallet and eIDAS 2.0
Verifiable credentials have existed as a standard for years. The reason they are being built into real systems now is European law. The revised eIDAS Regulation, usually called eIDAS 2.0, obliges every Member State to offer its citizens and businesses a European Digital Identity Wallet, and it obliges a long list of organisations to accept it.
The timeline is the part worth planning around. Member States have to make at least one wallet available around the end of 2026, and from 2027 large online platforms and regulated sectors such as banking have to accept it wherever they already require strong user authentication. For most organisations the question is therefore not whether wallets will arrive, but which side of the counter they will be standing on.
Inside the wallet the foundation is the Person Identification Data, the PID. That is the core identity set issued under the responsibility of a Member State: who you are, confirmed to the level the state itself uses. Everything else is an electronic attestation of attributes, an EAA, which is the term the regulation uses for a verifiable credential about something other than core identity, such as a membership, a diploma or a mandate to act for a company.
Attestations come in grades. A qualified electronic attestation of attributes, a QEAA, is issued by a qualified trust service provider under supervision and carries legal weight across the Union. A public body that is the authentic source for a fact can issue a public sector attestation with comparable standing. A plain EAA is perfectly usable and is where most private issuing starts, it simply does not come with the same standing in law.
Why not simply a PDF, paper or an API?
Most organisations prove things today with scanned documents, paper originals or a separate API integration with every counterparty. Verifiable credentials replace all three with one mechanism.
Much harder to forge
A PDF can be edited and a paper document can be copied convincingly. A verifiable credential carries a signature over its exact contents, so any change breaks the signature and the check fails on the spot.
Share less, prove more
Selective disclosure lets the holder reveal only the facts that matter, for example that someone is old enough rather than their full date of birth. The verifier gets the answer it needs and never receives the rest.
Far less manual checking
Phoning the issuer, comparing stamps and rekeying data all disappear. The check runs automatically, which cuts handling time and removes a whole class of human error.
The comparison with a PDF is the one most people reach for, and it is worth being precise about it. An exported or scanned document can be perfectly genuine, but the recipient has no practical way to tell a genuine one from a careful forgery. So in practice it is accepted on trust, or confirmed by contacting the issuer. That phone call is the real cost, and it is exactly what a credential removes.
Paper has the same problem with one more on top: it has to physically travel, and it cannot be checked at all outside office hours. An API integration does solve the trust problem properly, but only between the two parties that agreed to build it, and only for as long as both keep maintaining it. Ten counterparties mean ten projects.
Common misconceptions
The first is that verifiable credentials need a blockchain. They do not. The credentials themselves are signed statements held by the person or company they describe, and the European ecosystem checks them against ordinary published keys and government maintained lists. Some projects do put registry data on a ledger, but that is a choice about where to publish a list, not a property of the credential.
The second is that this is the same as putting a digital signature on a PDF. A signed PDF proves who signed the file and that it has not been edited, which is genuinely useful, but it stays a document meant for a person to read. A credential is a set of separate facts a system can act on, the holder can disclose only part of it, and it has a status the issuer can withdraw. A signed PDF has none of those last three properties.
The third is that the mobile driving licence is something else entirely. The mobile driving licence, the mDL, is a verifiable credential in the ISO format called mdoc, designed so that it also works face to face and without a network connection, which is what a roadside check needs. It sits alongside the SD-JWT VC format used for most online cases rather than competing with it, and one wallet can hold both.
The last is that adopting credentials means replacing what you have. In practice the source systems stay where they are. Issuing adds a signed output next to the record you already keep, and verifying adds a check next to the intake process you already run. The change happens at the edges, which is also why a first project can be small.
Where verifiable credentials are used
The same pattern repeats across sectors: a trusted source already holds the fact, and many other parties need to rely on it.
Government
Permits, registrations and citizen attestations issued once and reused across agencies and across borders.
Finance
Onboarding checks, company data and proof of income, confirmed without collecting a stack of scanned documents.
Healthcare
Professional registrations and qualifications for staff, checkable by any employer or institution that needs them.
Supply chain
Certificates, product data and supplier credentials that travel with the goods instead of by email attachment.
What these have in common is that the fact itself is not in dispute, it is simply expensive to prove. Someone already knows it, in a register, a student file or a certification database, and a chain of scans, emails and manual checks exists purely to move that knowledge to whoever needs it. Any process with that shape is a candidate.
The standards, in short
Verifiable credentials are not one vendor product. A handful of open standards define how they are written and read, which is what lets a credential from one issuer work with a verifier that has never dealt with that issuer before.
W3C VC
The W3C data model that says what a credential contains: the claims, who issued it, how long it is valid and the proof that ties it together.
SD-JWT VC
A compact format built on signed tokens, with selective disclosure included by design. It is the format the European wallet ecosystem has settled on.
mdoc
The ISO format used for mobile documents such as the mobile driving licence, made to work in person and offline as well as online.
Two other names come up quickly in any conversation about this, and both are about movement rather than content. OpenID4VCI describes how a credential gets from the issuer into a wallet, and OpenID4VP describes how a wallet presents one to a verifier. You do not need to know either in detail, but it helps to know that the format and the transport are separate decisions.
You do not have to choose between them up front. A platform that supports the relevant formats can issue the same underlying data in whichever one a given ecosystem expects.
Getting started: what a first pilot looks like
A sensible first project takes one credential, one issuer and one verifier, and leaves everything else alone. Pick a fact your organisation already holds and already gets asked about, where the current process is a scan, an email or a phone call. A membership, an employment confirmation, a certification or a mandate to act on behalf of a company all work well.
What it asks of the organisation is less technical than most teams expect. You need a data owner who can say what the credential asserts and when it is no longer true, a decision about how long it stays valid and how it gets withdrawn, and one integration with the system that already holds the data. The signing, the wallet interaction and the formats are handled by the platform.
The part that takes real time is the agreement around it. Who is allowed to issue this, who will accept it, and what happens if it turns out to be wrong are organisational questions, and they benefit from being answered before anything is built. Where a sector trust framework already exists, much of that work has been done for you.
A pilot of this size is normally a matter of weeks rather than quarters, and it is worth running it end to end with a small group of real users instead of building the complete version first. The point is to find out what the process feels like once the check is instant, because that usually changes what you want to build next.
How Credenco supports issuing, holding and verifying
Credenco covers all three roles, so an organisation can start with the one it needs today and add the others when the use case grows.
Issuance Service
Turn data your organisation already holds into signed credentials and deliver them to the wallet of the holder.
Holder Service
Receive, store and present credentials on behalf of your organisation in a Business Wallet, driven by your systems rather than by hand.
Verification Service
Ask for exactly the credentials you need and get a checked answer back, without building an integration for every issuer.
Which one you start with depends on where you sit. An organisation that owns data other parties keep asking about starts with issuing. One that spends time checking documents from other parties starts with verifying. Holding becomes relevant as soon as credentials about your own company start arriving and have to be presented again to someone else.
Frequently asked questions
What is a verifiable credential in plain terms?
It is a digital statement that one organisation made about a person or a company, signed so that anyone who receives it can check it. Think of a diploma, a permit or a company registration extract that proves its own authenticity, without the recipient having to contact the issuer.
How is it different from a PDF certificate?
A PDF has to be trusted, or confirmed with the issuer by phone or email. A verifiable credential is checked against the published key of the issuer in seconds, and any edit to its contents makes that check fail.
Do we need a wallet app to use them?
A person normally keeps credentials in a wallet app on their phone. An organisation uses a Business Wallet instead, which is a service rather than an app, so credentials can be received and presented by your own systems.
Does the issuer see where a credential is used?
No. The verifier checks the signature locally against published key material, and checks whether the credential is still valid against a published status list rather than by asking about that one credential. The issuer therefore does not learn who is verifying what.
What happens when a credential has to be withdrawn?
The issuer publishes the withdrawal in a status list that verifiers consult as part of every check, so the credential stops passing. The list covers many credentials at once, which is what keeps the issuer from learning which one was being checked.
How long does a first project take?
A pilot with one credential, one issuer and one verifier is usually a matter of weeks. The technical work is modest. Agreeing who may issue the credential and who will accept it is normally what sets the pace.
Related terms
Technical deep dive
This page stays at the level of what a verifiable credential is and what it means for your organisation. The implementation detail, including how to issue a credential from your own backend, lives in the technical documentation. Read the technical documentation
This page is informational and does not constitute legal advice. For authoritative guidance consult the European Commission and the OpenID Foundation directly.