--- title: Integrate PingOne Protect description: Integrate PingAM with PingOne Protect to add risk-based authentication and fraud detection to authentication journeys using real-time behavioral and contextual risk signals. component: pingam version: 8.1 page_id: pingam:integrations:pingone-protect canonical_url: https://docs.pingidentity.com/pingam/8.1/integrations/pingone-protect.html llms_txt: https://docs.pingidentity.com/pingam/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md section_ids: why_use_pingone_protect: Why use PingOne Protect? set_up_a_pingone_protect_journey: Set up a PingOne Protect journey optimize-risk-models: Optimize the PingOne Protect risk models --- # Integrate PingOne Protect Integrate AM with PingOne Protect to add risk-based authentication and fraud detection to your authentication journeys. PingOne Protect uses continuous, intelligence-based fraud detection to evaluate real-time risk signals from a user's device, network, and behavior to determine when additional authentication is required. ## Why use PingOne Protect? * Adaptive security Dynamically adjusts authentication requirements based on real-time risk signals such as location, device, and behavioral anomalies. This means low-risk logins are frictionless, while high-risk attempts trigger additional challenges, such as multi-factor authentication (MFA). * Reduced fraud Proactively identifies and mitigates fraudulent activities, such as account takeover (ATO), credential stuffing, and bot attacks, by analyzing a wide range of contextual factors during authentication. * Improved user experience Reduces friction for legitimate users by prompting for additional authentication only when necessary. * Granular control Provides detailed risk scores and lets you define policies for different risk levels within journeys. ## Set up a PingOne Protect journey | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------- | | | Make sure you've completed the steps in [Connect AM to PingOne](connect-am-to-pingone.html) before configuring a PingOne Protect journey. | AM provides the following nodes to integrate PingOne Protect into your authentication journeys: * PingOne Protect Initialize node The [PingOne Protect Initialize node](https://docs.pingidentity.com/auth-node-ref/8.1/pingone/pingone-protect-initialize.html) instructs the client to initialize a PingOne Signals (Protect) SDK so that it can start gathering device signals and contextual information. * PingOne Protect Evaluation node The [PingOne Protect Evaluation node](https://docs.pingidentity.com/auth-node-ref/8.1/pingone/pingone-protect-evaluation.html) contacts PingOne to calculate the risk level and other risk-related details associated with an event. Depending on how you configure your risk policies in PingOne, the response could return: * A risk score. * A risk level, such as high, medium, or low. * Recommended actions to take, such as mitigation against bots. * PingOne Protect Result node The [PingOne Protect Result node](https://docs.pingidentity.com/auth-node-ref/8.1/pingone/pingone-protect-result.html) updates the risk evaluation configuration or modifies the completion status of the resource while the risk evaluation is still in progress. You can check the results of the evaluation in the PingOne admin console by filtering for Risk Evaluation Updated event types. Create a journey using these nodes to integrate PingOne Protect into your authentication flow. For example: ![Example PingOne Protect journey](_images/pingone-protect-example-journey.png) Learn more in the [PingOne Protect example](https://docs.pingidentity.com/auth-node-ref/8.1/pingone/pingone-protect-initialize.html#example). ## Optimize the PingOne Protect risk models PingOne Protect is preconfigured with a default machine learning model that assesses risk based on various [predictors](https://docs.pingidentity.com/pingone/threat_protection_using_pingone_protect/p1_protect_risk_predictors.html) such as user behavior, device characteristics, and network context. You can optimize the model by letting it observe real authentication data and then refine the risk policies it applies to that data: 1. **Run with production data** Integrate PingOne Protect into your journeys and let it observe real user behavior. Ping Identity recommends running with the default risk policy for: * 1 to 3 weeks for workforce use cases * 2 to 4 weeks for customer use cases During this period, PingOne Protect builds a baseline of normal behavior for your users and environments. This includes learning patterns related to device, location, network, and user-specific habits. Make sure you send transaction feedback using PingOne Protect Result nodes to report whether each transaction was a `SUCCESS` or `FAILURE`. This feedback loop is essential for the models to learn to distinguish legitimate activity from fraud. 2. **Monitor and analyze** Use the PingOne Protect [threat protection dashboard](https://docs.pingidentity.com/pingone/threat_protection_using_pingone_protect/p1_protect_dashboard.html) to analyze activity after the initial observation period. The dashboard provides insights into risk evaluations, including: * Number of abnormal activities * High-risk locations and factors * Riskiest users * Distribution of browser and operating systems Focus on identifying false positives. These are legitimate user interactions that PingOne Protect flagged as high or medium risk. Analyze why these were flagged as risky by looking at the specific predictors involved. 3. **Refine risk policies** Based on your analysis, fine-tune how predictor output is translated into a final risk score and level using [risk policies](https://docs.pingidentity.com/pingone/threat_protection_using_pingone_protect/p1_protect_risk_policies.html): * Adjust the numerical score assigned to individual predictors within your risk policies based on your analysis of false positives and false negatives. * For each predictor (for example, `Anonymous Network`, `IP Velocity`, or `User Location Anomaly`), map its calculated risk level (low, medium, high) to a specific score. * Define the risk thresholds that map to a low, medium, or high overall risk level. For example, if `IP Location Anomaly` frequently causes false positives for users who travel, you might reduce the score assigned to a high risk for that specific predictor, or create a more lenient predictor for specific user groups. Optimization is an iterative process. Continue to monitor the threat protection dashboard and adjust risk policies as needed.