A concise description of how staff sign in, how sessions are renewed and revoked, and how workspace access is assigned. It is written to paste into an IT or procurement review, with current limitations stated alongside shipped controls.
Ask an access questionStaff authenticate through WorkOS AuthKit's hosted flow. Vericode relies on the resulting WorkOS session rather than collecting sign-in credentials in its own page. Available connection methods are managed through WorkOS configuration.
An authenticated request is resolved against a workspace and its membership. Staff roles describe the user's general responsibility within that workspace; API access is represented separately as machine access.
The application rotates refresh tokens for the web app and Sidekick. Ending a departing team member's access is a support-mediated action today, not an automated org-membership-removal or full-session-revocation event triggered by the product itself.
Workspace joining requires an invitation, deactivation is support-mediated, and SCIM directory sync is not available. Enterprise federation and organisation-wide MFA enforcement are not published as standard product commitments today.
Vericode uses WorkOS AuthKit for staff authentication. Selecting sign-in sends the user to the WorkOS-hosted sign-in flow, then returns the authenticated user to Vericode. The available sign-in methods are configured by Vericode through WorkOS rather than being hard-coded into the application.
Enterprise federation availability and configuration are not yet published as a standard product commitment; ask about the needs of your workspace. Vericode does not present SAML or enterprise SSO as a standard, purchasable feature today.
Staff authentication is handled through WorkOS. A documented, organisation-wide MFA enforcement policy is not yet published; formalising and evidencing that policy is planned. An identity provider may apply its own MFA controls, but that is not a Vericode-wide enforcement claim.
The web application uses a WorkOS-issued session stored in the session cookie namedwos-session. Vericode validates WorkOS as the token issuer.
Refresh-token rotation is implemented for the web application and Sidekick browser extension. A successful refresh returns a rotated token rather than relying on one long-lived browser credential.
There is no self-service, one-click deactivation in the dashboard, and no automated event in the product that removes WorkOS organisation membership or revokes every session on its own. The documented path today is to ask support to action the removal; see the staff lifecycle runbook for the current process.
Vericode does not publish or configure a specific access-token lifetime. Access tokens follow WorkOS platform defaults and are refreshed through rotation, so this page does not substitute an invented time-to-live figure for a verified setting.
Token validation allows two minutes of clock skew to accommodate small time differences between systems. That tolerance is not an access-token lifetime and should not be read as a two-minute session or revocation window.
Requests are scoped to a workspace. Roles provide broad application boundaries, while individual endpoints enforce the permissions relevant to their operation. Vericode does not publish a fine-grained capability matrix, so the descriptions below state each role's general purpose without implying unverified per-screen entitlements.
Workspace ownership and full control. Ownership takes precedence over other role assignments.
Reserved for day-to-day team and access administration. Defined in the permission model today, but not yet assignable to a workspace member.
Review and export access for verification evidence and audit activity.
Day-to-day use of Vericode's authorised-contact verification workflow.
An additional Api role identifies machine access through API keys; it is not a staff role for interactive sign-in.
Owner is derived from workspace ownership rather than assigned as an ordinary team role, and ownership wins when the application resolves access. Compliance Officer and Member are the roles a workspace member can hold today; Admin exists in the permission model but is not yet assignable to an individual member. These labels support separation of responsibilities, but they should not be treated as a substitute for a customer's own joiner, mover and leaver approvals or periodic membership review.
Staff join a workspace through an explicit invitation. Email-domain auto-join is not implemented, so control of a matching business email address does not by itself grant workspace membership.
Automated directory-sync deprovisioning through SCIM is not available today. Use the support-mediated deactivation and revocation process, retain the confirmation with the departure record, and complete the surrounding handover steps.
Open the staff lifecycle runbookCustomer and verification data (recipient details, messages and verification records) is hosted in Australia. Staff sign-in is handled by our identity provider, WorkOS, in the United States; see the data-residency page for subprocessor information.
Review data residency and provider contextThe Sidekick extension connects to the staff member's Vericode workspace and uses the implemented refresh flow described above. For network review, the documented production allowlist is app.vericode.com.au, api.vericode.com.au and api.workos.com. The managed-rollout guide covers the current installation boundary, browser policy options and limitations for Intune and Group Policy deployments.
This brief is intentionally limited to authentication, sessions, roles and lifecycle. Use the security overview for wider controls and the trust FAQ for current assurance, privacy, resilience and engineering answers.