CORE MODULE

Authentication Features

What you'll learn in this guide

An overview of the authentication features available in CX Platform forms — what each one does, how public and private forms differ, and which combination of features suits different real-world scenarios.

Overview

CX Platform gives you a layered set of authentication features to control who can access a form and how much they need to prove before they can interact with it. The right combination depends on how sensitive the form is, how it's being delivered, and what your compliance requirements are.

Authentication features are all configured in the Access and Authentication and Prefill Data Settings sections of the form template's Details tab. They're independent of each other and can be combined freely.

‍

Authentication features at a glance

Feature What it does Works with
Access mode (Public / Private) Controls whether the form is open to anyone with the link, or restricted to users with a valid private token from an API request. All forms
Authentication mode Requires the user to answer questions that match pre-supplied data before they can proceed — for example, surname and date of birth. Private forms
SMS MFA Sends a one-time passcode to a mobile number (prefilled or user-entered) that the user must enter to continue. Public and Private
Email MFA Sends a one-time passcode to an email address (prefilled or user-entered) that the user must enter to continue. Public and Private
KYC verification Requires the user to complete a real-time document identity check via the Chandler Verify add-on. Public and Private
Prefill data gates Holds back prefilled personal data until the user has passed the required authentication, MFA, or KYC steps. Private forms with prefill

‍

Public vs Private forms

The Access mode setting is the starting point for any authentication decision. It determines the delivery model for the form — and that shapes which authentication features are relevant.

Public forms

A public form is accessible to anyone with the URL — no token or login required. It's the right choice for general-purpose forms where restricting access would create unnecessary friction: open registrations, public feedback, event sign-ups, or general enquiries.

Authentication options for public forms are limited but still useful:

  • SMS Multi-Factor Authentication (user entered number) — the user provides a mobile number and receives an One-Time Pin to verify it. Useful for confirming a valid contact number without requiring private delivery.
  • Email Multi-Factor Authentication (user entered email) — the same pattern for email. Confirms the address is real and accessible before the submission is processed.
  • KYC (Know Your Customer) verification — a document identity check can be added to a public form when the nature of what's being collected requires it, even without a personalised link.

Public forms can't use Match to prefill data authentication or prefill data gates, since there's no API-supplied data to match against.

Private forms

A private form is delivered via a tokenised link generated by an API request — typically sent through CX Platform's Send module as part of an outbound communication. The token uniquely identifies the user session and can carry prefilled data.

Private delivery unlocks the full authentication stack:

  • Authentication mode (Match to prefill data) — the user must answer questions that match the prefill payload before proceeding.
  • SMS Multi-Factor Authentication (prefilled mobile number) — the One-Time Pin goes to a mobile number already held in your system, rather than one the user enters.
  • Email Multi-Factor Authentication (prefilled email address) — the same pattern for email.
  • KYC (Know Your Customer) verification — adds a full document check on top of the other layers.
  • Prefill data gates — hold back personal data until one or more of the above steps are passed. The user sees empty fields until they've verified.
‍Private forms need a Private / API access mode: Setting up authentication mode or prefilled MFA on a form that's still set to Public access mode won't work as expected. Make sure Access mode is set to Private / API in the Access and Authentication section before configuring anything that depends on a prefill payload.

‍

Use cases

Open registration or enquiry form

Access mode: Public — Authentication: None — MFA: None

A general-purpose form with no personal data and no access restrictions. Anyone with the URL can fill it in and submit. No verification required.

‍Suitable for: event registrations, public feedback surveys, general contact forms.

‍

Public form with email verification

Access mode: Public — Email MFA: User entered email

The user provides their email address and must verify it via OTP before the submission is accepted. Confirms the email address is real and accessible without requiring private delivery.

Suitable for: registrations where a confirmed email address is needed, lead generation forms, subscription sign-ups.

‍

Personalised form with prefill and identity gate

Access mode: Private / API — Authentication: Match to prefill data — Require authentication for prefill data: ticked

A tokenised link is sent to the user with their details pre-populated. They must enter their surname and date of birth before the form reveals any personal information. Wrong answers means no data is shown.

Suitable for: change of details forms, account updates, pre-filled applications where recipient confirmation is required.

‍

Sensitive form with authentication and SMS MFA

Access mode: Private / API — Authentication: Match to prefill data — SMS MFA: Prefilled mobile number — Require authentication and MFA for prefill data: both ticked

The user must first answer identity questions (surname, date of birth) and then verify via SMS OTP sent to their registered mobile number. Prefilled data is only revealed after both steps pass.

Suitable for: financial services forms, benefit claims, account management actions where two layers of confirmation are required.

‍

High-assurance application with full verification stack

Access mode: Private / API — Authentication: Match to prefill data — SMS MFA: Prefilled mobile number — KYC: Enabled — All three prefill data gates: ticked

Three layers of verification must be completed before any prefilled data is visible. Authentication confirms identity against known data. SMS MFA confirms access to a registered device. KYC verifies a government-issued identity document. Only then does the form surface personal or financial details.

Suitable for: new account opening, high-value transactions, regulated onboarding flows, and any scenario where positive ID verification is a compliance requirement.

‍

Public form with KYC for identity verification

Access mode: Public — KYC: Enabled (Make KYC optional: unticked)

The form is open to anyone, but all users must complete a document identity check via Chandler Verify before their submission is processed. No personalised link needed — the KYC step handles the identity requirement.

Suitable for: publicly accessible applications where positive identity verification is required, such as benefit eligibility forms or open enrolment flows.

‍

Choosing the right combination

A few questions that help narrow down what you need:

  • Do you already know who the user is? — if yes, Private / API delivery with prefill and authentication is usually the right model.
  • Does the form contain personal or financial data? — if yes, gate that data behind at least one verification step using Prefill Data Settings.
  • Is regulatory identity verification required? — if yes, add KYC. If it's a lighter-touch requirement, authentication plus MFA is usually sufficient.
  • Is the form publicly accessible? — if yes, authentication mode is limited to MFA or KYC (no prefill match). Use MFA to confirm a contact detail; use KYC to confirm identity.
  • Does the form use Save and Resume? — if yes, make sure the resume authentication settings match your prefill data gates. See the Configure Save and Resume guide.
Authentication in CX Platform is a stack, not a single switch. Each layer adds a gate — and each gate is only as strong as the configuration behind it. The guides linked throughout this article cover the detailed setup for each feature.