Table of Contents
Most organizations will eventually assemble a stack of identity tools that gather useful information and more than a couple that let them act on it. But because they’re often assembled ad hoc and as needs arise, none of them really talk to each other by default. Thus, when it comes to making consistent, connected decisions across the user journey, results are often mixed.
Risk signals from these tools are assessed at isolated points along the user journey rather than being evaluated as a continuous stream. The resulting policy architecture is a blunt instrument: one threshold applied unilaterally, regardless of who the user is or what they’re actually doing.
High-risk sessions don’t get enough scrutiny in this system, while low-risk sessions absorb friction they didn’t warrant. Neither outcome is acceptable at scale, and the gap between what these tools can collectively perceive and what the system can actually act on is where account takeovers (ATOs) and fraud tend to live.
Journey-time orchestration (JTO) addresses this gap directly by integrating tools that generate risk and trust signals with underlying access management and analytics systems.
What is journey-time orchestration?
JTO connects the systems that detect risk and determine trust with downstream analysis tools, allowing them to facilitate various actions in response: step-up authentication, adaptive MFA, identity verification (IDV) challenges, and even account lockouts. The orchestration layer happens at “journey-time,” or in real time as a user moves through onboarding, login, account recovery, or a high-risk action.
It’s important to recognize the distinction between aggregating signals and orchestrating across them. Fusing together outputs from multiple risk tools into a single score is signal consolidation, not orchestration. Managing the native capabilities of a single-vendor platform through a workflow engine is also not orchestration, at least in any meaningful sense. What JTO introduces is cross-vendor coordination happening dynamically, in-session, with event-level policy logic determining what the journey does next. This is much more than simply deciding whether a user passes through a security gate, but which gate, when, and why.
Core capabilities of journey-time orchestration
A complete JTO implementation is described by Gartner®¹ as covering six capability areas:
User journey mapping
This establishes the “terrain” of the identity environment: every key event in the user journey is modeled explicitly, typically through a visual flow designer. Login, account opening, password reset, high-value transaction: each of these events is a node where signals can be evaluated and actions can be triggered based on their level of risk.
User journey control
The runtime layer, which is where the branching logic lives. This is what makes risk-appropriate UX decisions (i.e., adaptive MFA) possible. As a user moves through their journey, the orchestration layer ingests responses from triggered tools and determines the next step: proceed, challenge, step up, or route to an alternative path.
Event-level policy definition
This component sets policies for specific events that specify which internal or external signals should be ingested, establishes risk thresholds, and determines what action to take when a threshold is crossed.
Vendor integration management
The orchestration layer handles the work of building and maintaining connections to the IAM and ATO prevention tools in your stack. This is typically arranged through an ecosystem of prebuilt connectors provided by the JTO solution rather than each vendor integration requiring its own creation and upkeep.
Data mapping and normalization
While vendor integration management takes care of integration into your stack, data mapping and normalization mediates vendor translation across your stack. When two providers in the same capability category return results in different formats, for example, the JTO solution maps those responses to a normalized set of internal attributes.
No/low-code flexibility
In a complete JTO implementation, all of the components above are flexible and adjustable enough to be modified in a drag-and-drop or low-code interface without developer cycles spent. This is what keeps JTO useful from a practical perspective; an orchestration layer that requires an engineering team to dial in a risk threshold isn’t delivering on its core value proposition.
Journey-time orchestration vs. identity orchestration
Once JTO’s parameters are clear, it’s worth distinguishing from the broader concept of identity orchestration. While the terms may sometimes be used interchangeably, identity orchestration is a higher-level discipline.
| Identity Orchestration | Journey-Time Orchestration |
|---|---|---|
Scope | Complete user journey architecture: flows, provisioning, federation, user management | Real-time risk decisions within an active session |
Inputs | Auth methods, identity providers, user data, and user-facing logic | Risk and trust signals from identity tools in the stack |
Outputs | A structured, connected, and executable user journey | A branching decision tree: proceed, step up, reroute, etc. |
Vendor relationships | Connects identity providers, CRMs, data stores | Connects risk signal tools, IDV vendors, ATO prevention providers |
Primary stakeholders | Developers and IAM teams | Security and product teams |
Main difference | Operates during flow execution | Operates at “journey time,” as the user interacts |
Identity orchestration involves designing and managing the full structure of user journeys, including authentication flows, provisioning, CRM and data syncs, federation logic, and the operational relationships between identity systems. It’s a big concept that’s chief concern is what a journey looks like and how its components are connected.
Journey-time orchestration is narrower and more runtime-specific. It governs the real-time decisions that happen inside an active session based on risk signals from across your vendor stack. The journey structure may well be defined through identity orchestration capabilities, but JTO is what executes the branching logic when users (and risk signals) arrive.
A platform handling both identity orchestration and JTO is managing both architecture and real-time risk response simultaneously. But rather than being a “jack of all trades, master of none,” this is often where the most competent and comprehensive solutions live. However, keeping these concepts distinct helps clarify what each layer is responsible for, and what customers of identity orchestration and/or JTO providers can expect.
Best practices in journey-time orchestration
While JTO can be described as a set of six components living under the same roof, the current running through them all is the same: connect the disconnected. What follows are the best practices for getting the most out of a JTO implementation, and how to ensure your risk signals actually contribute to a more secure environment:
Connect your analytics and UI layers
The orchestration layer acts as the connective tissue between the analytics layer (where risk is assessed) and the UI layer (where the user experience is delivered. Gartner® recommends that organizations “connect the analytics and UI layers to broker calls between systems along the user journey.” Platforms that also own UI components close the loop more tightly than those that do not. When working in this scenario, changes at the orchestration level can render instantly without a separate front-end deployment.
Also Read: Choosing the Right Descope UI Integration Option
Define policies at the event level, not globally
A single risk policy applied unilaterally across the user journey is exactly what JTO wants to replace. Event-level policies let you specify which signals are relevant at each step and what to do when those signals exceed a threshold. This should happen independently for each event, rather than as a blanket rule across the whole session. It’s this mechanism that makes adaptive authentication genuinely dynamic rather than a blunt, step-up-only instrument.
A/B test systematically
Organizations cannot fine-tune for user experience or shifting risk conditions without reliable comparisons. How else can they know which change will result in better outcomes? A mature JTO implementation supports running A/B tests and splitting traffic between paths to assess which delivers better outcomes: conversion rates, assurance, login completion, and so on.
The sequence in which various steps execute can also be tweaked to find configurations that hit trust thresholds more efficiently. JTO handles the vendor logic (translation and invocation), which lives in the orchestration layer; the main additional work is any UI modifications the test requires.
Build failover into identity flows
For capabilities where a user’s personally identifiable information (PII) is passed to a vendor for processing, configuring a designated backup costs relatively little and significantly improves resilience. Because the orchestration layer normalizes responses to shared internal attributes, the event-level policy doesn’t need to change when the primary vendor is unavailable. The logic stands regardless of which vendor fires, and the user continues undisrupted.
Evaluate the quality of the signals JTO surfaces
Vendor dependence can be a significant infrastructural risk in a JTO implementation. For example, if a vendor makes top-level risk scores available but keeps the underlying, raw signals inaccessible, the granularity of your event-level policies will be capped by what is actually exposed. Carefully assess what a vendor is actually willing to make visible to your risk engine. Here, having a test bed for workflow changes can be especially valuable; validating user journeys before live sessions can reveal whether the risk signals you’re incorporating are actually delivering quality decisions.
The DIY problem with JTO
Many organizations, across all industries and of various sizes, have attempted to address their vendor fragmentation by building their own orchestration layers. Some of those implementations manage the logic well at first, but the persistent problem isn’t building orchestration. It’s maintaining live integrations with a rotating roster of downstream integrations.
This is a surface that expands over time, accumulating a swath of tech debt as new tools are added and old ones become difficult to remove. A homegrown layer that requires custom engineering for each new vendor isn’t really delivering the operational benefit that makes JTO worth the investment.
The build-versus-buy conundrum can turn into vendor lock-in or DIY overload much faster than most teams expect, for the same reason it does in the broader customer and partner IAM landscape: ongoing maintenance costs are harder to anticipate upfront than the initial expense of building.
How Descope helps you implement JTO
Descope has been named a Representative Vendor for JTO capabilities in three Gartner® Hype Cycle reports: the 2025 Hype Cycle for Digital Identity, the 2025 Hype Cycle for Banking Customer Experience, and the 2025 Hype Cycle for Fraud and Financial Crime Prevention. That recognition spans three distinct research tracks because the problem JTO addresses shows up across identity, banking, and fraud contexts alike, and Descope covers all of them with the same underlying platform.
Descope’s capabilities natively map to the JTO framework presented by Gartner®, addressing all six components needed for a complete implementation.
User journey mapping, user journey control, no/low-code flexibility: Descope Flows is a no-/low-code visual workflow designer for building and modifying user journeys without touching your codebase
Data mapping and normalization, vendor integration management: The connectors ecosystem provides prebuilt integrations with 50+ third-party tools spanning IDV, ATO prevention, device intelligence, risk analytics, and fraud detection
Event-level policy definition: Adaptive MFA and fraud prevention capabilities tie risk signals directly into the branching logic of your flows
If you're considering an identity modernization initiative, it will be incomplete without an orchestration layer. But building it yourself can be costly in the long run: ongoing maintenance, tech debt, and stealing focus from core product are all real risks of DIY orchestration.
Descope offers the tools to fully control your user identity experience without handling all the heavy lifting alone. Sign up for a Free Forever account now, or book a demo to see how we can help.
¹ Gartner, Innovation Insight: IAM Journey-Time Orchestration, By Akif Khan, 14 February 2025.
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research and advisory organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.
