Skip to main content
    Back to All Solutions

    iShield Solutions Series, Security, Risk & Compliance · Identity

    Customer Identity & Access (CIAM)

    Passwordless, MFA, consent and progressive profiling for B2C and B2B2C journeys.

    Talk to Sales
    Overview

    What this solution does

    Customer sign-in and sign-up journeys — passwordless, social, multi-factor and step-up — run on Link's journey runtime, with consent applied as data moves. The customer record stays in iShield Connect and consent evidence can be kept in iShieldGRC, depending on how the platforms are implemented and configured.

    Why this composition: CIAM is a different buyer (CDO/CMO/CRO) and a different risk surface than workforce IGA — consent, fraud and conversion rate dominate. Connect owns the customer record, Link runs the journey runtime and policy plane, GRC carries the PDPL/GDPR evidence trail.

    • Enterprise challenge

      Security versus conversion

      Every extra sign-in step protects the account and loses some customers.

    • Enterprise challenge

      Consent captured but not applied

      Customers choose their preferences, but downstream systems and AI services do not see them.

    • Enterprise challenge

      Fraud signals in separate tools

      Risk signals are not connected to the moment of sign-in.

    How it works

    The customer sign-in journey

    Follow one customer from sign-in to an active session: authentication, a risk decision, identity verification when needed and consent — before the application, the customer record and the evidence trail are updated.

    • System
    • Integration service
    • Policy check
    • Failure path
    • Interface
    • iShield platform

    1. 01 SystemCustomer

      Customer starts sign-in

      A customer signs up or signs in on a web or mobile channel.

      Who acts, controls and evidence
      Who acts
      The customer

    2. 02 Integration serviceJourney runtime

      Authenticate

      The configured method runs — for example a passkey, magic link, social sign-in or a one-time code.

      Who acts, controls and evidence
      Who acts
      Identity team configures the journey
      Control
      Allowed methods per journey
      Evidence
      Sign-in event
      Module: CIAM Journey Runtime (Passwordless, Social, MFA)

    3. 03 Policy checkControls

      Risk signals

      Device, location, velocity and behaviour signals decide whether more proof is needed.

      Who acts, controls and evidence
      Decided by
      Rules set by the fraud and identity teams
      Control
      Risk rules and thresholds
      Evidence
      Risk decision
      Module: Step-up & Fraud Signals

      04 Failure path

      Step-up or refusal

      A risky attempt is asked for step-up authentication or refused, and the outcome is recorded.

      Who acts: Fraud team reviews refusals

    4. 05 Integration serviceJourney runtime

      Verify identity when required

      Where the journey requires it, identity is verified through a connected verification provider.

      Who acts, controls and evidence
      Who acts
      Identity team
      Control
      Verification required per journey
      Evidence
      Verification result
      Module: Identity Verification Broker

    5. 06 Policy checkControls

      Consent applied

      The customer's consent choices decide which data can flow to applications, analytics and AI services.

      Who acts, controls and evidence
      Decided by
      Data protection officer sets the rules
      Control
      Consent state per purpose
      Evidence
      Consent decision
      Module: Consent Enforcer

    6. 07 InterfaceCustomer

      Session to the application

      The application receives a session with only the claims the customer has consented to share.

      Who acts, controls and evidence
      Who acts
      Application team

    7. 08 iShield platformPlatforms

      Customer profile

      iShield Connect

      The customer profile and preferences are kept in iShield Connect, depending on how the platforms are implemented and configured.

      Who acts, controls and evidence
      Who acts
      CRM team

    8. 09 iShield platformPlatforms

      Consent and audit evidence

      iShieldGRC

      Consent and audit evidence can be kept in iShieldGRC for privacy and audit work, depending on how the platforms are implemented and configured.

      Who acts, controls and evidence
      Who acts
      Privacy and audit teams
    Illustration of a customer identity journey — not a product screen. Methods, signals and providers depend on implementation and configuration.
    What it does

    Core capabilities

    Passwordless & MFA

    Passkeys, magic links, one-time codes, push and SMS fallback, as configured per journey.

    Risk-based step-up

    Device, location, velocity and behaviour signals can trigger step-up authentication.

    Consent at the edge

    Consent choices applied at API, agent and analytics boundaries where configured.

    Progressive profiling

    Profile details collected over time, tied to the customer's consent state.

    Roles

    • Chief Digital Officer

      Owns the customer sign-in experience

    • Identity team

      Configures journeys, methods and verification

    • Fraud team

      Sets risk rules and reviews refusals

    • Data protection officer

      Sets consent rules and answers privacy requests

    What it composes

    Modules included across iShield

    This solution composes capabilities from the platforms below. Each module links to its place in the platform's module index.

    Governance & recovery

    Controls, failures and recovery

    Governance and security

    • Consent decides which data each application, analytics tool or AI service receives
    • Risk rules and journeys are versioned and released under control
    • Sign-in, risk and consent decisions are recorded

    Failures and recovery

    • A sign-in looks risky: The customer is asked for step-up authentication or refused, and the decision is recorded.
    • A verification provider is unavailable: The journey follows its configured fallback instead of letting the customer through unchecked.

    Reference frameworks

    Context only — no certification or conformity statement.

    OAuth 2.0 and OpenID Connect
    Customer sign-in and delegated access patterns.
    ISO/IEC 27701
    Privacy-management guidance for customer personal data.
    Applicable data-protection requirements
    Consent and privacy rules that apply to customer data, such as GDPR or national data-protection laws.
    Cross-platform boundaries

    Who owns what

    • Link runs the journey and applies consent; it is not the customer record.
    • The customer record stays in iShield Connect; privacy and audit evidence can be kept in iShieldGRC.
    • Exchanges between these platforms depend on how they are implemented and configured.
    Business outcomes

    What changes

    • Stronger protection where risk is higher, fewer steps where it is not
    • Consent applied wherever customer data flows
    • A recorded decision for every sign-in

    Bring Customer Identity & Access (CIAM) to your enterprise

    Discuss how this solution fits your integration estate, and the phased delivery and deployment options for your environment.

    Your privacy choices

    We use strictly necessary storage to run this website. With your permission we also use first-party analytics to understand which pages are useful. Analytics stays off unless you choose "Accept all" or turn it on in "Manage". You can change your choice at any time from "Cookie settings" in the footer. See our Privacy Policy.