Module 12 · Account security

Lee en español: Módulo 12 · Seguridad de la cuenta.

Objective: protect access to the dashboard using two-factor authentication (2FA) or Single Sign-On (SSO), limit when and from where people sign in, control platform support access, understand single session and know how to audit who has logged into the account. Time: ~10 minutes · Prerequisites: a user with account_admin role (for SSO and audit) or any user (for your own 2FA).

1. Two-step verification (2FA)

Two-factor authentication (2FA) using an authenticator app (TOTP) is not mandatory by default, but everyone can (and should) enable it for their own account. It is configured from the Security section in the sidebar.

When enabled, the platform provides a QR code for your app (like Google Authenticator or Authy) and recovery codes. Save the recovery codes in a secure place: each works only once and they are your only way in if you lose your device.

What if someone loses their device and codes?

If someone on your team loses their authenticator app and didn't save the recovery codes, they won't be able to log in. However, the account is not lost:

A user with the account admin (account_admin) role for the same tenant can go to Security → Console Users, select the person, and remove the second factor from their account. To do so, the dashboard will require the admin to write a reason (which will be sealed in the audit log). Once removed, the person can log in with just their password and set up 2FA again.

Admins cannot remove their own from that screen

An admin cannot use the user list button for their own account — they must use their own 2FA tab and confirm the action with a second factor.

2. Sign-in audit

To know who signs in to the platform and when, account administrators have access to the Sign-in audit (inside the Security section).

This log shows every recorded sign-in attempt for your account, newest first: when it happened, which person, the method (password, two-step sign-in or SSO) and whether it succeeded or failed.

3. Single Sign-On (SSO / SAML)

If your company already uses an identity provider (like Entra ID, Okta, or Google Workspace), an admin can configure Single Sign-On (SSO) in the corresponding tab under Security.

Once configured and enabled:

• People log in by delegating authentication to your identity provider.
• You can share a direct, copyable link with your team in the format /login?sso=<your-tenant-id>. With that link, the login screen will immediately know which provider to send them to, without them having to remember or type the organization ID.

4. Login policy (by address and by hours)

An account admin can limit when and from where people sign in to the dashboard. It lives under Security → Login policy (/security/login-policy). Only account admins see it and it does not depend on any platform switch: it starts with no policy written, so signing in works as it always did until someone publishes one.

What you define:

• Mode: Off (nobody is restricted), Observe (nobody is refused; each sign-in the policy would have refused is recorded) or Enforce (a sign-in from an address or at an hour outside the policy is refused).
• Allowed addresses: one address or range (CIDR, IPv4 or IPv6) per line, up to 64. Empty means no restriction by address.
• Sign-in hours, per role (Members and Account admins): tick the open days and set their start and end time. A role with no open day has no hours restriction; a day left unticked is closed.
• Time zone (IANA name, for example America/Chicago): required when any hours are set.
• Reason: optional; kept in the history.

The platform checks the policy after the password is right and before a session is issued. Every change adds a new version and nothing is edited in place: the History of versions lists them all, newest first.

Start in Observe mode

Publish the policy in Observe and read the Who would have been left out report: it is read from your real sign-in trail and shows which people, and how many successful sign-ins, the policy would have refused. When the report is empty or acceptable, switch to Enforce. Enforcing needs at least one address or one set of hours.

Do not lock yourself out

When you save in Enforce mode, the platform checks that your own address, role and the current time pass the policy. If they would not, nothing is stored and you are told why. In Observe that check is not made (only that your address can be identified, if there is an address list): read the report before switching to Enforce.

If a cell does not measure the address people sign in from, the screen says so and only hours can be set there, not an address list.

Sign-ins refused by the policy are visible in the Sign-in audit (section 2).

5. Platform support access

Support access (Security → Support access, /security/support-access) is the time-limited consent you give so that a member of the platform support team can look at your account. Only account admins see these controls.

Who turns it on: it is off by default. It is a platform switch that only the founder changes, and the cell's ceiling must also be open; with the ceiling closed no customer can use it. Your grant, revoke and history screens keep answering either way, so you can always revoke and review what already exists.

What support sees: a support session is read-only. It can only read a closed set of data views (for example campaigns, agents, numbers, statistics and dispositions) and cannot write, export, or create or reveal credentials. Everything else is denied. Also, each support session lasts at most 60 minutes, and never past the grant's expiry.

How to grant it:

1. Go to Security → Support access, Grant access section.
2. Write the Reason (1 to 500 characters): name the support ticket or the specific reason.
3. Set the Duration in minutes, from 15 to 480 (60 if you give none). The platform fixes the expiry when the grant is created and it never moves.
4. Press Grant support access.

A grant records your consent; it does not open a support session by itself. There can be only one live grant per account: while one is live, the platform refuses a second until you revoke the first.

How to revoke it: in the history, press Revoke grant and confirm with Yes, revoke. You can do it at any time before the expiry.

What is recorded: the Access history lists, newest first, every event: grant created, grant revoked, support session opened, support session revoked, read served and read denied, with the actor and the detail. Events are append-only; they are never edited or deleted.

While a support session is open, everyone on the team sees a banner in the dashboard: "Platform support is in this account", with who it is and until when.

6. Single session per person

With single session, each person can hold only one dashboard session at a time. It prevents shared credentials and sessions forgotten on another machine.

Who turns it on: it is off by default and only the founder changes it, at a customer's request; there is no settings screen for it in your account. It is off because it disconnects a person from the seat they were working at.

When it is on:

• Every new sign-in (password, second factor, forced second-factor enrollment or SSO) ends the other open sessions of that same person.
• On the machine that was left out, the next action goes back to the sign-in screen with this notice: "Your session ended because you signed in again on another device or browser. Sign in here to continue; only one session per person is allowed."
• Each ended session leaves a row in an append-only log.
• It does not affect API keys (dd_) or the widget: they are not person sessions. Sessions already open when it is turned on are left alone until that person's next sign-in.

When it is off, signing in never touches another session and nothing changes.