A digital verification method used to confirm a person’s immigration status through the official online service. It is commonly used for visa holders and other workers whose right to work is time-limited, and it only provides assurance when the employer follows the correct process and retains the record.
What the share code check actually proves
A share code check is a verification step, not a blanket trust decision. It confirms that a worker’s right to work information is being presented through the official online service, but the result is only meaningful when the employer uses the correct checking route and keeps the evidence record.
That distinction matters because the code itself is not the authority, the underlying immigration status service is. In practice, the check is a control for confirming eligibility at a point in time, while the employer’s process determines whether that verification can be relied on later.
Why employers use it for time-limited right-to-work cases
The main use case is time-limited permission to work, where manual document review can be less reliable than a live digital lookup. A share code lets the employer retrieve a current status view directly from the official service rather than relying only on a copied document or an out-of-date record.
This makes the control especially useful where status can change, because the verification process is tied to an official source rather than to a static artefact. It reduces the chance that a valid-looking document is mistaken for a valid current entitlement.
The security value is procedural as much as technical: if the employer uses the wrong workflow, accepts the wrong evidence type, or fails to keep the record, the check loses much of its assurance value.
What can make a share code check unreliable
A share code check can fail as a control when the organisation treats it as a one-off formality instead of part of a governed right-to-work process. The common failure mode is not the online service itself, but incorrect handling around it: wrong person, wrong date, wrong status route, or missing retention.
It also depends on the person generating the code and the employer viewing the result at the right time. If the code is shared carelessly, reused, or checked outside the approved process, the organisation may end up with a false sense of assurance.
Because the check is point-in-time, it should be understood as evidence of current status at the moment of verification, not as permanent proof for future access decisions.
How to interpret the record it leaves behind
The record is the part that gives the check operational value after the initial lookup. It shows that the employer took a verification step through the official service and can help demonstrate that the organisation followed the required process.
That record should be treated as controlled compliance evidence, not as a substitute for ongoing employment eligibility management. If status changes later, the earlier check does not automatically remain sufficient.
Good handling also means keeping the verification artefact in a way that is findable, consistent and aligned to the employer’s retention obligations, so the organisation can show what was checked and when.
Risk and Threat Considerations
A share code check creates risk when organisations rely on the code alone, skip the official process, or fail to retain evidence of the verification. The result can be unlawful hiring, missed status changes, or a weak audit trail that cannot support later compliance review.
Failure mechanism: the employer accepts an unverified or improperly checked code, or stores no durable record, so the verification step cannot prove that the right-to-work check was actually completed through the official service.
Impact: the organisation may onboard or retain someone without valid confirmation of work entitlement, creating legal, regulatory, and operational exposure, especially where a time-limited status requires repeat checking.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Share code checks depend on controlled use and retention of verification material. |
| IA-2 — Identification and Authentication (Organizational Users) | The check supports authenticated verification of an individual's status before access to work is granted. | |
| AU-2 — Event Logging | The process needs auditable records of who performed the check and when. | |
| Recommendation — Define handling rules for verification codes and retain the resulting evidence record. Require authenticated verification before granting employment-related access. Log each verification event so the organisation can prove the check occurred. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The term concerns controlled verification before granting workplace access. |
| A.5.33 — Protection of records | The process requires keeping verification evidence for later compliance review. | |
| Recommendation — Apply access-control policy to ensure work eligibility is checked before access is granted. Protect retained verification records so they remain available for audit and review. | ||
Practitioner Guidance
What to watch for: the practical control question is whether your process makes the share code check auditable. If the workflow does not capture who performed the check, when it was performed, and what result was seen, the verification is much weaker than it appears.
Governance implication: ownership should sit with the hiring or HR process, but the evidence standard should be defined centrally so teams do not improvise their own acceptance criteria. The safest approach is to treat the official service and the retained record as a paired control, not as separate optional steps.