Two-Factor Authentication (2FA) Service

The Two-Factor Authentication (2FA) service adds a native OTP-based verification step to EFCX user login. After a user signs in with their username and password, they must enter a one-time password (OTP) sent over a configured communication channel.

2FA is a tenant-level capability and, once enabled, applies consistently across all EFCX applications for that tenant.

Feature Summary

The OTP-based 2FA service strengthens security by:

Adding a second verification factor during login
Reducing risks from:
- Compromised credentials
- Unauthorized access attempts
- Shared or leaked passwords

The service enforces a controlled OTP lifecycle, including generation, delivery, validation, expiry, regeneration, and invalidation.

Prerequisites

Before enabling 2FA, ensure the following:

Channel Configuration
- The Email channel is configured in Unified Admin.
  See: https://expertflow-docs.atlassian.net/wiki/x/G4DJZ.
Tenant Configuration
- 2FA is enabled and fully configured via Tenant Settings API.
User Reachability
- Users have access to the selected delivery channel.

If no valid channel exists, 2FA configuration cannot be completed.

2FA is configured at the tenant level and applies uniformly to all users logging into Unified Admin and Agent Manager for that tenant.

Roles impacted

Once 2FA is enabled, the flow applies to:

Agents
Supervisors
Quality Managers
Evaluators
Routing Managers
Any other user accessing EFCX applications

There is no role-based or user-specific override. All users follow the same authentication flow.

Key Capabilities

Tenant-level enablement

2FA is enabled and configured from Tenant Settings. See 2FA Configuration Guide - Email.
Configuration applies globally across the platform for the tenant.
Changes take effect immediately for subsequent login attempts.

OTP delivery channels

The service supports OTP delivery through:

Email
Authenticator Apps
SMS (Future Scope)
Social Media Connectors (Future Scope)

Only one channel type can be active per tenant at a time.
The selected channel is used consistently for all OTP delivery.
Channels must be pre-configured in Unified Admin before they can be selected for 2FA.

User registration and reuse

Users who have not previously registered for 2FA are prompted to register during login.
The entered email is confirmed and stored with the user profile.
On subsequent logins, OTPs are sent automatically to the stored contact.

Email uniqueness considerations:

The same email should not be configured for multiple users.
If two user accounts share the same email and both request an OTP at the same time, only the most recently generated OTP is valid.
When one agent logs in successfully using the latest OTP, the other agent will not be able to log in with an older OTP.

OTP lifecycle enforcement

The OTP service enforces the following controls:

Time-bound expiry: OTPs are valid only for a configured duration.
Single-use validation: An OTP becomes invalid immediately after successful verification.
Regeneration support: Users can request a new OTP if delivery fails.
Cooldown enforcement: Regeneration is restricted until a cooldown period expires.
Invalidation on regeneration: Previously issued OTPs are invalidated when a new one is generated.

Consistent user feedback

The login flow provides clear feedback for:

Invalid OTP
Expired OTP
Regeneration wait time
Verification failure due to exceeded limits

Error messages are intentionally generic to avoid exposing sensitive system details.

Limitations and Constraints

The following limitations apply to this release:

Only one OTP delivery channel can be active per tenant.
No fallback or secondary channel is supported.
User-level brute-force tracking and lockout are not enforced by the OTP service itself.
The same email address should not be used for more than one user.

What’s New Compared to Previous Behavior

Current Implementation	Previous Implementation
OTP generation and validation are handled by a native EFCX OTP service. Delivery uses ExpertFlow-managed connectors for Email. Channel providers are configurable via Unified Admin. OTP lifecycle controls (expiry, regeneration, invalidation) are centrally enforced. Previous SMS OTP support via Twilio has been removed.	OTP delivery relied on Twilio-based SMS. Authentication logic was tightly coupled to a specific third-party provider. Channel selection and lifecycle control were limited.

This change improves extensibility, reduces vendor dependency, and aligns authentication behavior across the platform.

Out of Scope

The following capabilities are not part of this release:

SMS-based 2FA
WhatsApp and other additional channels.
Backup or alternative authentication channels
Trusted device/ “remember this device” behavior

FAQs

Q1. My OTP is always shown as invalid. Why?

Possible causes:

The OTP has expired; request a new OTP and try again promptly.
You are entering an old OTP after a newer one has already been generated.
Your user account may share the same email with another account, and the other user triggered a newer OTP.

Ask your admin to confirm that your account uses a unique email address.

Q2. I did not receive my OTP. What should I check?

Confirm that the email stored in your profile is correct and accessible.
Check spam/junk folders for OTP emails.
If the problem persists, contact your system administrator.

Q3. I get an error saying I exceeded the allowed attempts or must wait. What should I check?

The OTP service enforces a cooldown and attempt limits.
Wait for the configured cooldown period to pass, then request a new OTP.
If the issue continues, your admin should check the tenant 2FA configuration and logs.

Q4. Can I disable 2FA just for specific users or roles?

No. 2FA is enforced at the tenant level.
Once enabled, it applies uniformly to all EFCX users under that tenant.

Q5. Can users choose a different OTP delivery channel (e.g; switch from Email to SMS)?

Not in this release.
Only one delivery channel can be active per tenant; users cannot override the selected channel individually.