Digital Intelligence SDK FAQs

General product behavior

Does Digital Intelligence collect and maintain device-based or hardware-based identifiers like IMEI, MAC address, or SIM card numbers?

Digital Intelligence SDKs do not collect or expose hardware identifiers such as IMEI, SIM, or eSIM information.

• No IMEI or SIM/eSIM identifiers:
  Modern iOS and Android platforms restrict access to these identifiers. As a result, our SDKs neither collect nor expose SIM/eSIM details, and IMEI is not collected.

• No hardware MAC address:
  Mobile operating systems and modern browsers obfuscate or block access to hardware MAC addresses. Our SDKs therefore do not collect or expose a device’s hardware MAC. Instead, our signals rely solely on OS-permitted attributes to ensure privacy compliance and reliable device intelligence.

Cross-platform field availability

Why are some Digital Intelligence response fields only available on certain platforms?

Each SDK platform (iOS, Android, Web) has access to different operating system APIs and browser capabilities. For example:

• Native mobile SDKs (iOS and Android) can access GPS, battery status, VPN state, and CPU architecture through OS-level APIs.
• The Web SDK collects browser-specific signals such as WebRTC IPs, user agent strings, WebGL renderer details, and HTML form submission events.

Because these capabilities are inherent to each platform, certain fields are only populated when the session originates from a compatible SDK. Server-side fields (network analysis, history, entity profiling, and velocity metrics) are always available regardless of the client platform.

Why don't I see webRtcPublicIp or webRtcInternalIp in mobile SDK sessions?

WebRTC is a browser API that enables peer-to-peer communication and can reveal the user's real IP address even behind a VPN or proxy. Native mobile SDKs for iOS and Android do not use WebRTC, so these fields are only populated for sessions captured by the Web SDK.

For mobile sessions, use the device.network.connectionIp and device.network.realIp fields, which are available on all platforms.

Why is vpnStatus not available on Web?

The device.attributes.network.vpnStatus field relies on native OS APIs that report whether a VPN connection is active. Browsers do not expose this information to web applications.

For web sessions, use the server-side network analysis fields (device.network.isVpn, device.network.isProxy, device.network.isConsumerPrivacy) to detect VPN and proxy usage through IP reputation analysis. These fields are available on all platforms.

Why is isTamperedAndroidBuild only reported for Android?

The device.computed.isTamperedAndroidBuild field detects whether the Android OS build differs from the manufacturer's original version (for example, custom ROMs). This check is specific to the Android operating system and has no equivalent on iOS or Web.

For iOS, jailbreak detection is available through device.attributes.iOSAttributes.isRooted. For web sessions, use device.computed.isVirtualMachine and behavioral signals to assess session integrity.

Why are location and battery fields sometimes missing from mobile sessions?

Location and battery data require specific conditions to be collected:

• Location requires explicit user permission. If your app hasn't requested location access or the user has denied it, these fields are omitted. You can suppress location collection by setting omitLocationData to true in SigmaDeviceOptions.
• Battery data depends on device state and OS-level access. In rare cases, the OS may restrict battery information.

Missing fields do not indicate an SDK error. Design your workflows to handle optional fields gracefully.

Why is submissionCount only populated for Web sessions?

The behavioral.aggregations.submissionCount field counts HTML form submission events, which are specific to browser-based environments. Native mobile apps do not use HTML form submissions.

For mobile sessions, use other behavioral aggregation fields (clickCount, inputChangeCount, focusCount) to assess user interaction patterns. These fields are available across all platforms.

Why are many Digital Intelligence fields showing high null rates in my data?

High null rates are common when analyzing Digital Intelligence data in aggregate across all platforms. There are three main causes:

1. Platform-specific fields return null on non-matching platforms. For example, androidAttributes.isRooted is null for every iOS and Web session. If your traffic is 80% Web and 20% Android, this field is null 80% of the time — by design. Filter your analysis by device.attributes.platform to see accurate null rates per platform.

2. Permission-dependent fields are null when permissions are denied. Location fields (device.attributes.location.*) require the user to grant location access. If most users deny the permission, these fields have high null rates on mobile. Battery fields have similar behavior.

3. Input-dependent fields are null when data isn't provided. Velocity metrics (such as velocityMetrics.historicalCount.surName) require the corresponding PII fields (surname, email, mobile number) in the Evaluation API request. deviceContext requires passing a context string to processDevice(). customerUserId and userId are optional fields that must be explicitly provided.

Refer to the Data Dictionary platform availability section for a per-field breakdown of which platforms support each field.

Which fields depend on input data in the evaluation request?

Several Digital Intelligence response fields are only populated when specific data is included in the RiskOS™ Evaluation request:

• Velocity metrics (velocityMetrics.historicalCount.*) — Requires the corresponding PII fields: firstName, surName, email, or mobileNumber. If you omit surName from the request, velocityMetrics.historicalCount.surName is null.
• Entity profiler (entityProfiler) — Populated based on the PII entities (phone, email, nationalId) included in the request.
• customerUserId — Optional. Only populated if provided in the evaluation request.
• userId — Optional. Only populated if provided in the evaluation request.
• deviceContext — Only populated if a context string is passed to processDevice() on the client.

SDK blocking and ad blockers

We've previously had trouble with a similar vendor's SDK being blocked by ad blockers. Are there any known issues or best practices we should be aware of to prevent this with your SDK if needed?

Mainstream ad blockers (using default settings) typically do not block the Digital Intelligence (DI) Web SDK.

However, most SDK failures we observe are caused by:

• Enterprise firewalls
• VPN configurations
• Strict Content Security Policies (CSPs)
• Network restrictions that block SDK scripts or ingestion endpoints

Required endpoints

The DI SDK requires access to the following endpoints from the browser or application:

Best practices to prevent blocking

1. Allowlist Socure DI endpoints in your Content Security Policy (CSP) and network egress

Add Socure DI endpoints to your CSP allowlist:

CSP connect-src: https://ingestion.dv.socure.io https://network.dv.socure.io https://analytics.dv.socure.io

If loading the SDK via script tag, also allowlist the SDK host:

CSP script-src: https://sdk.dv.socure.io

2. Use NPM package installation (recommended)

Installing the Web SDK via NPM (instead of script tags) provides several advantages:

• Avoids content filters targeting third-party script hosts
• Improves load reliability in JavaScript frameworks (React, Angular, Vue)
• Reduces dependency on external CDNs

3. Optional: Use a reverse proxy (advanced)

For highly restrictive environments, configure the SDK to route through a customer-owned reverse proxy using the configBaseUrl parameter. This makes traffic appear as first-party requests.

Please coordinate with Socure before enabling this setup.

4. Implement graceful fallback and retry

Retry mechanism: Add retry logic with exponential backoff for session initialization

• Timeout handling: Handle transient network issues (DNS resolution, mobile network hiccups)
• Fallback strategy: Ensure your application continues to function when session tokens are unavailable

This approach ensures other verification checks can proceed even if the DI SDK encounters issues.

Field availability by platform

The Digital Intelligence SDK collects different signals depending on the platform (iOS, Android, or Web). The following table summarizes key differences. For a complete list of all fields, see the Digital Intelligence data dictionary.

Why are some Digital Intelligence fields not available on all platforms?

Field availability differs across iOS, Android, and Web because each platform exposes different OS-level APIs and enforces different privacy restrictions:

• Operating system restrictions:
  Mobile platforms (iOS and Android) provide access to native APIs for telephony, battery, VPN interface inspection, and hardware integrity checks that are not available in browser environments. Conversely, browsers expose web-specific APIs (WebRTC, WebGL, user agent parsing) that native SDKs do not use.

• Privacy and permission models:
  Each platform enforces its own permission model. For example, GPS location requires explicit user permission on all platforms, but the mechanism differs — native SDKs use CoreLocation (iOS) or LocationManager (Android), while the Web SDK uses the browser Geolocation API. Some signals (for example, carrier name) require permissions that only exist on mobile.

• Platform-specific security signals:
  Certain fraud signals are inherently platform-specific. Root/jailbreak detection applies only to mobile devices. Tampered build detection applies only to Android. Browser attributes (WebGL renderer, hardware concurrency) apply only to web.

• All platforms share core signals:
  Network-level intelligence (IP analysis, ISP, ASN, proxy/VPN/Tor detection), device history, velocity metrics, and entity profiling are available across all platforms because they rely on server-side analysis rather than client-side APIs.