Does Reusable KYC Expire?

A reusable KYC credential can expire, and a business can require fresher evidence before that expiry date. There is no universal period that makes every identity check reusable. Acceptance depends on the credential's validity, its status, what was checked, the issuer the business trusts and the rules for the particular service.

"Verify once" describes avoiding unnecessary repetition of identity proofing. It should not be read as "every fact about this person is checked forever." The distinction makes reusable KYC more useful, because it lets a business ask for the part that actually needs updating.

If the basic flow is new to you, start with what reusable KYC means. This article addresses the next question: what happens as that credential ages?

Four different clocks affect a reusable check

It helps to separate four concepts that often get collapsed into one expiry date:

Concept	What to check
Credential validity	Is it inside its stated validity period? An issuer may set an end date.
Credential status	Has it been suspended or revoked, including before expiry?
Evidence freshness	Is the underlying fact recent enough, such as a current address?
Presentation freshness	Is the wallet responding to this request with a new challenge?

These examples describe a possible design, not OpenKYC production settings. An implementation needs to define each concept explicitly. Calling all four "KYC valid" hides the reason a check should succeed, be repeated or be declined.

Credential expiry is set by the credential and its profile

The W3C Verifiable Credentials Data Model 2.0 defines validFrom and validUntil for expressing a credential's validity period. These properties are optional in the base data model. The applicable credential profile can impose additional requirements, and other credential formats express validity using their own fields.

An absent expiry field therefore does not mean universal, permanent acceptance. A verifier still needs an acceptance policy for the credential type and its intended use. A profile may require a field that the generic data model leaves optional.

When comparing providers, ask for the actual credential profile and an example of how validity is evaluated. "We use verifiable credentials" does not tell you whether their expiry behaviour fits your service.

Revocation can happen before expiry

A credential may be within its stated dates while the issuer has withdrawn it. For example, a provider could discover that the underlying evidence was fraudulent or that a credential needs replacement.

Expiry addresses a planned end date. Status addresses changes that may happen sooner. Our guide to credential revocation and status lists explains the distinction and the privacy tradeoffs in checking status.

A business also needs to decide how fresh its status information must be and what to do when that information cannot be retrieved. "The status service did not answer" is an unknown result, not evidence that the credential is active. Depending on the agreed policy, the application might retry, pause the flow or use another approved check.

Write those outcomes into the integration contract. They should not depend on whether a network exception happened to land in a success or failure handler.

A fresh wallet response does not refresh the underlying facts

A wallet can present an older credential in a new interaction. With a suitable holder-binding mechanism, the presentation can demonstrate control of the relevant key for the intended request. That does not mean the issuer repeated its identity checks today.

OpenID for Verifiable Presentations 1.0 binds verifiable presentations to the intended verifier and request nonce. This addresses replay of a presentation; it does not change when the credential's claims were established.

In a fictional example, a wallet presents an address credential issued in January during a September onboarding flow. The response can be fresh while the address evidence is eight months old. Whether it is acceptable depends on what the service needs and the policy governing that evidence.

That is why a single lastVerified timestamp is an ambiguous product field. Does it mean the document was checked, the credential was issued, its status was fetched, or the wallet answered a challenge? Give those events separate names.

Different claims age differently

Consider three requests in the same fictional marketplace:

• A service asks whether the customer is over 18. The person's age moves forward, but the credential's issuer trust, status and holder controls still matter.
• Another service needs a current residential address. A previously verified address may have changed, so the business needs an explicit freshness rule.
• A regulated service needs identity evidence alongside its own current risk checks. An earlier identity proofing event does not establish the outcome of every later screening or monitoring activity.

The FATF's Guidance on Digital Identity distinguishes identification and verification at onboarding from ongoing due diligence. It evaluates digital identity through assurance and risk, rather than treating it as a substitute for the whole customer due-diligence process. Applicable legal requirements and accepted reliance arrangements remain specific to the jurisdiction and business.

For a product team, the practical task is to identify which claim needs refreshing. Repeating the entire document-upload journey may be unnecessary when an approved process can update only the changed or insufficient evidence.

What to put in a verifier acceptance policy

A useful first policy can fit on a page. For each accepted credential type, specify:

1. The issuers or trust framework the business accepts, and how that decision is maintained.
2. The required claims and assurance for the particular customer journey.
3. Validity-period checks, including how missing or malformed fields are handled.
4. Status-check requirements, permitted cache age and outage behaviour.
5. Any freshness requirement for the underlying evidence, with a reason for it.
6. The presentation and holder-binding requirements for a new request.
7. The fallback offered when evidence is missing, stale or unacceptable.

This is a suggested integration worksheet, not a universal compliance checklist. The important output is a decision a developer can implement and a support team can explain. A generic "verification failed" message gives neither the business nor the customer enough information to recover.

For example, distinguish "this credential expired; request a replacement" from "this service needs a newer address check." The first concerns the credential lifecycle. The second concerns the service's evidence requirements. They need not lead to the same user journey.

Does renewal always mean uploading an ID again?

No single renewal flow applies to every credential. The issuer decides what evidence is needed to issue a replacement under its profile and assurance requirements. Some renewals may reuse evidence the issuer can still rely on; others require a new check. A wallet cannot extend an issuer-signed validity period by editing a date locally.

Does every business have to accept the same credential?

No. Reusability depends on participating businesses supporting the format and accepting the issuer, claims and assurance for their use case. Interoperable transport helps move a credential; it does not create a universal trust decision.

OpenKYC is building a marketplace for reusable identity verification, with credentials held in a user's wallet and shared with participating businesses. It is in private development. The policy examples above explain how to evaluate reusable KYC; they are not a promise of a particular OpenKYC expiry period or acceptance rule.

If you are exploring a verifier or issuer integration, join the OpenKYC waitlist with the claim you need to verify and how often it needs to be current.