CORE MODULE

Security Best Practices

What you'll learn in this guide

‍A practical set of habits and settings that keep your CX Platform environment — and the people you communicate with — safe. We'll cover the choices that matter most, from how you sign in, through how you manage users, to how you protect sensitive content.

Overview

Security in CX Platform isn't one big switch — it's a collection of small, sensible choices made in the right places. The platform gives you the tools to lock things down properly; this guide pulls together the practices we'd recommend every customer follow.

Most of what's covered here is configurable through Auth and the Security / data retention section of each Application. None of it requires a developer, and most of it takes minutes rather than hours.

Think of this as the security checklist you'd want to run through when you're setting up a new tenant, onboarding a new admin, or doing a quarterly review.

‍Who this is for
‍
System Administrators and tenant admins responsible for user access, Application configuration, or any sensitive content being sent through CX Platform. If that's you, the rest of this guide is worth a read.

‍

Protect how people sign in

Your sign-in process is the first line of defence. Get this right and the rest gets a lot easier.

  1. Use Single Sign-On wherever you can. SSO ties access to your organisation's existing identity provider, so when someone leaves the business, access is revoked centrally — no risk of a dormant CX Platform login being left behind.
  2. If SSO isn't an option, CX Platform has two-factor authentication in place. Every username and password login is paired with 2FA via SMS, so a stolen password on its own isn't enough to get in.
  3. Keep mobile numbers up to date in each user's profile. If someone changes their number and doesn't update it, they'll be locked out — and worse, the old number could end up reassigned to someone else.

‍

Never share login credentials
‍
Every admin should have their own account. Shared logins make audit logs meaningless — you'll never know who actually made a change — and they're impossible to revoke cleanly when someone moves on.

‍

Manage users and admins properly

Access creeps. Someone joins a project, gets given admin rights to get unblocked, and three years later they still have them. A bit of housekeeping keeps things tight.

  1. Assign at least two user admins per tenant, so you're never locked out if one person is unavailable.
  2. Grant the lowest level of access someone needs to do their job. If a user only needs to view reports, they don't need permissions to edit Applications.
  3. Review your user list at least once a quarter. Remove anyone who's left the business, changed roles, or no longer needs access.
  4. Check audit logs from time to time. They're not just for incidents — a quick scan tells you who's been making changes and whether anything looks unusual.

‍

Tie reviews to a calendar reminder
‍
Quarterly access reviews only happen if someone's responsible for them. Block out 30 minutes on the calendar and treat it like any other recurring task.

‍

Keep PROD and TEST clearly separate

Your Test environment exists so you can experiment without putting live data at risk. Use it that way.

  1. Try every configuration change in TEST first — new Applications, gateway changes, authentication factors, callbacks. Promote to PROD only once you're confident it works.
  2. Use dummy data in TEST. Never load real customer records, real email addresses, or real mobile numbers into a non-production environment.
  3. Check the URL before you make a change. The PROD/TEST tag is easy to spot in Auth, but it's worth double-checking when you're about to do something significant.

‍

Protect sensitive content with authentication factors

Anything containing personally identifiable information (PII) — statements, policy documents, account details — shouldn't be sent as a plain attachment. Use a secure link with an authenticated landing page instead.

  1. In your Application's Security / data retention section, nominate the authentication factors recipients need to provide. Surname plus date of birth is a common combination; pick what makes sense for the content you're sharing.
  2. Avoid factors that are easy to guess or already public. A postcode on its own is weaker than a postcode combined with something only the recipient would know.
  3. Send the secure link, not the document itself. The landing page does the gatekeeping, so the content stays protected even if the email is forwarded.

‍

Look after your gateway settings

Your gateway settings control how messages actually leave the platform, so they're worth a careful look.

  1. Keep Test mode switched on while you're building or trialling an Application. Switch it off only when you're ready to send for real.
  2. Set sensible send limits. A maximum hourly send rate stops a misconfigured campaign from going out at full volume before anyone notices.
  3. Use secure links and link tracking deliberately. Both have a place, but make sure recipients aren't clicking through trackers on content where that wouldn't be appropriate.
  4. Store gateway credentials (API keys, endpoints, passwords) only inside CX Platform. They shouldn't live in spreadsheets, shared notes, or emails.

‍

A quick checklist

If you want a single page you can run through, here's the short version.

Area What good looks like
Sign-in
  • SSO enabled where supported by your organisation.
  • 2FA enforced for any account not using SSO.
  • Mobile numbers current in every user profile.
Users and admins
  • At least two admins per tenant.
  • Least-privilege access — people only have what they need.
  • Quarterly reviews of the user list and audit logs.
  • No shared logins — every admin has their own account.
Environments
  • Test changes in TEST first, then promote to PROD.
  • Dummy data only in TEST — no real customer records.
  • Check the URL before making significant changes.
Sensitive content
  • Authentication factors nominated for any Application sending PII.
  • Secure links instead of plain attachments for sensitive documents.
  • Strong factor combinations — avoid anything publicly guessable.
Gateway settings
  • Test mode on during build, off only when ready to send.
  • Send limits set to catch misconfigured campaigns.
  • Credentials stored in CX Platform only — never in shared files.

What's next

None of this needs to happen all at once. If you've inherited a tenant and aren't sure where it stands, start with the sign-in section — that's the highest-impact area — and work your way down.

For the details on each area, head to the related guides on Auth, Applications, and authenticated landing pages.