Account Provisioning Saves Account Locally Even When Remote Provisioning Fails

Products

• CA Strong Authentication

Issue/Introduction

During account provisioning using the CA Mobile Authenticator / Mobile OTP iOS SDK, the account is saved locally on the device even though the remote provisioning network call fails.

From the application perspective:

• The SDK returns a provisioning error.

• However, the account data is still persisted locally.

• This behavior is unexpected, especially when the application passes a parameter intended to prevent any remote/network provisioning call.

Observed Behavior

• A remote provisioning request is triggered despite the application expecting a local-only provisioning flow.

• When the remote call fails, the SDK:

  • Returns an error to the application

  • Still saves the account locally

• This can lead to confusion, inconsistent account state, or duplicate provisioning attempts.

Environment

CA Mobile Mobile OTP SDK 

Advanced Authentication 9.1.x

 

Cause

The behavior is related to the roam parameter, which is a mandatory attribute in the provisioning response XML received from the server.

Key details:

• roam indicates whether the user is opting for roaming-based provisioning.

• The default value of roam is False.

• When roam=true:

  • The SDK assumes roaming is enabled

  • A remote provisioning call is initiated, even if the application intended to suppress it

• If the server response XML does not explicitly handle or override this parameter, the SDK proceeds with roaming behavior by design.

Why the Account Is Still Saved Locally

In roaming scenarios:

• The SDK processes and stores the account details locally as part of the provisioning flow

• Even if the remote call fails afterward, the local persistence has already occurred.

Resolution

To avoid this behavior, customers must ensure that:

• The roam parameter is correctly defined and handled in the server-side provisioning response XML

• The provisioning flow aligns with the intended use case (roaming vs non-roaming)

Broadcom has documented the roaming behavior and its impact on provisioning in the official documentation.

Reference Documentation

• CA Mobile OTP SDK – Build and Integration Guide
  https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/advanced-authentication/9-1/clients-reference-material/ca-mobile-otp-reference-material/ca-mobile-otp-crypto-sdk-desktop-client/ca-mobile-otp-sdk-build-and-integration.html
• Response.xml File
  https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/advanced-authentication/9-0/installing/ca-adapter-installation/ca-adapter-configuration-files-and-options/response-xml-file.html 

Additional Information

• This behavior is by design and not considered a defect.

• Applications implementing headless provisioning or custom provisioning flows must explicitly align server responses with SDK expectations.

• If clarification is needed on roaming vs non-roaming provisioning, Broadcom Support can assist with guidance, but implementation changes must be handled by the customer’s development team.