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.