ExplanationUnderstand the concepts

Understanding multi-factor authentication

Multi-factor authentication (MFA) adds a second step to signing in to Storyteq CMP. After entering their email and password, a user enters a one-time code from an authenticator app on their phone. Someone who has stolen or guessed a password still can’t sign in without that phone.

This page explains who MFA applies to, what signing in looks like once it’s on, and how recovery works when someone loses their phone. It’s written for administrators deciding whether to turn MFA on, and for anyone who wants to understand the sign-in step before they meet it.

Who MFA applies to

MFA is a setting for your whole organisation, so it’s either on for everyone or off for everyone. Storyteq turns it on when your organisation asks: your Storyteq contact makes the change, and it can take up to 5 minutes to apply. Once it’s on, every user who signs in with an email and password must use it, whether they sign in through Content Portal or Adaptation Studio. You can’t exempt individual users.

Users who sign in through your company’s single sign-on aren’t asked for a code. Your identity provider already authenticates them, so its rules apply instead. To require a second factor for those users, enforce it in your identity provider.

MFA uses an authenticator app on the user’s phone, which generates time-based one-time passwords. SMS codes, email codes, push approvals, and hardware security keys aren’t available. The apps that work, and the settings they need, are listed in Authenticator apps and sign-in messages.

What signing in looks like

The first time a user signs in after MFA is turned on, they set it up themselves. After their password, a setup screen shows a QR code. They scan it with their authenticator app, which links the app to their account, and then enter the code the app displays. Nobody needs to prepare anything for them in advance.

On every later sign-in, the user enters their email and password, then the current six-digit code from the app. The app generates a new code every 30 seconds.

A successful sign-in starts a session on that browser, so the user isn’t asked for a code every time they open Storyteq CMP. The session lasts up to 30 days from when they signed in. They sign in again, with a code, when the session ends, when they sign out, when they use a different browser or device or a private window, or when they clear their browser’s cookies.

The steps users follow are in Sign in with multi-factor authentication.

Turning MFA on and off

Users who are already signed in aren’t signed out straight away. Within about 5 minutes, when their sign-in refreshes, they’re sent to the MFA step. If they haven’t set up an authenticator yet, they set it up then.

When MFA is turned off, users sign in with their email and password only. The change can take up to 5 minutes to apply, so users may still be asked for a code during that time. The storyteq.com entry in each user’s authenticator app stays where it is. If MFA is turned on again later, users carry on with that same entry, without setting it up again.

A user’s setup also survives their account being deactivated and reactivated. The only thing that removes it is an administrator resetting it, as described in the next section.

When someone loses their phone

MFA has no self-service backup codes. A user who loses their phone, replaces it, or deletes the authenticator app can’t generate codes, so recovery goes through an administrator.

The user requests a reset from the sign-in screen. The request goes by email to a mailbox your organisation chooses, such as an IT helpdesk inbox. An administrator checks that the request is genuine, then resets the user’s one-time password in Platform Administration. The user’s next sign-in shows the setup screen again, so they can link their new phone. The old entry in their authenticator app stops working.

Anyone who can reach the sign-in page can send a reset request in a user’s name. The administrator’s check keeps the second factor meaningful. It happens through a separate channel, such as a phone call or chat, so that the email alone can’t get anyone a reset.

Because a person handles every reset, recovery isn’t instant. Before MFA is turned on, your organisation sends its Storyteq contact the address of the mailbox that should receive reset requests. Until that mailbox is set up, users who lose their phone can’t request a reset from the sign-in screen.

The administrator’s side of this, from rollout to resets, is in Manage multi-factor authentication.

Sign-in records

Every sign-in attempt is recorded, including failed attempts and wrong codes. There’s no lockout after repeated failed attempts, so a user who enters a wrong code can keep trying. Records are kept for 90 days. Administrators can’t open the records in Storyteq CMP; to get an export, ask your Storyteq contact.