--- sourceDocument: Australia Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/australia/platform-security Release : - australia ft:locale : - en-US ft:publication_title : - Australia Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Human-assisted SMS OTP authentication # Human-assisted SMS OTP authentication {#ariaid-title1} Release version: Australia Updated November 5, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Human-assisted SMS OTP authentication Human-assisted SMS OTP authentication enables a human agent to verify an end user's identity by sending a one-time passcode (OTP) via SMS during a live interaction. The agent initiates OTP generation and validation through platform scriptable APIs, while the consuming application (such as Customer Service Management or Field Service Workspace) manages the agent workflow and user interface. This feature is distinct from SMS OTP used in AI voice agent authentication and requires explicit enabling via a system property. Show full answer Show less ## When to Use * Verify end user identity during sensitive operations handled by a human agent, not an AI voice agent. * Examples include authorizing wire transfers, processing high-risk requests in live chat or phone interactions, and verifying contacts before sharing account-specific information. ## How It Works * The agent identifies the end user and triggers OTP generation via the generateCode API. * The platform generates the OTP and either sends it directly to the user (Out-Of-the-Box mode) or returns it for the consuming application to send (Bring-Your-Own mode). * The end user reads the OTP back to the agent, who submits it for validation through the validateCode API. * The platform validates the OTP and returns the result, allowing the consuming application to update the interaction accordingly. ## Delivery Modes * **OOB (Out-Of-the-Box):** Platform sends SMS using a configured provider like Twilio or Infobip. Default mode. * **BYO (Bring-Your-Own):** The platform returns the OTP, and the consuming application manages SMS delivery via its own infrastructure. ## Phone Number Resolution * In OOB mode, the platform resolves the phone number either from the consuming application's API request or from a configured table and column. * In BYO mode, the consuming application determines the recipient number; the platform does not resolve phone numbers. * Note: For custom SMS providers, phone number resolution prioritizes the MFA Provider Custom configuration. ## Rate Limiting and Retry Controls * Limits include maximum OTP requests per tenant and per agent per minute, and per-user retry limits for validation failures. * Resend cooldown enforces a minimum wait time between sending new OTPs within the same conversation. * Retry counts failed validations; resends do not consume retry attempts. ## Audit Trail All OTP generation and validation calls are logged with relevant identifiers and timestamps. Audit records are retained for 90 days and managed by a cleanup job to support compliance and troubleshooting. ## Limitations * Not available as a factor in AI Voice Assistant Designer; operates solely via scriptable APIs. * No built-in agent-facing UI; consuming applications must implement the agent workflow. * In BYO mode, the platform lacks visibility into SMS delivery status. * Combination of BYO delivery mode with configuration-table phone number resolution is unsupported. ## Availability and Requirements * Requires installation of the HA SMS OTP plugin and its dependency on the SMS MFA plugin. * For OOB mode, an active SMS provider configuration is necessary. * Users or scripts must have appropriate roles (snauthhasmsotpcaller), and the consuming application scope must have granted API execution permissions. Human-assisted SMS OTP lets a human agent verify an end user's identity by sending a one-time passcode via SMS during a live interaction. The agent initiates OTP generation and validation through the platform's scriptable APIs, and the consuming application (for example, CSM or FSO workspace) handles the agent-facing workflow and user interface. Note: * This capability is separate from the SMS OTP factor used in AI voice agent authentication. SMS OTP for AI voice agents is configured in AI Voice Assistant Designer and executed by the orchestrator during automated calls. Human-assisted SMS OTP is triggered by a human agent and is not part of the AI voice agent flow. * You can enable human-assisted SMS OTP using the `glide.auth_factors.ha_sms_otp.enabled` property. Set it to `false` to turn the feature off; the default is `true`. Read and write access to this property is restricted to users with the `sn_auth_ha_sms_otp_admin` or `security_admin` role. {#human-assisted-sms-otp__ul_tpz_pln_lkc} ## When to use human-assisted SMS OTP {#human-assisted-sms-otp__when-to-use} Use human-assisted SMS OTP when a human agent needs to verify the end user's identity before performing a sensitive operation, and the interaction is not handled by an AI voice agent. Examples: * A customer service agent verifies a caller's identity before authorizing a wire transfer or account change. * A support agent confirms the end user's identity during a live chat or phone interaction before processing a high-risk request. * A field service agent verifies a contact before sharing account-specific details over the phone. ## How human-assisted SMS OTP works {#human-assisted-sms-otp__how-it-works} 1. The human agent identifies the end user in the consuming application. 2. The agent triggers OTP generation. The consuming application calls the generateCode API. 3. The platform generates a one-time code. * In OOB mode, the platform dispatches the SMS directly to the end user's phone using the configured SMS provider. * In BYO mode, the platform returns the code in the API response. The consuming application dispatches the SMS through its own provider. 4. The end user receives the SMS and reads the code back to the agent. 5. The agent submits the code. The consuming application calls validateCode. 6. The platform validates the code and returns a result. The consuming application updates the interaction accordingly. ## Delivery modes {#human-assisted-sms-otp__delivery-modes} {#human-assisted-sms-otp__delivery-modes__entry__2} | Mode | Behavior | |-|-| | OOB (Out-Of-the-Box) | The platform sends the SMS directly to the end user using the configured SMS provider (Twilio, Infobip, or Custom). Default delivery mode. | | BYO (Bring-your-own) | The platform returns the OTP in the API response. The consuming application handles SMS delivery through its own infrastructure. | [ ] ## Phone number resolution {#human-assisted-sms-otp__phone-resolution} When delivery mode is OOB, the platform resolves the end user's phone number using one of two strategies. {#human-assisted-sms-otp__phone-resolution__entry__2} | Strategy | Behavior | |-|-| | Provided by calling application | The phone number is supplied in the API request by the consuming application. | | Resolved from configured table | The platform resolves the phone number from a table and column configured in the HA SMS OTP service configuration. | [ ] When delivery mode is BYO, the consuming application handles delivery and determines the destination number. The platform does not resolve or use a phone number. Note: If Delivery Mode is set to OOB and your SMS provider is a Custom type, phone number resolution uses the table and field configured in your MFA Provider Custom config record, not the Phone Number Resolution selection in the HA SMS OTP configuration. In case of a mismatch, the MFA Provider Custom config takes precedence. ## Rate limiting and retry behavior {#human-assisted-sms-otp__rate-limiting} {#human-assisted-sms-otp__rate-limiting__entry__3} | Limit | What it controls | Default | |-|-|-| | Per tenant per minute | Maximum OTP requests across all agents in the tenant. | 100 | | Per agent per minute | Maximum OTP requests a single agent can trigger. | 10 | | Per-Conversation User Retry Limit | Maximum failed validation attempts for a single end user within one conversation. Counts incorrect code submissions only. | 3 | | Global User Retry Limit | Maximum failed verification attempts for a single end user within the configured retry window. When exhausted, the user is locked out for the configured lockout duration, after which the counter resets. | 10 | | Resend cooldown | Minimum time between consecutive OTP generation requests within the same conversation. | 60 seconds | [ ] Note: Retry and resend are independent counters. Retry counts failed validation attempts (incorrect code submitted). Resend counts new OTP generation requests (new code sent). Triggering a resend does not consume the retry budget. ## Audit trail {#human-assisted-sms-otp__audit-trail} Every generateCode and validateCode call is logged with the agent ID, end user ID, conversation ID, phone number (for OOB), result, and timestamp. Audit records are retained for 90 days by default. A table cleaner job manages retention. ## Limitations {#human-assisted-sms-otp__limitations} * Human-assisted SMS OTP is not available as a factor in AI Voice Assistant Designer. It operates independently through the scriptable APIs. * The platform does not provide an agent-facing UI for triggering or validating OTP. The consuming application must build and maintain the agent workflow. * In BYO mode, the platform has no visibility into whether or where the SMS was actually delivered. Audit records reflect only what was passed to the API. * The combination of BYO delivery mode with config-table-lookup phone number resolution is not supported and is blocked at save time. ## Availability {#human-assisted-sms-otp__availability} Human-assisted SMS OTP is available when the following conditions are met: * The HA SMS OTP plugin (`sn_auth_ha_sms_otp`) is installed. This plugin depends on the Multi-factor authentication with SMS plugin (`com.snc.authentication.sms_mfa`). * For OOB delivery: an SMS provider (Twilio, Infobip, or Custom) is configured and active under Multi-factor Authentication \> Providers. * The calling user or script has the `sn_auth_ha_sms_otp_caller` role. * The consuming application scope has been granted explicit permission to execute the HA SMS OTP API methods. **Related concepts** * [Configuring authentication factors for AI voice agents](https://www.servicenow.com/docs/beBiwnUoZfSUJbCPFuwWfw "To secure voice agent environments, configure authentication factors that first identify the caller, then authenticate them before granting access.") **Related tasks** * [Configure human-assisted SMS OTP](https://www.servicenow.com/docs/0HSkmGKdQ1kla0ZRcZV1SA "Configure the HA SMS OTP service to enable human agents to generate and validate one-time pass codes during live interactions.")