---
title: Component interoperability
description: This page outlines how customers can allow users to authenticate on different platforms (web/mobile) regardless of which component they initially enroll from by leveraging client state.
component: recognize
page_id: recognize:introduction:component-interoperability
canonical_url: https://docs.pingidentity.com/recognize/introduction/component-interoperability.html
llms_txt: https://docs.pingidentity.com/recognize/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
section_ids:
  interoperability-between-pingone-recognize-components: Interoperability between PingOne Recognize components
  how-pingone-recognize-client-state-works: How PingOne Recognize client state works
  possible-scenarios-relating-to-interoperability: Possible Scenarios relating to interoperability
---

# Component interoperability

PingOne Recognize currently consists of three main product components:

| Component                      | Facilitates user enrollment | Enables authentication |
| ------------------------------ | --------------------------- | ---------------------- |
| IDV Bridge (OnPremise or Saas) | [icon: check, set=fa]       | [icon: x, set=fa]      |
| Mobile SDK                     | [icon: check, set=fa]       | [icon: check, set=fa]  |
| Web SDK                        | [icon: check, set=fa]       | [icon: check, set=fa]  |

## Interoperability between PingOne Recognize components

All these components can now operate in an interconnected manner. A user can complete the enrollment process on any of these components and later authenticate on a different component without needing to re-enroll.

The technology enabling this seamless interoperability is called the **PingOne Recognize Client State**.

### How PingOne Recognize client state works

The PingOne Recognize client state can be generated by any of the components listed above.

* It can be consumed by either the Web SDK or Mobile SDK to enable cross-platform authentication. Client state is used to authenticate:

* **Mobile SDK**: a new client state is created on this device and for this specific UserID to allow for on-going authentication of that user from that device.

* **Web SDK**: a new client state is stored on the PingOne Recognize server for this specific UserID to allow for ongoing authentication from any browser where the customer chooses to initiate PingOne Recognize as a 2nd factor for authentication.

This interoperability opens up various use cases for PingOne Recognize authentication.

### Possible Scenarios relating to interoperability

1. **Live Enrollment → cross-platform authentication**

   Users enroll into PingOne Recognize by taking a selfie through a PingOne Recognize UI deployed by our customers into their own Mobile or Web apps using our SDKs.

   * [Enroll users through the Web SDK](#web-sdk/web-sdk-guide/enrollment) and then activate them in your Mobile app at a later stage to authenticate there without the need to re-enroll.

   * [Enroll users on the Mobile SDK](#consumer/mobile-sdk-guide/enrollment) and authenticate them in your web application (again without any re-enrollment).

2. **IDV Bridge → cross-platform authentication**

   Customers have captured a selfie, typically during KYC/Onboarding flows, and enroll this image into PingOne Recognize via:

   * **On-Premise** - enroll user selfies through the "PingOne Recognize Agent" component installed inside their own infrastructure, and subsequently allow them to authenticate using your web or mobile app at a later date with client state.

   * This option ensures that the selfies stay within your own infrastructure and therefore the entire process remains 100% privacy preserving.

   * **SaaS** - enroll user selfies through our [authentication service api](../idv-bridge/idv-bridge-saas.html), where the UserID is created instantly and client state can be stored to subsequently authenticate through your web or mobile app.

   * The selfie is sent to a secure enclave in PingOne Recognize and instantly transformed into a cryptographic key. No biometric data or PII is then stored.