Modern banking and digital financial ecosystems require more than basic user authentication. In large-scale environments such as mobile banking, internet banking, open banking, partner ecosystems, and high-risk digital service channels, identity alone is not sufficient. Financial institutions must be able to establish trust not only in the user, but also in the device, the session, the channel, the transaction context, and the surrounding risk signals. This is the foundation of a Digital Trust architecture and a practical Zero Trust operating model.
Within this model, a CIAM platform is no longer limited to login and token issuance. It becomes the central orchestration and policy layer that coordinates user authentication, device trust, contextual evaluation, approval journeys, and adaptive decisions across onboarding, login, step-up authentication, and transaction authorization. This aligns with the architecture described in the technical materials, where Curity acts as the orchestration and control layer, while specialized services such as OCR/eKYC, device intelligence, fraud engines, biometrics, and signing components can be integrated as external capabilities through APIs and extensibility mechanisms.
In this architecture, trust is established through multiple layers working together. User identity is verified through strong authentication methods. Devices are evaluated based on registration status, device binding, posture, and integrity. Sessions and requests are enriched with contextual signals such as IP address, location, operating system, browser, time, and behavioral anomalies. Transactions are assessed based on value, sensitivity, and channel. The solution then applies policy to determine whether to allow, challenge, step up, restrict, or deny the request. This approach reflects the contextual access and real-time decisioning model already described in the solution materials.
The following overview defines how Curity should be positioned within this model: as the identity and policy control plane for Digital Trust and Zero Trust access, designed to orchestrate trusted journeys across banking channels and integrate with external trust, risk, and verification services.
In a Digital Trust architecture, Curity should be positioned as the identity and policy control plane rather than as a monolithic platform expected to natively perform every specialized trust or fraud function. This distinction is important both technically and architecturally.
Curity’s primary role is to centralize and orchestrate authentication, authorization, session control, token issuance, account-related flows, and policy-driven decisions. It provides the core mechanisms required to enforce consistent identity and access rules across channels and systems. These include support for modern standards and protocols, API-driven authentication through HAAPI, strong extensibility through Authentication Actions and scripting, user and account management integration, CIBA-based decoupled authentication, and the ability to enrich flows with contextual and external data. This positioning is directly supported by the technical materials, which describe Curity as the orchestration layer for registration journeys, trusted-device authentication, contextual access, and external API-driven verification flows.
As the control plane, Curity performs several core functions.
First, it authenticates users through strong and flexible authentication patterns. These may include passwords, MFA, passkeys, WebAuthn, device-bound credentials, decoupled authentication, and cross-channel approval. Second, it issues tokens and sessions that represent not only user identity, but also achieved assurance level and, where designed, the relevant device or contextual state. Third, it orchestrates complex flows such as onboarding, QR login, push approval, CIBA-based backchannel approval, biometric authentication, and step-up challenges. Fourth, it evaluates or consumes policy inputs from internal logic and external systems in order to allow, deny, step up, or redirect the journey.
What Curity does not need to do natively is replace every surrounding specialist system. In a bank-grade architecture, device intelligence, fraud scoring, OCR/eKYC processing, liveness verification, transaction signing, app attestation, and other advanced trust services may be provided by external components. Curity integrates these capabilities into a unified identity and policy framework. This model allows financial institutions to preserve flexibility, avoid lock-in, and evolve individual trust services without rewriting the core CIAM layer.
This orchestration model is clearly reflected in the provided materials. For onboarding, Curity coordinates registration journeys while external OCR/eKYC and biometric engines perform extraction and verification. For trusted-device and push/QR login use cases, Curity orchestrates the authentication and approval journey while external device or mobile components provide trusted-device interaction and device trust signals. For contextual access, Curity consumes context and risk information and enforces adaptive policies.
This is why Curity should be described as the control plane for Zero Trust identity: it centralizes decision logic, orchestrates trust-aware journeys, and ensures policy consistency across distributed channels and external trust services.
Traditional identity systems focused mainly on proving who the user is. In modern banking, that is only one part of the trust decision. The institution must also determine whether the request is coming from a registered and trusted device, whether the device posture remains acceptable, whether the session context is normal, and whether the requested action fits the user’s expected profile and policy.
This creates a three-part trust model: trusted identity, trusted devices, and adaptive access.
Trusted identity means that the user has been authenticated with a level of assurance appropriate to the action being performed. This may include password-based login, MFA, local biometrics unlocking device-bound credentials, passkeys, WebAuthn, or step-up authentication. The materials already describe Curity’s support for passkeys, WebAuthn, biometrics-related orchestration, HAAPI-based mobile flows, and strong authentication patterns for banking.
Trusted devices means that the platform can associate a customer or account with one or more registered devices and evaluate whether a current request originates from a known and acceptable device. This is not limited to storing a device identifier. In the proposed solution, trusted devices include device binding, device lifecycle handling, device relationship models, first-device policy, replacement and re-binding logic, and device trust status. The solution materials explicitly describe account-to-device relationships, multiple devices per customer, trusted-device approval flows, and device-related management needs such as lost device, replace device, and add new device.
Adaptive access means that the platform does not make static, one-time trust decisions. Instead, access is evaluated dynamically based on context and risk. Signals such as IP address, location, operating system, browser, device status, time, geolocation anomalies, and other risk inputs can affect the result of an authentication or authorization decision. Based on this evaluation, the platform may allow the request, require step-up authentication, invoke additional checks, limit functionality, or deny access entirely. This model is consistent with the contextual access capability described in the technical materials, including Conditional Multi-Factor, geolocation actions, time-based deny logic, action and context attributes, and integration with external risk engines.
Together, these three elements create a stronger and more realistic trust model for digital banking. A valid user identity without a trusted device may not be sufficient. A trusted device without current contextual validation may not be sufficient. A low-risk login posture may not be sufficient for a high-risk transaction. By combining trusted identity, trusted device, and adaptive access, the bank can apply security proportionate to risk while maintaining a smoother customer experience for routine actions.
This model also supports a shift away from weak, standalone authentication factors toward higher-assurance journeys that combine device binding, local biometrics, passkeys, push approval, QR-based cross-channel confirmation, and context-aware step-up. In this sense, CIAM becomes the operational foundation for Digital Trust rather than merely an identity repository.
Zero Trust in banking should not be interpreted only as a network architecture principle. It must also be applied to customer identity journeys, digital channels, approval workflows, and transaction authorization decisions. Banking environments operate across multiple access channels, including mobile apps, web banking portals, kiosks, open banking APIs, partner channels, customer support-assisted flows, and internal operational systems. A customer may start a session on one channel and approve it on another. A transaction may originate from a web browser but require confirmation on a registered mobile device. A device that was trusted during onboarding may later show integrity issues or unfamiliar behavior. Under these conditions, trust cannot be granted permanently or globally. It must be established and re-established continuously.
A Zero Trust model for banking therefore requires the following principles. Every channel must be subject to the same identity and policy framework, even if the UX differs. Strong authentication and approval flows must be orchestrated consistently across mobile, web, and cross-channel journeys. Device trust must be continuously evaluated rather than assumed. Contextual and environmental signals must influence access decisions. Sensitive transactions must trigger stronger controls than routine actions. External trust services, such as risk engines, OCR/eKYC providers, biometric engines, and signing systems, must be integrated into a unified decision model rather than operating as disconnected tools.
The technical materials already describe this type of architecture. For onboarding, Curity orchestrates registration journeys and can integrate external OCR/eKYC and biometric verification services. For cross-channel authentication, it supports push approval, QR-based login, device-centric approval, and CIBA-style decoupled authentication. For contextual access, it supports continuous, risk-aware decisions based on live data and external inputs. For strong authentication, it supports passkeys, WebAuthn, biometrics-related orchestration, and device-related trust logic.
This makes Zero Trust highly relevant not only to user login, but also to transaction approval. A bank should be able to distinguish between a low-risk session refresh and a high-value funds transfer. It should be able to apply contextual rules such as requiring step-up authentication for new devices, suspicious geolocation changes, unusual operating system versions, high-risk transaction types, or elevated fraud signals. It should also be able to bind approval to a trusted device and, where necessary, integrate cryptographic confirmation or signing mechanisms to ensure that the approved transaction is the one the user actually intended to authorize.
From a product positioning perspective, Zero Trust for banking channels and transactions means that Curity should be described as the central policy and orchestration layer that ensures access decisions are consistent, adaptive, auditable, and based on open standards. It does not replace the need for specialist trust components, but it ensures they are coordinated into a unified identity and access decision framework. This is the key architectural value of Curity in a Digital Trust platform for large-scale banking environments.
The solution provides a unified QR Code Login capability for banking channels, enabling a customer to initiate login on a browser or other non-mobile channel and complete secure approval on a registered mobile device. This capability is built on Curity Device Flow as the standards-based authentication foundation and extended with the integrated OEM mobile SDK/mobile app to deliver trusted-device execution, QR scanning, local approval, and device-aware policy enforcement. Curity documents Device Flow as the OAuth 2.0 Device Authorization Grant and returns device_code, user_code, verification_uri, verification_uri_complete, and, when enabled, qr_code, where the QR code encodes the complete verification URI. Curity also documents that the initiating client polls the token endpoint with the device_code until the user has completed verification and granted access.
In the complete platform capability, QR Code Login is therefore not treated as a standalone QR convenience feature. It is a controlled cross-channel trusted-device authentication journey in which:
QR Code Login begins when the web channel or browser-side login flow requests a Device Flow transaction from Curity. Curity creates the transaction and returns the values required for the QR-assisted login path:
The solution can therefore support QR generation in two standard ways:
This means QR generation is grounded in Curity’s native Device Flow transaction model rather than relying on a proprietary QR login protocol. From a product perspective, this should be described as a standards-based QR login initiation capability built on Curity Device Flow.
After the QR code is scanned, the platform validates the QR transaction before allowing the mobile approval step to continue. This validation is not limited to checking whether the QR payload can be decoded. It includes checking whether the underlying Device Flow transaction is still valid and eligible for approval.
In the proposed solution, QR validation includes:
Device Flow transactions are time-bound, that the client must respect the returned polling interval, and that a redeemed device_code cannot be reused. Curity also notes that replay or reuse of an already redeemed device_code may lead to token revocation as a breach-protection measure.
From a product-guide perspective, QR validation should therefore be positioned as: a transaction-level security control that ensures the QR still maps to a valid, live, and not-yet-consumed Curity Device Flow authorization context before trusted-device approval is allowed.
The OAuth Device Flow standard does not define how a banking platform identifies a trusted device. To address this, the solution extends Curity’s Device Flow foundation with integrated trusted-device verification through the OEM mobile SDK/mobile app and the surrounding device trust services. This trusted-device verification layer is implemented by the integrated mobile/device-management components in the proposed solution and consumed by Curity as policy input. Once the QR transaction has been validated, the mobile side performs trusted-device verification before the approval step is allowed to continue. This trusted-device verification can include:
This is the key step that turns a standards-based QR-assisted authorization flow into a banking-grade QR trusted-device login capability. In product terms, this should be described as an integrated trusted-device control layer that extends Curity Device Flow with device recognition, device-state validation, and approval eligibility checks on the registered mobile device.
After trusted-device verification succeeds, the user completes local approval on the mobile device. This local approval may use:
At the Curity level, the verification continues through the Device Flow verification path. Curity documents that the user accesses the verification URI, the user_code is verified, the user is authenticated according to the configured authentication policy, and the user then explicitly grants access to the device client. Once this is complete, the initiating client can redeem the device_code at the token endpoint.
This allows the product to describe QR Code Login as a capability that combines:
While the user is completing approval on the mobile device, the browser-side client continues polling Curity’s token endpoint using the device_code and the returned interval. Once the user has successfully completed verification and granted access, Curity returns the token response and the login session on the browser is completed. This polling and token redemption behavior is part of Curity’s documented Device Flow model.
This means the full QR Code Login capability can be described as:
From a product capability perspective, the interaction model is as follows:
Web channel
OEM mobile SDK/mobile app
This is the clearest way to describe the feature as a single integrated product capability rather than as disconnected parts.
Step A – Resolve the QR transaction context
After scanning the QR code, the mobile app resolves the QR payload and opens the Curity Device Flow verification path using verification_uri_complete, or directs the user to the verification_uri where the user_code is entered or resolved automatically. In Curity Device Flow, the user must access the verification endpoint, verify the user_code, and then continue through the configured authentication and consent flow.
Step B – Identify the current device as a registered device In parallel with opening the Curity verification flow, the integrated mobile SDK/mobile app sends the current device context to the platform’s trusted-device service for lookup. This lookup may use a combination of:
Step C – Validate trusted-device state
The solution then verifies that:
Step D – Optional posture and integrity evaluation
If required by bank policy, the platform may also evaluate additional device trust signals, such as:
These checks belong to the integrated trusted-device capability of the platform and should not be presented as native Device Flow capabilities of Curity.
Step E – Local strong authentication on the mobile device Once trusted-device validation succeeds, the mobile app requires the user to complete local strong authentication on the registered device, for example by using:
Step F – Complete user verification and consent in Curity At the Curity verification endpoint, once the user_code has been accepted, the user is authenticated according to the configured authentication policy for the device client and must then explicitly allow access. This is a key standards-based part of Curity Device Flow: the device client can redeem the device_code only after user verification and consent have been completed.
Step G – Return the approval result and complete login After the user has successfully completed local approval on the trusted mobile device and the Curity verification flow is completed, the initiating client typically the browser-side client continues polling the Curity token endpoint using the device_code, following the returned interval, until Curity returns the token response or the transaction expires.
The solution provides a Push Notification Login capability for banking channels, enabling a user to initiate login on a web, mobile, or third-party channel and complete secure approval on a previously registered mobile device. The capability is implemented as a unified authentication pattern in which Curity governs the authentication transaction, journey state, and final token issuance, while the integrated OEM mobile app/SDK provides the trusted-device execution layer, including push-token registration, device recognition, local user verification, and approval submission.
Curity’s role in this model is to act as the identity and authentication orchestration platform. Curity provides the Authentication Service profile, HAAPI for API-driven authentication journeys, and support for standards-based decoupled and backchannel authentication patterns such as CIBA. Curity’s User Management model also supports accounts with associated resources such as devices, exposed through SCIM and GraphQL, which is the correct architectural basis for representing device-linked authentication journeys.
The integrated OEM mobile app/SDK extends this foundation into a practical bank-grade push authentication model. It registers the device for push delivery, maintains the device’s app-instance and trust context, receives the push message, opens the approval flow, performs local strong authentication such as biometric or PIN, and returns the result to the Curity-governed authentication transaction.
The originating channel sends the login request into the Curity-governed authentication flow. The solution determines that trusted-device approval is required. The trusted device is resolved from the customer-device relationship model. The solution evaluates any relevant risk signals, if enabled. A push challenge is created and routed to the registered mobile app instance through APNs or FCM. The user opens the push challenge in the mobile app. The OEM mobile app/SDK performs local strong authentication and, where applicable, device-bound proof such as passkey or device-key confirmation. The approval result is then returned into the Curity-controlled authentication journey, and Curity finalizes the login by issuing the session or tokens to the originating channel.
When the bank wants a more decoupled or standards-based model, the same capability can be expressed using CIBA-style backchannel authentication, where Curity manages the authentication transaction and the integrated push/mobile layer operationalizes the approval on the registered device.
For trusted-device push authentication to work, the Curity-governed journey must have access to a device record associated with the customer or account. In the integrated platform, this trusted-device record contains, or has access to, the following categories of information:
From a product perspective, this should be described as trusted-device information available to the Curity-controlled authentication journey. Depending on deployment design, these records may be managed through Curity’s device-associated user management model, or through an integrated device relationship store used by the same authentication architecture. Curity’s official documentation supports the concept of accounts with associated device resources through User Management GraphQL and the User Management profile.
The solution supports push delivery through the standard mobile push infrastructures:
This is the most appropriate deployment model for banks that want to use their own mobile banking app or mobile authenticator app, rather than a third-party MFA application.
In this model, the solution flow is as follows. A login is initiated on the browser or originating channel. Curity determines that trusted-device approval is required. The solution resolves the customer’s registered device, evaluates policy or risk if required, and creates a push challenge. The push service then sends a notification to the correct mobile app instance through APNs or FCM. The mobile app opens the challenge, performs local strong authentication, and returns the signed or approved result into the Curity-governed authentication flow. Curity then completes the login by issuing the session or tokens to the originating channel.
This is consistent with Curity’s documented role around HAAPI for API-driven authentication journeys and CIBA for decoupled or backchannel authentication patterns, while the push transport itself remains the responsibility of Apple and Google infrastructure rather than Curity itself.
To prove integration capability with APNs and FCM, the key point is that the solution must maintain the correct push routing identifiers for each registered device. APNs/FCM tokens are stored in the platform’s trusted-device/mobile backend domain and linked to the customer-device record, Curity orchestrates the authentication flow using that context. APNs and FCM use those tokens for delivery, but the authoritative customer-device association remains in the solution’s trusted-device domain governed by the Curity-based authentication solution.
On Apple platforms, the app registers with APNs and receives a device token. Apple documents that the app must forward this device token to the provider server, and that the provider must have this token in order to deliver remote notifications to the device.
On Android, the FCM SDK generates a registration token for the client app instance. Firebase recommends that the application server retrieve and store the latest registration token, because it may change over time. Firebase also documents that the registration token uniquely identifies the client app instance for message targeting.
Therefore, the integrated platform stores, for each trusted device, the push-routing information required to address that app instance, for example:
Curity provides the standards-based CIBA transaction, while device wake-up, trusted-device resolution, and device-side execution are handled by the integrated mobile trust layer in the proposed solution. This capability is built on Curity’s support for Client-Initiated Backchannel Authentication (CIBA) and extended with the integrated OEM mobile app/SDK to provide trusted-device resolution, device wake-up through APNs/FCM, local strong authentication on the registered device, and final approval submission into the Curity-controlled authentication transaction. CIBA as a decoupled OpenID Connect flow where authentication is initiated on a Consumption Device and completed on an Authentication Device, without browser redirects on the initiating client. The client initiates the flow through the Backchannel Authentication Endpoint, receives an auth_req_id, and later obtains the result through polling, ping, or push delivery modes.
In the complete platform capability, CIBA is therefore not treated as a standalone protocol feature. It is a unified cross-device trusted-device authentication model in which:
For a CIBA-based trusted-device flow to work, the solution must maintain a device record associated with the customer or account. In the integrated Curity-based architecture, this trusted-device record should contain, or be able to resolve, the following categories of information:
This device information is what allows the solution to determine which registered device should act as the Authentication Device in the CIBA model. Curity provides the standards-based authentication transaction and journey control, while the integrated mobile trust layer supplies the device-facing execution context. Curity’s HAAPI is also relevant here because it provides the API-driven interaction model required for mobile-native authentication experiences.
The CIBA flow begins when the initiating channel or client sends an authentication request directly to Curity’s Backchannel Authentication Endpoint. Curity documents that the client authenticates to the Authorization Server and includes a user-identifying hint so that the user to be authenticated can be resolved. Curity then immediately returns an Authentication Request Acknowledgment containing a unique auth_req_id, which becomes the correlation reference for the decoupled authentication transaction.
From a product capability perspective, Curity’s CIBA support provides the standardized transaction framework for:
After the CIBA transaction is created, the solution resolves which registered device should be used as the Authentication Device. This step is part of the integrated trusted-device capability of the solution and is where the CIBA flow becomes banking-grade.
The solution uses the user hint or customer context from the backchannel authentication request to:
Once the correct device is selected, the solution uses APNs or FCM to deliver a wake-up message or approval notification to the mobile application. In the CIBA flow, this push delivery is not the authentication transaction itself. Instead, it is the mechanism used to wake the Authentication Device so that the user can complete the Curity-governed approval flow. Curity explicitly states that it is up to the Authorization Server to select an appropriate channel for decoupled authentication on the authentication device.
To support this device wake-up model, the solution must integrate with:
Apple documents that an application registers with APNs and receives a globally unique device token, which the app must forward to its provider server so the provider can send notifications to that app instance.
Firebase documents that the FCM client application receives a registration token, and Firebase explicitly recommends that the application server retrieve and store the latest registration token on its server and keep it updated over time.
Therefore, in the integrated CIBA capability, the solution maintains the push-routing information required to wake the correct registered mobile app instance, including:
For APNs, the iOS app receives the APNs device token from Apple and forwards that token to the provider server. The authoritative customer-device relationship therefore remains in the bank’s platform or trusted-device domain, while APNs simply uses the token for delivery routing.
For FCM, the app instance receives an FCM registration token and the application server is expected to store and maintain that token. Firebase explicitly recommends keeping an updated list of active tokens on the server. Again, the authoritative trusted-device relationship remains in the solution, while FCM provides message routing based on the token.
Once the push or wake-up message reaches the mobile device, the OEM mobile app/SDK opens the authentication flow and performs trusted-device approval. This includes:
At the Curity level, this user interaction is part of the decoupled authentication transaction that Curity initiated through CIBA. Curity documents that authentication takes place on the Authentication Device, where the user enters credentials and grants consent, after which the result is returned through the selected token-delivery mechanism.
After the user completes local strong authentication and approves the request on the mobile device, the result is returned into the Curity-controlled CIBA transaction.
Curity supports three result-delivery modes for CIBA:
This means the integrated platform can support:
To implement the CIBA flow with trusted-device wake-up, the solution exchanges two broad categories of data.
The first category is device registration and routing data:
The second category is authentication transaction data:
As with the push-notification model, the recommended approach is to keep the raw push payload minimal and retrieve sensitive approval data only after the app opens a secure authenticated channel.
Although both flows may use APNs or FCM and both end with user approval on a registered mobile device, the two capabilities are not identical.
In the Push Notification Login model:
In the CIBA-based model:
A concise distinction is:
Curity’s learning materials also compare Device Flow and CIBA and emphasize that CIBA avoids QR or code-based user interaction on the initiating device by using a backchannel authentication request for a known user.
The proposed solution provides a unified Trusted Device Authentication capability for digital banking channels. In this capability, a device that has been enrolled, associated with a customer or account, and recognized by the platform as eligible for trusted use can participate in authentication and approval journeys as:
Within the proposed solution, Curity forms the core CIAM and authentication orchestration foundation, while the integrated device-trust capability extends that foundation into a practical banking-grade trusted-device model. Curity provides the official identity and journey framework through the Authentication Service profile, HAAPI, Signup Action, Authentication Actions, Scripting, JSON / REST Data Source, and device-capable User Management interfaces such as SCIM /Devices and GraphQL. These are the product-supported building blocks used by the solution to drive registration, login, approval, and account-device association flows.
Built on that foundation, the proposed solution extends trusted-device functionality to cover:
Accordingly, Trusted Device Authentication should be understood and presented as one integrated capability of the proposed solution, rather than as separate disconnected layers.
The Trusted-Device Authentication Model in the proposed solution is an authentication framework in which a previously enrolled device is treated as part of the overall trust decision for login and approval requests. The platform does not rely only on user identity. It also evaluates whether the authentication or approval is being performed from a device that is correctly associated with the customer, is in an eligible lifecycle state, and satisfies the configured trusted-device policy.
In this model, the proposed solution uses Curity’s official authentication and registration framework to orchestrate the journey and maintain transaction continuity. Curity officially provides:
This Curity foundation is then extended by the integrated trusted-device capability of the proposed solution to support:
As a result, the trusted-device model in the proposed solution is not limited to a single login method. It becomes a common security layer applied consistently across multiple authentication patterns.
The proposed solution uses an account-linked device model as the basis for trusted-device authentication. Curity’s official user-management model already supports devices associated with an account. Curity documents:
On top of this official Curity-supported model, the proposed solution enriches the device record so that the same trusted-device object can be used consistently across all authentication flows. In practical terms, the trusted-device record in the proposed solution includes or resolves:
This is important because trusted-device authentication in banking cannot rely only on a bare device ID. It requires a richer device relationship model that can answer:
Therefore, the proposed solution should describe its device model as a unified account-device trust model built on Curity’s device-capable user management foundation and extended by the integrated trusted-device service of the platform.
The proposed solution supports device binding between a customer/account and a device as a first-class trusted-device function.
Curity provides the official product basis for device binding through:
Within the proposed solution, device binding is performed as part of an orchestrated identity journey. This means:
This allows the platform to support:
For product-description purposes, device binding should therefore be presented as:
The proposed solution supports a first-device policy, meaning it can determine how the first trusted device is established for a customer or account. Curity does not expose a single standalone product switch called “first trusted device policy.” However, Curity provides all of the official building blocks needed to implement it:
In the proposed solution, first-device policy works as a governed platform rule:
This means the first-device policy is not a disconnected OEM-only rule. It is part of the Curity-governed journey of the proposed solution, with the trusted-device policy logic applied inside the same integrated architecture.
A banking-grade trusted-device model requires explicit device trust status rather than a simple known/unknown flag. The proposed solution therefore maintains a trust-state model for devices, typically including states such as:
Curity provides the official journey-control and device-record framework needed to read, update, or branch on device-related information, while the integrated trusted-device capability of the proposed solution gives business meaning to the trust state and applies it consistently across flows. Curity’s Authentication Actions and Scripting are especially relevant here because they allow the platform to branch the journey depending on the trusted-device outcome or to enrich the flow with device-related context. As a result, device trust status is treated as part of the platform’s overall authentication policy, not merely as metadata stored for reporting.
The proposed solution includes full device lifecycle handling as part of the trusted-device capability. This means the platform can manage the transition of a device through its entire usable lifecycle, including:
Curity provides the official orchestration framework for lifecycle-aware journeys through:
The integrated trusted-device capability of the proposed solution then applies lifecycle rules to determine:
This lifecycle handling is what allows the same trusted-device model to support operational scenarios such as lost device, replace device, and add new device in a controlled and auditable way.
The proposed solution supports a configurable policy for how many trusted devices a customer or account may have. Curity and OEM layer provides the required official mechanisms to implement this as part of the integrated solution:
Within the proposed solution:
This enables policies such as:
In practice, this means the number-of-devices policy is presented as a configurable trusted-device control of the proposed solution, implemented through Curity-governed flow control and integrated trusted-device policy evaluation.
The proposed solution explicitly supports lost device, replace device, and add new device scenarios as part of the trusted-device feature set.
Lost device
When a device is reported lost:
Replace device
When the customer replaces a device:
Add new device When the customer adds an additional device:
Curity’s role in these flows is to provide the official journey entry points and flow-control framework, while the integrated trusted-device capability of the proposed solution applies the lifecycle decision rules and trusted-device state transitions. This makes lost / replace / add-device handling an integral part of the trusted-device authentication feature rather than a separate administrative module.
The trusted-device capability of the proposed solution is designed to support all major authentication models that require device-aware trust decisions.
Push approval The platform supports push approval by using Curity as the core authentication orchestrator and the integrated mobile/device execution layer to route approval to the correct registered device, perform local strong authentication, and return the approval result. HAAPI and decoupled patterns are relevant here for secure mobile/API-driven interaction.
QR login The platform supports QR-assisted login using Curity’s Device Flow as the standards-based transaction foundation. Curity supports device_code, user_code, verification_uri, verification_uri_complete, and optional qr_code, while the integrated trusted-device layer verifies that the scanning mobile device is eligible to approve the session.
App-to-app authentication The platform supports app-to-app patterns using Curity’s API-driven journey model through HAAPI and the integrated device/mobile layer for deep-link or app-context execution, local approval, and result return.
Cross-channel approval The platform supports cross-channel approval by correlating an initiating channel with a trusted approval device under one Curity-governed authentication transaction, with the integrated trusted-device layer selecting and executing approval on the correct mobile device.
Decoupled authentication The platform supports decoupled authentication through Curity’s standards-based and API-driven orchestration, while the trusted-device layer operationalizes the approval on a separate registered device.
CIBA-based authentication The platform supports CIBA using Curity’s Backchannel Authentication Endpoint, auth_req_id, and result delivery modes. The integrated trusted-device capability resolves the correct Authentication Device and performs the mobile-side approval.
Device Identity and Relationship Management in the proposed solution is a unified capability built on Curity’s official identity, journey, and user-management foundations and extended by the integrated trusted-device services of the solution. Curity provides the Authentication Service profile, HAAPI-driven orchestration, Signup Action, Authentication Actions, scripting, JSON / REST integration, SCIM /Devices, and GraphQL account-device structures. On top of this foundation, the proposed solution provides a complete device identity and relationship model covering customer ↔ account ↔ device ↔ credential association, first trusted-device policy, multiple devices per customer, device binding and re-binding, device lifecycle states, lost / replace / add-device workflows, and a centralized trusted-device registry and relationship store.
The proposed solution models a hierarchical relationship that reflects real-world banking entities and extends beyond a simple user-to-device mapping. At the center of this model, Curity provides the identity and account foundation through its User Management capability, including SCIM /Devices and GraphQL support for devices linked to accounts. Curity’s GraphQL documentation explicitly states that the user-management graph is based on the account, with sub-elements such as linked accounts and devices that belong to that particular account, and it documents device-related mutations such as addDeviceToAccountByAccountId and updateDeviceFromAccountByAccountId.
Within the proposed solution, the relationship model is described as follows:
Customer (Legal Entity) Represented by the bank’s master customer identifier, such as CIF or another customer reference. The customer is the top-level business entity and the logical owner of all related accounts, devices, and credentials.
User Account (Digital Identity) Represented by an account within the identity platform. In most deployments, a customer maps to a primary digital identity used for authentication. Where needed, the proposed solution can support linked-account scenarios, for example where one customer uses multiple digital identities for separate banking contexts, while still maintaining a coherent trusted-device model.
Represented by a record in the USER table. In most deployments, there is a one-to-one (1:1) mapping between a Customer and a User Account.
Represented by a record in the DEVICES table. A single User Account can be associated with multiple Devices (1:N relationship). The USER_ID foreign key establishes this ownership.
Represented by records in the FIDO_IDENTITY and KEY_DATA tables. A single Device can generate and manage multiple cryptographic Credentials (e.g., Passkeys, Device Signing Keys). These credentials are cryptographically bound to the device's hardware (via Secure Enclave, TPM, or Keystore) and cannot be exported or used from another device.
This means the proposed solution supports a unified Customer ↔ Account ↔ Device ↔ Credential model rather than isolated records, allowing trusted-device decisions to be reused consistently across registration, login, step-up, push, QR, app-to-app, and decoupled authentication flows.
The establishment of the first trusted device is a critical moment in the customer’s digital journey. The proposed solution supports a first trusted device policy, implemented as part of a Curity-governed registration or authentication journey and extended by the integrated trusted-device policy logic of the solution. Curity does not document a single built-in toggle called “first trusted device policy.” Instead, the proposed solution uses Curity’s official building blocks to implement this capability:
Within the proposed solution, the first-device policy can operate in one of the following modes:
Automatic Trust Establishment: Upon the first successful high-assurance enrollment or authentication from a new device, the platform creates the initial device record for the account and assigns the device an eligible trusted-device status. This device becomes the first anchor of trust for later device-led authentication and approval journeys. Upon the very first successful authentication from a new device, the system automatically creates a record in the DEVICES table and assigns it a STATUS = ACTIVE.
Elevated Assurance Establishment: For deployments with stronger onboarding requirements, the first device may initially be created in a pending or candidate state (STATUS = PENDING). Activation then requires an additional step, such as:
Primary Device Designation: The first trusted active device may also be logically designated as the “primary device”, allowing policy rules to require that device for high-risk approvals or as the initial approval path for future device management actions.
The solution natively supports a one-to-many relationship between a User Account and Devices, allowing customers to securely access services from several personal devices.
Device binding is the process of creating a strong, verifiable association between a physical device and a user account. The solution provides multiple layers of binding to prevent spoofing and account takeover.
• Layer 1: Logical Binding (DEVICE_ID): A persistent, unique identifier generated by the mobile app and stored securely. This is the primary key for the device record. • Layer 2: Fingerprint Binding (COMPOSITE_HASH): A cryptographic hash of the device's hardware and software characteristics. The system compares the presented hash with the stored value. A mismatch indicates a significant change in the device environment, which may be a sign of tampering, OS upgrade, or app re-installation. • Layer 3: Cryptographic Binding (Passkey / Device Key): The strongest form of binding. A public/private key pair is generated on the device. The private key is securely stored in hardware (e.g., Secure Enclave, Keystore) and never leaves the device. The public key is registered with the user's account in the backend (FIDO_IDENTITY or KEY_DATA). Subsequent authentication requests must be signed by the private key, providing irrefutable cryptographic proof of the device's presence.
Re-binding Scenarios:
Re-binding is the process of managing the device identity when the software environment changes but the physical hardware remains the same.
| Status | Description | Sub-field | Sub-field Value | Notes |
|---|---|---|---|---|
| UNREGISTERED | The user has no registered authentication device. | None | N/A | Default state when the user has not enrolled any authentication method or device. |
| PENDING | The device is partially registered and pending completion of identity verification or enrollment. | enrollment_status | pending_identity_verification: Identity verification not completed (eKYC / identity proofing). | The device cannot be used for authentication until enrollment is completed. |
pending_device_binding: Device binding not completed. | ||||
pending_user_confirmation: Awaiting user confirmation (e.g., email/SMS approval). | ||||
pending_manual_review: Requires manual review due to inconsistent or unclear data. | ||||
pending_compliance_check: Awaiting compliance checks (e.g., AML / policy validation). | ||||
pending_risk_assessment: Awaiting risk evaluation (e.g., high-risk user/device). | ||||
| ACTIVE | The device is fully registered, trusted, and can be used for authentication. | None | N/A | One or more devices can be ACTIVE depending on policy (single-device or multi-device model). |
| INACTIVE | The device is registered but currently not allowed to authenticate. | reason | another_device_preferred: Another device is prioritized for authentication. | Used to control device eligibility without removing it. |
user_disabled: User manually disabled the device. | ||||
session_expired: Device session expired due to inactivity. | ||||
policy_restriction: Restricted due to policy (e.g., outdated device posture). | ||||
device_unverified: Device requires re-verification after major change (e.g., OS update, app reinstall). | ||||
temporary_suspension: Temporarily disabled by system or bank. | ||||
| LOCKED | The device is locked due to security concerns or user action. | lock_reason | user_request: User requested lock (lost device, device replacement). | The device cannot be used for authentication until unlocked. |
failed_attempts: Multiple failed authentication attempts (e.g., PIN/biometric failures). | ||||
suspicious_activity: Suspicious login behavior detected (e.g., unusual location, device mismatch). | ||||
device_compromised: Device is rooted/jailbroken or shows signs of compromise. | ||||
security_violation: Security policy violation detected. | ||||
fraud_suspected: Potential fraud associated with the device. | ||||
compliance_violation: Regulatory or compliance violation. | ||||
| lock_duration | null — permanent lock. | |||
| Timestamp value — temporary lock (e.g., 24h / 7d / 30d). | ||||
| DEREGISTERED | The device has been removed from the list of registered authentication devices. | deregister_reason | user_removed: User removed the device. | The device is no longer associated with the user account. |
system_removed: System removed due to policy or risk. | ||||
device_obsolete: Device no longer supported (e.g., outdated OS). | ||||
account_suspended: User account suspended. | ||||
risk_violation: Removed due to high-risk classification. | ||||
compliance_requirement: Removal required for regulatory compliance. | ||||
expired_registration: Registration expired due to inactivity. | ||||
security_policy_update: Removed due to updated security policy. |
The solution provides clear, secure workflows for common end-user device management scenarios.
A. Add New Device (Device Enrollment & Binding)
Trigger
B. Lost Device (Device Deregistration / Risk Mitigation)
Trigger
Workflow (Self-Service)
Workflow (Assisted Service)
C. Replace Device (Device Migration Scenario)
Description
Workflow
All device identity and relationship data is centrally managed within a dedicated, secure data store.
Device Intelligence and Device Risk Evaluation in the proposed solution is a unified capability built on Curity’s official identity and authentication orchestration foundation and extended by the integrated device-trust services of the solution. Curity provides the authentication journey control, API-driven mobile interaction model, policy branching, and REST integration mechanisms needed to incorporate device-aware decisions into registration, login, and approval flows. On top of this foundation, the proposed solution provides device fingerprinting, app instance identity, device-bound cryptographic trust, basic posture and trust signals, telemetry correlation, and optional attestation integration to strengthen device binding, trusted-device continuity, and adaptive authentication decisions. The capability is positioned as part of the proposed solution’s trusted-device and device intelligence model.
Device fingerprinting in the proposed solution is the process of deriving a stable or semi-stable device profile from a combination of hardware, software, and application context so that the platform can recognize returning devices, detect meaningful environment changes, and support re-binding or risk-based decisions.
The proposed solution can maintain a composite device fingerprint derived from configurable device attributes collected by the mobile app / SDK and associated with the device relationship model. The purpose of this fingerprint is not to guarantee absolute uniqueness, but to provide a strong device-recognition signal that helps distinguish:
Typical fingerprint inputs may include:
Device fingerprinting is the process of generating a unique or semi-unique identifier for a device based on a combination of its inherent hardware and software characteristics. This identifier is used to recognize returning devices, detect anomalies, and identify potential spoofing attempts even when traditional identifiers like DEVICE_ID are reset.
Composite Fingerprint (COMPOSITE_HASH): The solution calculates a strong cryptographic hash (e.g., SHA-256) derived from a wide array of attributes collected from the device. This hash is stored in the DEVICES table and presented during each authentication request.
Granular Hashes (HW_HASH, SW_HASH): In addition to the composite hash, the solution can generate separate hashes for the hardware profile and the software profile. This provides more granular insight during risk evaluation. For example, a change in SW_HASH with a stable HW_HASH strongly suggests an OS update or app reinstallation, which carries a different risk profile than a complete device change.
Fingerprint Algorithm and Version (FP_ALGORITHM, FP_VERSION): The system records the specific algorithm and version used to compute the fingerprint. This ensures backward compatibility and allows for the phased rollout of improved fingerprinting logic.
1. Device Fingerprint
** 3. Hardware Information **
** 4. Software Information **
** 5. Device Details and Localization **
The proposed solution uses a multi-layer identity model that distinguishes between:
At the application layer, the mobile app / SDK can generate and maintain a logical device identifier or app instance identifier that represents the current installation context. This identifier is used as part of the overall device-binding and trusted-device model of the proposed solution. This is important because:
The proposed solution therefore does not rely on a single raw identifier alone. Instead, it uses:
Where privacy-sensitive or pre-login contexts require it, the proposed solution can also use anonymous or session-scoped device references so that device-aware policies can be applied before the user is fully identified.
The solution utilizes a multi-layered approach to identity, distinguishing between the physical device, the operating system instance, and the specific application installation.
This should be presented as a layered device identity model within the proposed solution, used to support device continuity, trusted-device recognition, and re-binding decisions.
The proposed solution supports basic device posture and trust signals that can be collected through standard mobile application capabilities and operating-system APIs, without positioning the solution as a deep app-protection or RASP product.
These signals can include:
Where the mobile platform allows, the proposed solution can also collect basic risk-relevant signals such as:
These signals are used as trust inputs into the authentication journey. They are not marketed as proof of advanced attack prevention, nor are they positioned as a replacement for a full mobile application protection product.
Accordingly, this section should be described as a set of lightweight and practical device trust signals that the proposed solution can use to support trusted-device evaluation and adaptive authentication decisions.
Rooting (Android) and Jailbreaking (iOS) are processes that grant users privileged control over the operating system, circumventing the vendor's security restrictions. The solution's integrated SDK performs deep checks to detect such compromised states.
Attackers frequently use emulators (software that mimics a real device) or simulators to automate fraud, create fake accounts, or test stolen credentials at scale. The solution includes robust detection for these virtualized environments.
A key part of the proposed solution’s device intelligence capability is device cryptography. This is what allows the solution to move beyond simple device recognition and into stronger proof of device possession. In the proposed solution, device cryptography can be used in several ways:
This is an important distinction: the proposed solution is not merely identifying a device by metadata. It can also combine that with cryptographic proof tied to the device context, which substantially strengthens device binding and non-repudiation for approval scenarios.
From a feature perspective, this should be described as device-bound cryptographic capability used by the proposed solution to strengthen device binding, trusted-device approval, and proof of device possession.
The proposed solution continuously evaluates device-aware and context-aware signals as part of authentication and approval decisions. In this model, device context is not treated as a standalone security product domain, but as an integrated input into the broader identity, trusted-device, and adaptive-access decision framework of the platform. This means the proposed solution does not need to behave like a full anti-malware, app shielding, or dedicated mobile protection product. Instead, it uses device and contextual intelligence as one of the core factors in determining whether a request should be allowed, stepped up, routed to trusted-device approval, re-bound, restricted, or denied.
Within the proposed solution, this capability is implemented through the combination of:
In practical terms, the proposed solution uses device-aware risk evaluation to support decisions such as:
Accordingly, device intelligence in the proposed solution should be understood as a device-aware and context-aware risk input into the Curity-governed authentication journey, rather than as a standalone mobile security product.
To address the bank’s request regarding rule-based risk evaluation, the proposed solution supports a deterministic risk model in which collected contextual and device signals are evaluated through configurable policy logic. In this model, Curity acts as the policy and orchestration control plane, while the broader proposed solution provides the collection, normalization, storage, and enrichment of the device and contextual attributes used by those rules.
Curity provides the official vendor-supported building blocks needed to implement such rule-based logic:
This means the proposed solution can legitimately position rule-based risk evaluation as a Curity-governed policy capability that evaluates contextual and device attributes collected and maintained by the proposed solution, using Authentication Actions, Switch logic, Conditional MFA, Time-based Deny, geolocation-related actions, scripting, and REST-based policy enrichment.
To keep the rule-based model aligned with the storage model referenced by the bank, the proposed solution uses data previously collected and retained in the broader device and context architecture, including:
These attributes are collected by the relevant web/mobile/backend components of the proposed solution and then exposed into the Curity-controlled journey as:
This is important because Curity is not being positioned as the raw collection engine for all browser, OS, or device telemetry. Instead, Curity is the orchestration and policy layer that consumes these attributes and applies rule-based decisions consistently inside the authentication journey.
The following examples show how the proposed solution can implement the deterministic risk criteria requested by the bank.
1. Login outside allowed hours The proposed solution can evaluate whether the current login time falls outside the allowed access window for the user, customer segment, application, or banking service.
Possible action:
Curity relevance:
Possible action:
3. Unusual or unsupported OS version The proposed solution can evaluate the operating system family and version received from the current channel or device context and compare it with:
Possible action:
Curity relevance:
4. Unregistered device The proposed solution can determine whether the device participating in the request is already associated with the customer/account and whether it is in a valid lifecycle and trust state.
Possible action:
Curity relevance:
5. Sudden change from desktop to mobile browser The proposed solution can correlate the current request context with recent session history and detect a sudden or suspicious change in the interaction model, such as:
Possible action:
Curity relevance:
6. Trusted device but app integrity issue The proposed solution can support the case where a device is already registered as trusted, but the current app instance presents a problematic trust signal, such as:
Possible action:
Important positioning note:
7. Financial transaction from an unusual environment The proposed solution can combine transaction context with environmental context such as:
Possible action:
Curity relevance:
Below are examples of how the proposed solution can express deterministic policies using the collected context.
Example A — Operating system rule
Condition OS family = Android AND OS major version < supported baseline
Result • deny login for high-risk services, or • allow login but force step-up authentication
Curity implementation path • OS attributes passed into the journey as context attributes • evaluated through Switch Action or Conditional Multi-Factor • HAAPI used to present the correct next step to the mobile app if challenge is required.
Example B — Browser rule
Condition Browser fingerprint / browser family not previously seen for this account
Result • require trusted-device approval, • or step-up before access to sensitive functions
Curity implementation path • browser context obtained from channel / backend • exposed into authentication flow as attributes • decision enforced through Authentication Actions, Switch Action, and optionally JSON / REST lookup to compare against stored browser history.
Example C — Device rule
Condition Device not currently registered or not in an allowed trust state
Result • trigger add-device or re-binding journey, • or deny direct access until alternative proof is completed
Curity implementation path • device state resolved through trusted-device services of the proposed solution • result passed to Curity as a policy input • journey continues through HAAPI, Authentication Actions, and registration or enrollment steps if needed.
To answer the bank’s request for vendor evidence that the platform supports rule-based evaluation, the relevant Curity-supported references in the proposed solution are:
These references are sufficient to support the statement that Curity provides the official policy-orchestration and rule-enforcement framework used by the proposed solution, while the broader proposed solution supplies and stores the necessary OS / browser / device / time / trusted-device context used by those rules.
Detailed API reference for device lifecycle, device binding, authentication, CIBA, Device Flow, risk evaluation, and transaction authorization patterns.
Technical reference for HAAPI, mobile SDK capabilities, device intelligence collection, supported platforms, integration patterns, and security considerations.
Reference material for device data models, context and risk attributes, configuration rule concepts, identity-device-credential relationships, audit logging, event streaming, and data protection at rest.
If you are designing a digital trust and Zero Trust device security architecture for a regulated banking environment, Curity can provide the identity and policy control plane for decoupled authentication, device lifecycle, device-bound credentials, and risk-aware access — integrated with specialized device intelligence, signing, and fraud capabilities.