Silent Network Authentication (SNA)

Overview

Silent Network Authentication (SNA) is a phone number verification method that authenticates users through their mobile network using real-time carrier signals.

Instead of relying on one-time passwords sent via SMS, SNA verifies that the device associated with the provided phone number is active and connected to the mobile network. This validation happens through secure interactions with mobile network operators, establishing a strong proof of possession tied to the SIM.

SNA is available as part of Incode's phone verification capabilities and can be used within identity verification workflows to strengthen verification while maintaining minimal user friction.

Benefits of SNA

SNA enhances phone number verification by improving user experience, reliability, and security.

• Low friction user experience - Users only need to enter their phone number, after which verification happens seamlessly in the background without requiring OTP retrieval or manual input. This simplifies the flow, reduces user effort, and improves completion rates.
• Reliable verification - By removing dependency on SMS delivery, SNA avoids common issues such as message delays, delivery failures, and repeated OTP requests. This leads to a more consistent and predictable verification experience.
• Improved security - SNA shifts verification from message-based authentication to carrier-level validation, significantly reducing exposure to SMS-based threats such as phishing, OTP interception, and SIM swap-related attacks.

Other considerations

• Requires mobile network connectivity - SNA relies on communication with the mobile carrier network and will not work if the device has no mobile data connectivity.
• Fallback required for full coverage - In cases where SNA is not supported due to device, carrier, or connectivity constraints, fallback mechanisms such as SMS OTP are required to complete verification.

Incode SNA for stronger Identity Verification

SNA provides a strong, real-time signal that a user controls the phone number they are claiming, by validating the association between the device and SIM through the mobile network. Within Incode, this signal becomes a key input into broader identity verification and fraud detection workflows.

On its own, SNA answers foundational questions about phone ownership and device linkage. When combined with other Incode signals such as biometrics, document verification, and device intelligence, it helps create a more complete and reliable view of the user.

This allows you to make stronger identity decisions by answering questions such as:

• Does the user control this phone number?
• Is this number actively linked to the device being used?
• Has this phone or device been reused across multiple accounts?
• Is this identity linked to known or previously detected fraud?
• Is this identity part of a suspicious network of users or devices?

These insights are powered by Incode's ability to connect signals across sessions and workflows, enabling detection of repeat fraud, account sharing, and coordinated activity.

For deeper network-level insights and relationship-based risk analysis, SNA can be combined with Incode's Trust Graph.

Implementation details

Sequence diagram

The sequence diagram below illustrates how SNA is executed within Incode, including coverage checks, carrier validation, and fallback to SMS OTP when required.

How to use SNA with iOS SDK

• Use an SDK variant that includes the -sna suffix (for example, 5.43.0-s-sna).
• Configure a flow on the dashboard with SNA enabled in the Phone Number Input module.
• Start the onboarding flow:
  • Using startFlow or startOnboarding
    • Specify configurationId inside IncdOnboardingSessionConfiguration that is provided as sessionConfig to the startFlow / startOnboarding methods
  • Using Sections:
    • Specify configurationId inside IncdOnboardingSessionConfiguration that is provided as sessionConfig to the setupOnboardingSession method
    • Call startOnboardingSection with the Phone module provided to the IncdOnboardingFlowConfiguration

How to use SNA with Android SDK

• Use the Android SDK, version 5.50.0 or higher. SNA support is bundled - there is no separate -sna variant, and no additional Maven repository or credentials are required.
• Configure a flow on the dashboard with SNA enabled in the Phone Number Input module.
• Start the onboarding flow:
  • Using startFlow: specify configurationId inside SessionConfig.Builder().setConfigurationId() provided as sessionConfig to startFlow. SNA is driven entirely by the flow configuration; no additional code is required.
  • Using startOnboarding or Sections (where your app builds the FlowConfig): specify configurationId inside SessionConfig.Builder().setConfigurationId() (provided as sessionConfig to startOnboarding / setupOnboardingSession) and pass the Phone module in your FlowConfig. For Sections, call startOnboardingSection with that Phone module. SNA is enabled by the flow configuration alone - there is no client-side API to turn it on.

Requirements and fallback behavior (Android)

• SNA requires Android API level 24 or higher. On older devices the SDK silently falls back to SMS OTP.
• SNA also falls back to SMS OTP automatically when the number or carrier is not SNA-covered, when there is no cellular data path (for example airplane mode or a VPN-tunneled connection), or on a transient verification failure.
• The network permissions SNA requires (CHANGE_NETWORK_STATE, ACCESS_WIFI_STATE, CHANGE_WIFI_STATE) are bundled with the SDK and added to your app's merged manifest automatically - you do not need to declare them. They are normal (install-time) permissions, so no user prompt is involved.
• Optionally declaring the READ_PHONE_STATE runtime permission enables a 2G-network safety check that routes devices on insecure 2G networks straight to SMS OTP. The SDK never requests the permission itself; see the Optional permissions section of the Android setup guide.
• The third-party SDK that powers SNA is bundled inside onboard.aar; no additional Maven repository or credentials are required. If your app ships an open-source / third-party licenses screen, reproduce its license attribution (see Licenses).
• Bundling adds roughly 150 KB to the onboard artifact. The bundled SDK stays dormant unless the flow configuration enables SNA, and it is never loaded on devices below API level 24.
• Onboarding driven by the Workflows API does not support SNA yet - the Workflows Phone module configuration does not expose an SNA setting. Use a flow configuration (configurationId) for SNA.

How to use SNA with Native Web (coming soon)

Support for SNA on Native Web is coming soon.