User Verification

Confirm who somebody is, how old they are, or what they are affiliated with — using an external provider or an e-mail domain check.

User Verification Overview

Verification confirms something about a person that they cannot simply assert: who they are, how old they are, or what organisation they belong to.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

Permissions — the group a successful verification can award

What it is for

An account tells you somebody registered. It does not tell you they are over 18, that they are a nurse, or that they are the person named on the account. Where a service depends on any of those, verification is how you find out — without asking staff to inspect documents by hand.

How a check flows

A check is requested for a person and a verification type.
They are sent to the provider — or, for a domain check, asked to confirm an e-mail address.
The provider returns an outcome.
The result is recorded with an expiry, and any group award is applied.

Every transition is recorded

Each check accumulates events recording the status it moved from and to, what caused the change, when, and from which address. So the history of a verification is not just its final state — it is the whole sequence.

That matters when somebody disputes an outcome, and it matters more when a regulator asks how you satisfied yourself about a user.

What is stored, and what is not

This is the point people most need reassuring about, and the design is deliberate: the platform records the outcome, a short evidence summary, the provider's reference, and any failure reason.

It does not store the passport, the driving licence or the photograph. Those are handled by the provider, who is set up to hold them. What you keep is the conclusion and a pointer — which is what you need, and far less than you would otherwise be responsible for.

Checks can start from anywhere

A check records where it came from — a stage in a User Input View, a support request, a journey node. So verification can be a step in a form somebody is filling in, or an automated part of a process, not only something an administrator initiates.

Nothing is enabled out of the box

Five providers and seven verification types ship, all disabled and without credentials. Nothing contacts an external service, and no verification is demanded of anybody, until you deliberately turn it on.

Verification is not authentication

Worth separating. Authentication proves somebody is the account holder each time they sign in. Verification establishes a fact about them, once, that then persists until it expires.

Verifying someone does not make their account more secure — that is what two-factor authentication and passkeys are for.

Worked example

A retailer offers a student discount. Registration is ordinary; when a customer selects the discount they are asked to verify their student status. The check runs, succeeds, awards the student group, and expires in a year. Nobody in the business ever sees a student card, and the discount cannot be claimed by asserting it.

Recommendations

Verify only what you actually need to know.
Let the provider hold the documents — that is the design.
Do not treat verification as a security control for the account.
Enable one type first and prove the flow before adding more.

Categories and Types

Verification is organised as three categories, with types built on top of them.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

The three categories

Identity — this person is who they say they are, usually via a government-issued document.
Age — this person is over a required age.
Affiliation — this person belongs to a group: a student, a nurse, a teacher, a serving member of the armed forces.

Why the distinction matters

They differ enormously in intrusiveness and in cost. An identity check involves a document and a photograph; an affiliation check can often be satisfied by confirming an e-mail address at a known domain.

Reaching for identity verification when affiliation would answer the question is the commonest design mistake here. If what you need to know is "does this person work for the NHS", you do not need their passport.

The seven types that ship

General ID Check — identity, valid two years.
Age Check — age, valid two years.
Student — affiliation, valid one year, with academic domains pre-filled.
Healthcare Worker — affiliation, one year, with NHS domains pre-filled.
Teacher, Military / Veteran, First Responder — affiliation, one year.

All ship disabled. They are starting points to adapt rather than a fixed menu — you can change their rules or add your own.

What a type defines

A type ties together the category, which provider handles it, how long a result stays valid, whether re-verification is allowed, whether a human must review it, whether it gates sign-in, and which security group success awards.

So the category says what is being established and the type says how, for how long, and what happens next.

Validity differs by category for a reason

Identity and age ship at two years; affiliation at one. That reflects how the underlying fact changes — somebody's date of birth does not, but their employer does. A student who verified eighteen months ago may well have graduated.

Keep the list short

Enable the types you have a use for. A long list of verification options presented to a user is a decision you have handed them, and most of it will be irrelevant to what they were trying to do.

Worked example

A service needs to know that clinicians are genuine and that everybody is over 18. It enables Healthcare Worker — satisfied for most users by an NHS e-mail address — and Age Check. It does not enable identity verification, because knowing a user's legal name adds nothing to what the service does and would mean asking everybody for a passport.

Recommendations

Choose the least intrusive category that answers your question.
Adapt the shipped types rather than starting from nothing.
Enable only what you use.
Set validity to how fast the fact changes, not to a round number.

Connecting a Provider

A provider does the actual checking. Five are supported, and each declares what it is capable of.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

The five

Entrust / Onfido — identity and age.
Stripe Identity — identity and age.
SheerID — affiliation and age.
GoCertify — affiliation.
Internal (E-mail Domain Check) — affiliation, performed by the platform itself with no external service.

Capabilities are declared

Each provider records what it can verify, so a type can only be pointed at a provider able to do that kind of check. This prevents the configuration that looks correct and fails on the first real attempt.

Start with the internal check

For affiliation, the internal e-mail domain check is free, involves no external service, no contract and no personal data leaving the platform. Where it answers your question — and for NHS, academic and many corporate affiliations it does — use it.

Bring in an external provider when the domain check genuinely cannot cover your population.

Each provider declares its own settings

Rather than a generic credential form, every provider publishes the fields it actually needs, so the prompts match that provider's own documentation. Credentials are stored encrypted.

Sandbox mode

Providers that offer a test environment can be run in sandbox. Use it. Commission the whole flow — request, redirect, outcome, group award, expiry — against test data before a real user is asked for a document.

Getting this wrong in production means a real person has submitted a passport into a broken flow, which is not a mistake you can quietly retry.

Use service credentials

Register the connection under an account belonging to the organisation, not to an individual. Verification credentials permit checks that cost money and process identity documents; they should not depend on one person's login and should be revocable without disrupting them.

Commissioning checklist

Enable the provider and enter its credentials.
Turn on sandbox.
Point one verification type at it.
Run a check end to end as a test user.
Confirm the outcome, the evidence summary, the expiry and any group award.
Run a deliberate failure and confirm the failure reason is recorded.
Only then switch off sandbox.

Test the failure path too

Most commissioning tests only prove the happy path. The failure path is what your support team will actually deal with, and it is worth knowing what a user sees when a check does not succeed.

Worked example

An organisation enables SheerID in sandbox, points the Student type at it, and runs six test checks — four expected to pass and two to fail. The failures confirm that the reason is recorded and the user is given a sensible message. Sandbox is switched off a week later, after the group award and expiry have been verified.

Recommendations

Try the internal domain check first for affiliation.
Commission in sandbox, always.
Test the failure path, not just success.
Use organisational credentials, never a person's.

Setting Up a Type

A type is where the rules live. It is worth going through the settings deliberately, because two of them change behaviour well beyond the check itself.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history
Permissions — the group awarded on success

Architect Panel → Layout & Pages:

E-mail Templates — the message sent to the user

The settings

Category — identity, age or affiliation.
Provider — who performs the check.
Provider programme — where a provider offers named programmes.
Internal domains — for the e-mail domain check.
Validity days — how long a success lasts.
Allow re-verification — whether a user may check again.
Require manual review — whether a person confirms the outcome.
Gates login — whether sign-in requires this verification.
Award group — the security group granted on success.
E-mail template and account, and a link timeout.
Enabled and sort order.

Award group is the powerful one

A successful verification can place the user into a security group — which is how a verified status becomes actual access rather than a badge.

Because it grants access, treat it with the care you would give any other permission decision. Ask what that group can reach, and satisfy yourself that everybody who passes this check should have it. A generous group behind a lightly-checked verification is a real exposure, and it will not look like a permissions problem when you come to review it.

Gates login is the other one

It prevents sign-in until the verification is held. Powerful, and easy to apply too broadly — see the article on requiring verification to sign in before turning it on.

Validity days

Set it to how quickly the underlying fact changes. Two years is reasonable for identity; one year for affiliation; shorter where the status is genuinely volatile. A validity longer than the fact's natural life means you are relying on something that stopped being true.

Allow re-verification

Generally leave it on. A user whose circumstances changed — a new job, a new document — should be able to check again without an administrator. Turning it off is for the rare case where repeated attempts are themselves a risk.

Link timeout

How long the user has to complete a check after it is requested, in minutes. It ships at 30, which suits somebody who starts immediately. If your users typically receive an e-mail and come back later, that is too short — and an expired link is a support call.

Require manual review

Adds a human decision before the result is accepted. Right for high-value verifications; wrong as a default, because a review queue nobody works becomes a queue of users waiting.

Worked example

A service sets up Healthcare Worker: affiliation, internal domain check against NHS domains, 365 days validity, re-verification allowed, no manual review, does not gate login, awarding the "Verified Clinician" group. The group is checked first — it grants access to clinical content only, nothing administrative — before the type is enabled.

Recommendations

Review what the award group can reach before setting it.
Match validity to the fact, not to a convenient number.
Leave re-verification on.
Lengthen the link timeout if users receive a link by e-mail.

E-mail Domain Checks

The internal check confirms affiliation by confirming control of an e-mail address at a recognised domain. No external provider, no document, no cost.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Integration & Connections:

E-mail Accounts — the account the confirmation is sent from

How it works

The type lists acceptable domains. The user gives an address at one of them, receives a message, and follows the link. Control of the address is the evidence.

Domain patterns

Domains are listed separated by semicolons, and wildcards are supported. The shipped Student type uses *.ac.uk;*.sch.uk;*.edu; Healthcare Worker uses nhs.net;*.nhs.uk.

So you can accept an entire sector with a pattern, or name individual organisations exactly. Both are useful: a pattern for a whole sector, exact domains for a partner list.

What it actually proves

Be precise about this, because it determines whether the check is fit for your purpose. It proves the person controls an e-mail address at that domain today.

It does not prove their name, their role, or that they are currently employed — a university address often outlives graduation, and a leaver may keep access to a mailbox for weeks. For "is this person part of this community", that is fine. For "is this person authorised to make clinical decisions", it is not.

Where it is excellent

Sectors with reliable domain conventions — academia, the NHS, government.
Partner organisations whose domains you know.
Anywhere the consequence of a wrong result is a discount rather than access to something sensitive.

Where it is not enough

Populations with no consistent domain — teachers at independent schools, self-employed professionals.
Anything where currency matters and a stale mailbox would mislead you.
Anywhere the affiliation gates access to personal data about others.

In those cases an external affiliation provider checks against an actual register rather than a mailbox.

Be careful with wildcards

A pattern accepts every subdomain, including ones you have not thought about. Before adding one, consider who else holds an address under it — a broad academic wildcard admits staff, students, alumni and contractors alike.

If the distinction matters, name domains explicitly.

Watch the link timeout

The user must follow the link within the type's timeout. Where the message may sit in an inbox — a work address checked twice a day, or a shared mailbox — 30 minutes is not enough, and expired links are the main source of support for this check.

Check deliverability first

The whole check depends on a message arriving. Confirm your sending domain is properly configured, and test against one of the domains you intend to accept — corporate mail filters are the usual obstacle, and the failure looks to the user like the service is broken.

Worked example

A service accepts nhs.net;*.nhs.uk for its clinician type. Ninety per cent of clinicians verify in under a minute at no cost. The remainder — private practice and locum staff without an NHS address — are routed to an external affiliation provider, so nobody is excluded by the cheap route not covering them.

Recommendations

Use it wherever the domain convention is reliable.
Be clear it proves mailbox control, not employment.
Prefer exact domains to wildcards where the distinction matters.
Provide a fallback route for people the domains do not cover.

Identity and Age Checks

Identity and age checks are performed by an external provider against a government-issued document, usually with a photograph of the holder.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

How it runs

The user is sent to the provider, photographs their document and usually themselves, and the provider compares the two and validates the document. The platform receives an outcome, a short evidence summary and the provider's reference.

The documents do not come here

The image of the passport stays with the provider. What is recorded on your side is the conclusion.

This is the right division. Holding identity documents is a serious responsibility — storage, retention, disclosure, breach exposure — and the provider is built and contracted for it. Keeping only the outcome means a breach of your database does not expose anybody's passport.

Age is a smaller ask than identity

They use the same kind of document, but they establish different things and should not be treated as interchangeable.

An age check answers whether somebody is over a threshold. An identity check establishes who they are and returns a name you then hold. If your obligation is age-related, ask for age — requesting full identity verification collects more than you need, and the extra is data you must then justify holding.

Expect some people to fail legitimately

Document checks do not succeed for everybody. Worn documents, poor cameras, poor lighting, some disabilities, and people without a passport or driving licence all produce failures that are nothing to do with fraud.

Plan an alternative route — manual review, an affiliation check, a supported process — before you make a document check the only way through. A service that cannot be used by somebody with no passport has an accessibility problem, not just a verification one.

Set expectations before the redirect

Tell users what they will need and roughly how long it takes, before sending them to the provider. Someone who starts a document check on a train without their passport will abandon it and may not come back.

Cost per check

Document verification is charged per attempt, usually including failures. That is a reason to check only when you need to, to avoid re-running unnecessarily, and to keep validity periods sensible rather than short.

Read the evidence summary

When a result is queried, the summary is what tells you what the provider actually concluded. Combined with the event history — every status transition, with its source and time — it usually answers the question without contacting the provider at all.

Worked example

An age-restricted service uses an age check rather than identity verification, because its obligation is about age alone. Most users pass in a minute. Those who fail twice are offered a supported route with manual review, so no one is excluded by a camera or a worn document — and the service never holds anybody's name from a passport.

Recommendations

Ask for age when age is the question.
Always provide an alternative route.
Set expectations before the redirect.
Let the provider hold the documents.

Checking a Status

Every check is recorded with its outcome, its history and its expiry, so "is this person verified?" is answerable directly.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Activity:

Activity Log — the group award that followed a success

What a check records

The type and provider.
The user, by three-part identity, and the e-mail used.
The status.
The provider reference — needed if you ever have to ask them about it.
The outcome and a short evidence summary.
A failure reason where it did not succeed.
Requested, completed and expires timestamps.
The address and browser it came from.
Where it originated — a form stage, a request, a journey step.

Read the events, not just the status

Each check carries a history of transitions — what it moved from and to, what caused it, when, and from where. A check sitting at an unexpected status is explained by its events far more often than by its current state.

This is where you see that a user started a check and never completed it, or that a provider callback arrived twice.

Check the expiry, not just the outcome

A successful check that has since expired is not current verification. The commonest confusion here is reading a success and not noticing its date — particularly for affiliation, which typically lasts a year.

The source field answers "why was this asked for?"

When a user says they were unexpectedly asked to verify, the source tells you which form, request or process triggered it. That turns a vague complaint into a specific configuration question.

Failure reasons before contacting support

Most "verification is broken" reports are explained by the recorded failure reason — a document that could not be read, a mismatch, an expired link. Read it first; it is usually enough to advise the user without involving the provider.

Keep the provider reference

If you do need to raise something with the provider, that reference is what lets them find the transaction. Quote it rather than describing the user.

Do not re-run a check to diagnose it

It costs money, it asks the user to submit a document again, and it usually produces the same result. Read the existing record first.

Worked example

A user says they verified but cannot reach the content it was supposed to unlock. The check shows a success — completed fourteen months ago, against a type with 365-day validity. It expired a fortnight earlier. They are asked to re-verify, which takes a minute, and the whole enquiry is answered from one screen.

Recommendations

Read the expiry with the outcome.
Use the event history for anything unexpected.
Check the failure reason before escalating.
Never re-run a check just to investigate it.

Manual Review

A type can require a person to confirm the outcome before it is accepted. That is a real control and a real commitment.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

Permissions — the group awarded once a review passes

When it is worth it

The verification grants access to something genuinely sensitive.
The provider returns results you sometimes need to interpret rather than accept.
A regulatory obligation requires a named person to be satisfied.
Volumes are low enough that reviewing everything is realistic.

When it is not

High volume with low consequence. A review that must happen for thousands of users becomes a rubber stamp, and a rubber stamp is worse than no review — it produces a record asserting that somebody checked, which nobody meaningfully did.

If you cannot review properly, do not claim to.

An unworked queue is a queue of people

This is the failure mode to design against. Every item waiting is a user who cannot do what they came to do, and who has no way of knowing whether anything is happening.

Before enabling manual review, decide who works the queue, how often, and what the target turnaround is. Then check it is actually happening a fortnight later.

What a reviewer should look at

The provider's outcome and evidence summary.
Any recorded failure reason.
The event history — a check with an odd sequence deserves more attention than its final status suggests.
Whether the type is appropriate for what the user is asking for.

Reject with a reason

A rejection with no explanation produces an immediate re-attempt, usually identical. Saying what was wrong is what lets somebody succeed on the second try, and it is what makes the decision reviewable later.

Do not reduce checks to speed the queue

The temptation when a queue builds is to look at less. If the queue is too big to review properly, the answer is more reviewers or fewer things requiring review — not a shallower review.

Watch the turnaround, not the depth

Track how long items wait. A queue that is always short is working; one that grows through the week and is cleared on Fridays is one where users wait days without knowing it.

Worked example

An organisation requires manual review only on the type granting access to clinical records — around fifteen a week. Two named reviewers work it daily with a one-working-day target. Ordinary affiliation checks are automatic, so the reviewers see the fifteen that matter rather than several hundred that do not.

Recommendations

Require review only where consequence is high and volume is low.
Name who works the queue before enabling it.
Always give a reason when rejecting.
Track waiting time as the health measure.

Validity and Expiry

A verification is a fact established at a moment. Validity is your judgement about how long that fact stays reliable.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

Permissions — the awarded group, and what happens to it on expiry

Setting validity

Set it to how quickly the underlying fact changes, not to a round number:

Identity — changes rarely. Two years is the shipped default and is reasonable.
Age — never goes backwards, so a long validity is defensible; two years ships.
Affiliation — changes often. One year ships, and shorter can be justified where turnover is high.

Longer is not simply worse

Short validity means frequent re-verification: cost for document checks, friction for users, and support volume. Long validity means acting on facts that may have stopped being true.

Judge it by the consequence of being wrong. Where a stale affiliation means someone keeps a discount, a year is fine. Where it means keeping access to personal data about other people, it is not.

Expiry is silent unless you make it visible

A verification lapses on its date and the user finds out when something stops working — usually while trying to do something else, with no explanation.

Warn people beforehand where you can. A month's notice on an annual affiliation turns a broken journey into a task somebody completes at their convenience.

Think about the awarded group

If a successful verification awards a security group, decide what should happen to that group when the verification expires. An expired verification whose group award persists means access outliving the evidence for it — which is exactly the situation you introduced verification to avoid.

Include awarded groups in your access reviews, and check them against current verification status rather than assuming they track it.

Allow re-verification

Leave it on. Circumstances change: somebody starts a new job, renews a document, moves institution. Being able to check again without an administrator is what keeps records current.

Do not extend by editing

Where a check has expired, the correct response is a new check. Extending an existing one asserts that a verification performed two years ago is current, which is not what happened and not what your records should say.

Review expired checks periodically

A population with many expired verifications is one where either the validity period is too short for the behaviour of your users, or the re-verification path is not working. Both are worth knowing.

Worked example

A service sets affiliation validity to a year and sends a reminder a month before expiry. About 70% re-verify before lapsing. The remainder lose the awarded group on expiry and are prompted at the point they next need it. An annual access review cross-checks group membership against live verifications and finds no one holding access on lapsed evidence.

Recommendations

Match validity to how fast the fact changes.
Warn users before expiry.
Check awarded groups against live verifications in access reviews.
Re-verify rather than extending.

Gating Sign-In

A type can be set to gate login — nobody signs in without holding that verification. It is the strongest thing in this area and the easiest to regret.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

Blocked User Accounts — where lock-out reports will surface
Authentication Methods — the sign-in routes affected

What it does

Sign-in requires the verification. Somebody without it cannot proceed past authentication, however valid their password and second factor.

When it is right

A legal requirement that only verified people use the service — age restrictions being the common case.
A closed professional service where affiliation is the basis of membership.
An environment where an unverified account should not exist at all.

When it is not

Anywhere verification unlocks part of the service. If a student discount needs verification, gate the discount, not sign-in — otherwise every non-student is locked out of a service they are entitled to use.

This is the mistake to avoid: gating login is for "may this person be here at all", not "what may they do once here". The second question is answered by the awarded group.

Introduce it carefully

Enable the type without gating, and let people verify.
Watch how many hold it. Do not guess.
Tell users the requirement is coming, with a date.
Make sure the verification path works for everybody who should pass, including the awkward cases.
Only then turn on gating.

Gating first and hoping people verify locks out your user base on the day you enable it.

The unverified cannot always fix it themselves

Think through what somebody blocked at sign-in actually sees, and whether they can reach the verification from there. If verification requires being signed in, and sign-in requires verification, you have built a loop — and it is not obvious until a real user hits it.

Test this specifically, with an account that has never verified.

Keep an administrative route in

Make sure administrators are not gated by the same requirement, or that at least one account is exempt. Locking every administrator out behind a verification that is failing is a bad afternoon.

Plan for provider outages

If verification gates sign-in and the provider is unavailable, new and expiring users cannot get in. Know in advance whether you would lift the gate temporarily, and who can do that.

Worked example

An age-restricted service enables the age check without gating and reaches 89% within three weeks. It writes to the remainder, confirms the flow works for people without a passport via the supported route, and gates sign-in a month later. Administrators are exempt. Fewer than twenty users are affected on the day, all of whom can verify from the block screen.

Recommendations

Gate access to features, not sign-in, unless membership itself depends on it.
Enable and measure before gating.
Test with a never-verified account for the loop.
Exempt at least one administrator.

Troubleshooting

Most verification problems are a handful of causes. Working through them in order of likelihood resolves the great majority without contacting a provider.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Activity:

E-mail Log — whether a domain-check message was sent
Error Log — technical failures around a check

Start with the record

Open the check and read the status, the failure reason and the event history before anything else. It usually contains the answer, and every other step is slower.

The link expired

The commonest failure on domain checks. The user received the message, came back later, and the link had timed out.

Fix for the individual: re-run the check. Fix for the pattern: lengthen the link timeout on the type. If this happens often, 30 minutes does not suit how your users read e-mail.

The message never arrived

Check the e-mail log. If it shows a successful send, the message left and the problem is at the recipient's end — a corporate filter, a full mailbox, a typo in the address they gave. If there is no entry, the check never got that far.

The domain is not accepted

The user's address is at a domain the type does not list. Read the type's domain list against the address carefully — a wildcard covering *.nhs.uk does not cover nhs.net, and that specific pair catches people out.

Decide whether to add the domain or route the user to another verification type. Do not add a domain casually — it grants everybody at that domain the same result.

The document check failed

Read the failure reason. Poor image quality, an unreadable document and a mismatch are different problems with different advice. Repeated failures with no clear reason are worth raising with the provider — quoting the provider reference.

Remember that legitimate failure is common. Somebody failing twice is not evidence of fraud; it may be a worn licence and a bad camera.

Verified, but access has not changed

Check three things in order: has the check expired; does the type actually award a group; and does that group have the access the user expects. Most of these turn out to be the third — the verification worked and the group does not grant what somebody assumed.

Nothing happens when a check is started

Check whether the provider is enabled, whether its credentials are present, and whether it is in sandbox when you expect production. A provider left in sandbox after commissioning is a classic, and it produces results that look real but are not.

The same user appears twice

Look at the three-part identity. The same person arriving by two different sign-in routes is two identities, and a verification against one does not apply to the other. This surfaces when somebody moves from a local account to single sign-on.

Worked example

A run of failures on the clinician type all show "domain not accepted". The users are at nhs.net, which the type had lost when its domain list was edited. Adding it back resolves everybody at once, and the event history confirms the change coincided with the edit.

Recommendations

Read the check record first, every time.
Lengthen the link timeout if expiry is a pattern.
Confirm sandbox is off after commissioning.
Check the identity route when a verification seems to have vanished.

Security and Data Protection

Verification processes information about people, some of it sensitive. The design keeps your exposure small, but there are decisions only you can make.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

Permissions — who may see verification records

Architect Panel → Data:

Retention & Disposal — how long check records are kept

Architect Panel → Activity:

Record Read Log — who has looked at verification data

What you hold

The outcome and a short evidence summary.
The provider's reference.
The e-mail address used.
Any failure reason.
Timestamps, the IP address and the browser.

What you do not hold

The passport, the driving licence, the photograph. Those stay with the provider.

This is the single most important thing to understand about your exposure here, and it is worth stating plainly to anybody assessing the system: a breach of your database does not disclose anybody's identity documents, because they were never in it.

What you hold is still personal data

An evidence summary saying somebody is a verified healthcare worker is information about them. A record that an age check failed is information about them. The IP address and browser are personal data.

Treat verification records with the same care as any other personal data: restrict access, set retention, and include them in your record of processing.

Settle the lawful basis first

Before enabling a type, be able to say why you are asking. "It seemed useful" is not a basis, and verification is exactly the kind of processing that attracts scrutiny — you are asking people to prove things about themselves as a condition of using a service.

Ask for the least that answers your actual question: age rather than identity, affiliation rather than identity, a domain check rather than a document.

Set retention deliberately

Check records accumulate, including failures. Decide how long you need them — long enough to evidence that you verified somebody, not indefinitely — and apply it.

Failed checks deserve particular thought. A record that somebody repeatedly failed an age check is sensitive, and there is rarely a reason to keep it for years.

Restrict who can see them

Verification records reveal affiliations and outcomes. Access should be limited to the people who administer verification, not available to anybody who can see a user record.

Where the records are sensitive, consider enabling read auditing so you can answer who has looked.

Tell people what happens

Explain, before they start, what will be checked, by whom, what you will keep and for how long. Sending somebody to an unfamiliar third party to photograph their passport with no explanation is both poor practice and a good way to lose them at the redirect.

Do not repurpose the data

An affiliation established for access control should not quietly become a marketing segment. That is a different purpose, and it needs its own basis.

Worked example

Before enabling verification, an organisation documents why each type is needed, sets retention at two years for successes and six months for failures, restricts the records to three named administrators, and adds a short explanation to the point of redirect. When asked later what identity data it holds, the answer is that it holds none — only outcomes.

Recommendations

Ask the least intrusive question that answers your need.
Set retention, with a shorter period for failures.
Restrict access to verification administrators.
Explain the process before the redirect.