An end-to-end guide, in applied mode, to building a credible PingOne Protect demo. It starts with what Protect is and is not, then lays out the three-beat demo arc, the licence tiers, and the eight Risk-tier predictors as against the six Protect-tier ones. From there it walks through standing up the environment and the worker app, building a targeted risk policy with scores, thresholds, overrides, and mitigation, wiring it up through the riskEvaluations API and a DaVinci flow, adding the PingOne Signals SDK, triggering each predictor live, and proving the result on the Threat Protection dashboard and in the audit log. The deck includes nine traps, six checks, a full run of show, and two closing slides of cited documentation links.
Subject: Identity & Access Management · 139 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
Identity Threat Protection · Build Guide
A start-to-finish playbook for standing up a PingOne Protect demo your company will actually believe: the environment, the predictors, the policy, the flow, the SDK, and the six signals you can fire live on stage.
Objectives
A Protect demo fails for one of two reasons: nothing risky ever happens, or everything is risky and the audience stops trusting the score. This deck is built to prevent both.
Everything here is checked against Ping's official documentation. The sources block in this deck's JSON lists every page used, so you can hand a skeptic the link.
Section
Part 1
Concept
Picture the demo. Your CISO, an IAM engineer, and someone from the fraud team are on the call. You share your screen and log in successfully. Nothing happens. Everyone waits.
The question in the room is not "does Ping have a risk engine?" It is: "what would this have caught last quarter, and what would it have annoyed my users about?"
A demo that answers only the first half sells nothing. Every design decision in this deck exists to answer both halves in the same ten minutes.
Counterexample
Discussion prompt
Picture the demo. Your CISO, an IAM engineer, and someone from the fraud team are on the call. You share your screen and log in successfully. Nothing happens. Everyone waits.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Answer:
The question in the room is not "does Ping have a risk engine?" It is: "what would this have caught last quarter, and what would it have annoyed my users about?"
Intuition
Think of your login as a door with a lock. The lock checks credentials: right key, you're in. That's authentication — passwords, passkeys, MFA.
PingOne Protect is not the lock. It's the bouncer standing next to the door, watching who's approaching.
Same key, but you arrived from Lagos nine minutes after badging in from Dallas, on a device nobody has ever seen, over a Tor exit node — the bouncer says hold on even though the key is genuinely yours.
This is why Protect is sold as risk-based authentication: it doesn't replace the lock, it decides how hard the lock should be today.
Analogy
Discussion prompt
Explain The bouncer, not the door by analogy to something with no Identity & Access Management in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Think of your login as a door with a lock. The lock checks credentials: right key, you're in. That's authentication — passwords, passkeys, MFA.
Concept
PingOne Protect — A PingOne cloud service that evaluates the risk of an identity event — a sign-on, a registration, a transaction — and returns a risk level of LOW, MEDIUM, or HIGH plus a recommended action, which your authentication flow then acts on.
Two things it is not, and you should say both out loud in the demo before someone asks:
Explain it
Discussion prompt
Explain So what is PingOne Protect? to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Two things it is not, and you should say both out loud in the demo before someone asks:
Concept
Almost every question you'll get in a demo is really about one of three objects. Learn the boundary between them and you can answer live.
Ping's docs put it plainly: risk policies determine "how the various risk predictors are combined and how the aggregated risk score should be translated into a final risk level."
Matching
Match the pairs
From Three moving parts — memorize these — match each one to what it actually does. The descriptions have been shuffled.
Why: Predictors, Risk Policy, Risk Evaluation are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Ranking
Put in order
Put the moves of One sign-on, all the way through into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Risk is evaluated in-flow, so the answer can change the flow's next step — that's the whole point.
Worked example
Follow a single login end to end. This is the exact walkthrough to narrate on your third demo slide.
A user submits credentials to your app; the flow calls Protect before deciding what to do next.
Why: Risk is evaluated in-flow, so the answer can change the flow's next step — that's the whole point.
Protect runs every predictor in the assigned policy against the event: IP, device data from the SDK, this user's history.
Why: Each predictor independently returns low, medium, or high — they do not talk to each other.
The policy converts each medium/high predictor result into its configured score, and sums them.
Why: Ping's docs describe using Scores to "specify an exact numerical score that should be assigned when PingOne Protect determines a medium or high risk level for a predictor."
The summed score is compared to your High and Medium thresholds to produce the final level.
Why: This is the only number the flow branches on — everything before it is inputs to this one mapping.
The flow branches: LOW allows silently, MEDIUM steps up to MFA, HIGH denies or locks.
Why: Your branching is a business decision, not a Ping default — say so in the demo, because it's the part the buyer controls.
After the user finishes, the flow updates the evaluation with a completion status.
Why: The docs are explicit that completion status should indicate SUCCESS or FAILED — this feedback is what lets the models learn.
Reverse engineer
Discussion prompt
Work backwards. The example finished here:
After the user finishes, the flow updates the evaluation with a completion status.
What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.
Hint: Every quantity in the result had to enter somewhere. Account for each one.
Answer:
Follow a single login end to end. This is the exact walkthrough to narrate on your third demo slide.
Anomaly
Predict first
A student writes this, and it looks reasonable:
The pitch: "It's MFA, but it only prompts when it needs to."
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Now every question is about authenticators, push notifications, and FIDO support — none of which Protect does.
The pitch: "It's the decision layer in front of whatever MFA you already run."
Why: Now every question is about authenticators, push notifications, and FIDO support — none of which Protect does.
Trap
The pitch: "It's MFA, but it only prompts when it needs to."
The buyer hears: this replaces our MFA.
Why: Now every question is about authenticators, push notifications, and FIDO support — none of which Protect does.
First hard question kills it: "so does it do passkeys?"
Why: You say no, and the room silently reclassifies the product as incomplete.
The pitch: "It's the decision layer in front of whatever MFA you already run."
The buyer hears: this makes our existing investment smarter.
Why: Protect's own docs frame the DaVinci use case as reducing "MFA fatigue" and lowering "the probability of unintentional push approvals" — it improves MFA rather than replacing it.
The passkey question now has a good answer: "Protect decides whether to challenge; your passkey flow handles how."
Why: The product stays in its lane and the demo keeps its credibility.
Concept
Before you build anything, decide which surface you're demoing, because it changes your whole setup. Ping's getting-started guide lists four integration methods.
| Surface | Use it when | Demo cost |
|---|---|---|
| PingFederate + Protect Integration Kit | The company already runs PingFederate on-prem | High — needs a PF instance |
| PingOne DaVinci flow | You want a visual flow you can edit live on stage | Medium — best storytelling |
| PingOne Protect API (direct) | You have a custom app, or you want a scriptable demo | Low — fastest to stand up |
| PingOne Advanced Identity Cloud journey | The company is on AIC / ForgeRock journeys | Medium — three nodes to add |
Recommendation for a first company demo: build the API path first because it always works and takes an afternoon, then add a DaVinci flow on top for the visual. The API version is your safety net if the flow breaks on stage.
Comparison
Comparison matrix
From Where Protect plugs in — four surfaces: refill the Use it when column from what you know. The rest of the table is as it appeared.
| Surface | Use it when | Demo cost |
|---|---|---|
| PingFederate + Protect Integration Kit | The company already runs PingFederate on-prem | High — needs a PF instance |
| PingOne DaVinci flow | You want a visual flow you can edit live on stage | Medium — best storytelling |
| PingOne Protect API (direct) | You have a custom app, or you want a scriptable demo | Low — fastest to stand up |
| PingOne Advanced Identity Cloud journey | The company is on AIC / ForgeRock journeys | Medium — three nodes to add |
Concept
This is the single most common way a Protect demo dies mid-build: you design a story around bot detection, then discover your environment can't turn it on.
Ping's getting-started page draws the line clearly: a PingOne Risk license provides access to eight predictors, while additional predictors require a PingOne Protect license.
| License | Predictors you get |
|---|---|
| PingOne Risk | Anonymous Network Detection, Geovelocity Anomaly, IP Reputation, IP Velocity, New Device, User-Based Risk Behavior, User Location Anomaly, User Velocity |
| PingOne Protect (adds) | Adversary-in-the-Middle, Bot Detection, Email Reputation, PingID Device Trust, Suspicious Device, Traffic Anomaly |
There's a second gate underneath the license: risk evaluation requests require PING_ONE_RISK in the Bill of Materials (BOM) for your environment. If it isn't there, the API rejects you regardless of what the console shows.
Trap
Day 1: you storyboard the demo around AI-agent bot detection, because that's what the exec asked about.
You script the whole narrative, book the meeting, and only then open the console.
Why: Bot Detection requires a PingOne Protect license — it is not in the eight-predictor Risk tier.
Two days before the demo you're emailing your account team asking for a license upgrade.
Why: Best case you slip the date; worst case you demo a story you can't actually run.
Day 1: you open Threat Protection → Predictors and list what is actually available in this environment.
Storyboard only around predictors you can see in the console today.
Why: The eight Risk-tier predictors already carry three excellent stories: anonymous network, impossible travel, and new device.
Put the licensed-only predictors in a "phase 2" slide instead of the live demo.
Why: You still get to talk about AitM and bot detection — as roadmap, not as a promise you have to render live.
Ranking
Put in order
These are the steps of The build recipe — ten steps, in order, scrambled. Put them back in order before the next slide shows you.
PING_ONE_RISK is in the environment's BOM.Why: This is the order the recipe itself gives. Recalling the sequence without the slide in front of you is the difference between recognising the method and being able to run it — most of what goes wrong in practice is a step done out of turn.
Pattern
Everything else in this deck expands one of these steps. Photograph this slide; it's the checklist.
PING_ONE_RISK is in the environment's BOM.Steps 1-5 are plumbing and can be done in an afternoon. Steps 6-10 are the demo, and they're where the thinking goes.
Elimination
Eliminate the wrong options
In PingOne Protect, what decides whether an event's final risk level is HIGH?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: A
Why: Predictors each return a level independently. The risk policy assigns a numerical score to each medium or high predictor result, sums them into an aggregated score, and maps that total onto the Low / Medium / High thresholds you configure. Overrides can force a level, but the default path is score-then-threshold.
Check
Answer before clicking. This one separates people who've read the docs from people who've built the demo.
Check your understanding
In PingOne Protect, what decides whether an event's final risk level is HIGH?
Answer: A
Why: Predictors each return a level independently. The risk policy assigns a numerical score to each medium or high predictor result, sums them into an aggregated score, and maps that total onto the Low / Medium / High thresholds you configure. Overrides can force a level, but the default path is score-then-threshold.
Section
Part 2
Concept
Your company has a fraud problem it can name. Start there, not at the predictor list. A demo is a story with a product in it, and three is the number that fits in a meeting.
These three cover the overwhelming majority of what buyers actually worry about, and every one of them runs on the Risk-tier predictors you already have:
| Story | Business fear | Predictor that carries it |
|---|---|---|
| Credential stuffing at scale | Our leaked passwords are being sprayed at us | IP Velocity, User Velocity, IP Reputation |
| Account takeover from abroad | Someone in another country is using a real password | Geovelocity Anomaly, Anonymous Network Detection |
| Session hijack / unknown device | The password is right but the human is wrong | New Device, User-Based Risk Behavior |
Notice each story names a fear, not a feature. "Impossible travel detection" is a feature. "Someone in Lagos has Dana's real password" is a story.
Trade off
Comparison matrix
From Pick exactly three stories: every row here is a choice with a cost. Fill the Predictor that carries it column, then say which row you would actually pick and what you give up for it.
| Story | Business fear | Predictor that carries it |
|---|---|---|
| Credential stuffing at scale | Our leaked passwords are being sprayed at us | IP Velocity, User Velocity, IP Reputation |
| Account takeover from abroad | Someone in another country is using a real password | Geovelocity Anomaly, Anonymous Network Detection |
| Session hijack / unknown device | The password is right but the human is wrong | New Device, User-Based Risk Behavior |
Intuition
Demos that convince follow the same shape as a good bug report: expected, actual, fix.
Beat 1 is the one everyone skips, and skipping it is why demos fail. Without it the audience has no idea whether your HIGH result means anything — maybe everything comes back high.
Beat 3 is what turns a product demo into a control demo. It answers the second half of the room's real question: "what will this annoy my users about, and can I tune it?"
Step zero
Discussion prompt
Storyboarding beat 2 in detail — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Set the scene in one sentence: "Dana's password showed up in a breach…
Answer:
result.level of HIGH, and the recommendedAction.Worked example
Take the account-takeover story. Here's how to turn it into ninety seconds of screen time.
Set the scene in one sentence: "Dana's password showed up in a breach dump. Someone in another country just tried it."
Why: Naming a person makes the audience track a human, not a JSON field.
Show the request going out with a foreign IP and a device fingerprint the tenant has never seen.
Why: Two predictors will fire — Geovelocity Anomaly and New Device — which demonstrates aggregation instead of a single tripwire.
Read the response out loud: result.level of HIGH, and the recommendedAction.
Why: Reading the raw field names once buys credibility with the engineers, who need to know this is a real API and not a mock.
Show the flow's branch firing — the MFA challenge or the denial.
Why: The audience must see a consequence. A risk score with no consequence is a dashboard, not a control.
Cut to the audit log entry and the dashboard tile updating.
Why: This proves the event is recorded, which is the compliance team's only question and it will be asked.
Blank canvas
Draw it
Draw what Storyboarding beat 2 in detail just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.
Concept
Same demo, three audiences, three different sentences. Decide which one you're giving before you start.
| Audience | What they're measuring | Lead with |
|---|---|---|
| Security / CISO | Coverage and false negatives | The HIGH-risk catch, and what signals fed it |
| Product / CX | Friction and false positives | The LOW-risk silent pass, and the tuning dial |
| Engineering / IAM | Integration cost | The API call and the flow — how few moving parts there are |
| Fraud / Risk ops | Investigability | The dashboard, Risk Details, and the feedback loop |
If all four are on the call, run the arc in the standard order but spend your extra minute on whoever holds the budget.
Anomaly
Predict first
A student writes this, and it looks reasonable:
The instinct: turn on all fourteen predictors so the demo looks powerful.
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The aggregate score crosses your High threshold on completely legitimate traffic.
The discipline: three predictors, three stories, one policy.
Why: The aggregate score crosses your High threshold on completely legitimate traffic.
Trap
The instinct: turn on all fourteen predictors so the demo looks powerful.
Every login now scores HIGH because a dozen weak signals stack up.
Why: The aggregate score crosses your High threshold on completely legitimate traffic.
The audience asks "so it flags everyone?" and you spend the rest of the call defending the product.
Why: You have accidentally demonstrated a false-positive machine, which is the exact thing the CX stakeholder feared.
The discipline: three predictors, three stories, one policy.
Score only the predictors your stories need; leave the rest out of the policy.
Why: A predictor with no score in the policy contributes nothing to the total, so it can't create noise.
Mention the others by name as available headroom.
Why: "We're using three today; there are eleven more" sounds like depth. Turning all fourteen on sounds like you didn't tune it.
Pattern
Fill this in before you touch the console. If you can't complete a row, that story isn't ready.
| Field | Your answer |
|---|---|
| Fear (one sentence, no jargon) | |
| Character name and situation | |
| Predictor(s) that must fire | |
| How I trigger it live | |
| Expected result.level | |
| Flow branch the audience sees | |
| Where I show the evidence afterward |
Three of these tables — one per story — is your entire demo script. Everything else is setup.
Prediction
Predict first
Why is the 'boring login' (a normal user who gets LOW risk and passes silently) considered mandatory in a Protect demo?
Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.
Correct: It establishes a baseline, so the later HIGH result proves discrimination rather than blanket suspicion
Why: Without a low-risk control case, the audience cannot tell whether HIGH means the system detected something or simply flags everything. The contrast between the silent pass and the blocked attempt is what demonstrates the engine discriminates — which is the entire value proposition.
Check
Think about what each choice actually proves to the audience.
Check your understanding
Why is the 'boring login' (a normal user who gets LOW risk and passes silently) considered mandatory in a Protect demo?
Answer: A
Why: Without a low-risk control case, the audience cannot tell whether HIGH means the system detected something or simply flags everything. The contrast between the silent pass and the blocked attempt is what demonstrates the engine discriminates — which is the entire value proposition.
Section
Part 3
Concept
You want your own environment, not a shared corporate one, because you will change thresholds live and you do not want that landing on production traffic.
Ping's getting-started page lists exactly what you need before beginning:
Those two roles matter more than they look. Environment Admin lets you add the service and edit policies; Identity Data Admin lets you read user data — which is what the Risk Details window needs later.
Estimation
Predict first
This is a four-click operation and it's the moment Threat Protection appears in your left-hand nav.
Commit before you compute: what does Adding the PingOne Protect service come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.
Correct: Verify: open Threat Protection → Predictors and confirm you see the default predictors listed.
Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. When Protect is added to an environment, one predictor of each basic type is included by default — seeing them confirms the service is live, not just licensed.
Worked example
This is a four-click operation and it's the moment Threat Protection appears in your left-hand nav.
In the admin console, go to Overview.
Why: The Overview page is where an environment's enabled services are listed and managed.
Click the plus icon next to Services.
Why: This opens the catalog of services that can be added to this environment.
Find PingOne Protect and click Add.
Why: If Protect isn't offered here, the environment's license or BOM doesn't include it — stop and fix that first rather than working around it.
Click Finish.
Why: The service is now enabled, and a Threat Protection section appears in the navigation with Dashboard, Risk Policies, and Predictors.
Verify: open Threat Protection → Predictors and confirm you see the default predictors listed.
Why: When Protect is added to an environment, one predictor of each basic type is included by default — seeing them confirms the service is live, not just licensed.
Concept
Worker application — A PingOne application that represents your script or backend rather than a human user. It authenticates with a client ID and secret and receives an access token that carries admin scopes.
You need one for two reasons in a demo: the API path requires a token to create risk evaluations, and the DaVinci connector authenticates through a worker connection as well.
The Protect connector's prerequisites name it directly — you need a worker application, either the preconfigured PingOne DaVinci Connection or a custom one.
Definition probe
Sort into buckets
Every line below is part of the definition of PingOne Protect or of Worker application — one or the other, never both. Put each where it belongs.
Missing information
Discussion prompt
Do this once, save the values in your password manager, and your demo becomes scriptable.
What do you need to know — or decide — before the first line can be written? List everything the problem has to hand you.
Hint: Anything you would have to invent to get started is a thing the problem must supply.
Answer:
Worker apps use the client credentials grant, which needs no human in the loop — exactly what a demo script wants.
Worked example
Do this once, save the values in your password manager, and your demo becomes scriptable.
In Applications, add a new application and choose the Worker application type.
Why: Worker apps use the client credentials grant, which needs no human in the loop — exactly what a demo script wants.
Save the Client ID, Client Secret, and Environment ID.
Why: The environment ID appears in the URL and on the environment's properties; you'll paste it into every API call and SDK init.
Grant the app the roles it needs, at minimum the ones covering risk and identity data.
Why: A token only carries the scopes its app was granted — a 403 on riskEvaluations is nearly always a missing role, not a bad secret.
Request a token with the client credentials grant against your region's auth host.
Why: PingOne is regional: North America uses pingone.com, with .eu, .asia, and .ca hosts for other regions. Using the wrong host is a silent, confusing failure.
curl -X POST \
"https://auth.pingone.com/$ENV_ID/as/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-u "$CLIENT_ID:$CLIENT_SECRET" \
-d "grant_type=client_credentials"Confirm the response contains an access_token and note its short lifetime.
Why: Tokens expire; bake the token request into your demo script rather than pasting a token that will be dead by showtime.
Error analysis
Annotate
Walk the callouts on Creating the worker app and getting a token. Each one is a place this is easy to get subtly wrong.
Trap
The setup: you grab a token during rehearsal and paste it into your script.
Three hours later you run the demo live.
Why: The access token has expired, and every risk evaluation call returns 401.
You debug authentication in front of the CISO.
Why: The audience now associates the product with brittleness, which is the opposite of the impression a security tool needs to make.
The setup: your script fetches a fresh token as its first action, every run.
Wrap the token call and the evaluation call in one script.
Why: The token is always seconds old, so expiry can't bite you regardless of when the meeting actually starts.
Run the whole script end to end during rehearsal, then again five minutes before you present.
Why: The second run is what catches an expired secret, a rotated role, or a tenant that changed under you.
Concept
A brand-new environment with one user is the worst possible demo environment, and it's what most people build.
Several predictors are explicitly comparative — they measure this event against that user's past events. With no past, there is nothing to compare to.
This is the single highest-leverage prep task in the whole build, and it's the one that can't be done the night before.
Section
Part 4
Concept
Concretely: a predictor is a detector with an opinion. Ping describes predictors as learning user behavior and detecting anomalies.
Each one evaluates its own narrow question and returns a level. The policy is what turns levels into a number — the predictor itself has no idea what score it's worth.
Most predictors also accept a fallback value: the level to assume when the predictor cannot reach a conclusion, usually because required data is missing.
Fallbacks are a demo hazard and a production hazard both. A missing SDK payload plus an aggressive fallback equals mysterious high risk on perfectly normal logins.
Concept
These come with the PingOne Risk license, and when Protect is added to an environment, one predictor of each basic type is included by default.
| Predictor | What it detects |
|---|---|
| Anonymous Network Detection | Access via unknown VPNs, Tor, and proxies — how malicious actors typically hide origin |
| Geovelocity Anomaly | Impossible travel between consecutive sign-on locations |
| IP Reputation | IPs involved in malicious activity such as DDoS or spam |
| IP Velocity | One user appearing from many IPs in a short window |
| User Velocity | Many users appearing from one IP address |
| New Device | A device never seen before, or unused for 12+ months |
| User Location Anomaly | Sign-on outside a radius of the user's previous location — 50 km by default |
| User-Based Risk Behavior | ML comparison of this transaction against the typical behavior of that specific user |
Three of these — IP Reputation, Anonymous Network, and Geovelocity — need nothing but an IP address, which makes them the easiest signals to fire live.
Concept
These need the fuller PingOne Protect license. Know them by name even if you can't demo them, because the exec who read the datasheet will ask.
| Predictor | What it detects | Needs SDK |
|---|---|---|
| Bot Detection | Non-human activity including agentic AI automation, computer-using agents (CUAs), automated frameworks, and recorders | Yes |
| Adversary-in-the-Middle (AitM) | Reverse-proxy attacks harvesting user credentials and session tokens | Yes |
| Suspicious Device | Emulators, super-user permissions, virtual machines, mirroring apps, tampered devices | Yes |
| Traffic Anomaly | Brute-force attacks via high volume of evaluations and suspicious user-per-device ratios | No |
| Email Reputation | Disposable email addresses at registration | No |
| PingID Device Trust | Whether a workstation is a known, trusted, managed device | No (needs PingID agent) |
Two of these carry a built-in action rather than just a level: Traffic Anomaly returns a DENY recommendation at high risk, and Email Reputation exposes an actionable TEMP_EMAIL_MITIGATION response field.
Discrimination
Sort into buckets
Sort these by Needs SDK, from memory, without looking back at The Protect-license predictors. Telling them apart on the spot is the skill; the table is only where the answer happens to be written down.
Intuition
Rule-based predictors work on their first request: an IP either is a Tor exit or it isn't. Machine-learned predictors are different — they need to know what normal looks like for your population first.
Ping's guidance is concrete: train models for 1-3 weeks for workforce populations, or 2-4 weeks for customer populations, before you start tuning.
Think of it like a new night-shift guard. Week one, everyone looks suspicious because they've never seen anyone. By week three they know who belongs.
Demo consequence: if your environment is three days old, do not build your story on User-Based Risk Behavior. Build it on the rule-based signals, and talk about the ML ones as what improves after deployment.
Anomaly
Predict first
A student writes this, and it looks reasonable:
The plan: "I'll show the ML predictor spotting anomalous behavior."
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The model has no baseline for this user, so it either returns nothing useful or falls back to its configured fallback value.
The plan: rule-based signals carry the live demo; ML carries the roadmap.
Why: The model has no baseline for this user, so it either returns nothing useful or falls back to its configured fallback value.
Trap
The plan: "I'll show the ML predictor spotting anomalous behavior."
Environment is four days old with three logins total.
Why: The model has no baseline for this user, so it either returns nothing useful or falls back to its configured fallback value.
On stage, the anomaly you carefully staged scores LOW.
Why: You cannot explain why in the moment, and the demo's climax is a shrug.
The plan: rule-based signals carry the live demo; ML carries the roadmap.
Stage the live moment on Anonymous Network Detection or Geovelocity Anomaly.
Why: Both are deterministic given the IP, so they behave identically in rehearsal and on stage.
Show the User-Based Risk Behavior predictor's config and the Risk Details window instead of trying to trigger it.
Why: You demonstrate the capability and the investigation UI honestly, without betting the demo on an untrained model.
Break the constraint
Discussion prompt
The rule this trap just fixed:
Both are deterministic given the IP, so they behave identically in rehearsal and on stage.
Now break it on purpose. Build a case that violates it and follow the consequences until something visibly fails. Where does the failure first show up — and would you have noticed it if you had not been looking?
Hint: The dangerous rules are the ones whose violation still produces an answer. If yours fails loudly, try to find one that fails quietly.
Answer:
The model has no baseline for this user, so it either returns nothing useful or falls back to its configured fallback value.
Step zero
Discussion prompt
Configuring New Device for a demo — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Go to Threat Protection → Predictors and open the New Device…
Answer:
Worked example
New Device is the best-behaved predictor for a live demo: deterministic, easy to trigger, and instantly intuitive to a non-technical audience.
Go to Threat Protection → Predictors and open the New Device predictor.
Why: Predictors are configured independently of policies; a predictor exists whether or not any policy scores it.
Understand its rule: it flags devices never seen before, or not used for 12 or more months.
Why: The twelve-month window is worth saying out loud — buyers assume 'new' means 'first ever' and it's broader than that.
Set the fallback value deliberately.
Why: New Device leans on device identification from the SDK or persistent cookies; the fallback is what applies when neither is present.
If the environment has messy historical data, set an activation date to restart learning.
Why: This is how you get a clean baseline without rebuilding the environment — every device before that date is ignored.
Trigger it: open a private browsing window, or clear cookies, and sign in as a user who normally uses your main profile.
Why: That destroys the device identifier the tenant associated with the user, so the next sign-on genuinely is a new device.
Concept
Every security buyer has the same objection: "our whole sales team is on a corporate VPN, are you going to flag all of them?"
Anonymous Network Detection, IP Reputation, and Geovelocity Anomaly each support an allow list of IP addresses to ignore.
Adding your corporate egress range to that list — live, on stage — and re-running the same login to watch it drop from HIGH to LOW is one of the most persuasive thirty seconds available to you.
It answers the friction question with a demonstration instead of a promise, which is worth more than any slide.
Concept
Beyond the built-ins, Protect lets you extend the model in two directions. Both matter for a company demo because they answer "can it use our data?"
The custom predictor is the answer to the question you will definitely get: "we already have a fraud score from a third party — can Protect use it?" Yes: push it in as a custom predictor and give it a score in the policy alongside the built-ins.
You can also fine-tune existing predictors — rename them and edit their settings — which is how you make the console read in your company's own language.
Ranking
Put in order
These are the steps of Choosing predictors — the filter, scrambled. Put them back in order before the next slide shows you.
Why: This is the order the recipe itself gives. Recalling the sequence without the slide in front of you is the difference between recognising the method and being able to run it — most of what goes wrong in practice is a step done out of turn.
Pattern
Run every candidate predictor through these four questions. Anything that fails one is out of the live demo.
The three that pass all four in almost every environment: Anonymous Network Detection, Geovelocity Anomaly, and New Device. Start there and add only if you have a specific reason.
Check
One of these is a licensing/architecture fact people get wrong constantly.
Check your understanding
Your environment has a PingOne Risk license and no Signals SDK deployed. Which predictor can you still demonstrate live?
Answer: A
Why: Anonymous Network Detection is one of the eight predictors included with the PingOne Risk license, and it works from the originating IP address alone — no client SDK required. That combination of 'in the base license' and 'no SDK' is exactly why it is the most reliable predictor to build a live demo around.
Section
Part 5
Concept
There are two policy types, and picking the wrong one produces the confusing failure where your policy exists but never seems to apply.
| Type | How it gets used |
|---|---|
| Global (legacy) | Requires explicit selection during the risk evaluation — you pass its policy ID in the request |
| Targeted | Applies automatically based on the flow types, applications, and user groups you define on the policy |
For a demo, build a targeted policy. It applies on its own, so a forgotten policy ID in your API call can't silently route you to the default policy instead.
If you do use a global policy, remember the Protect connector and the API both accept an optional Risk Policy ID — omitting it is what sends you to the default.
Worked example
This is the exact console path. Rehearse it, because editing a policy live is beat 3 of your demo arc.
Go to Threat Protection → Risk Policies and click the tab for Targeted.
Why: The Global tab holds legacy policies; targeted policies are the current model and carry their own applicability conditions.
Click the plus icon to add a risk policy. Optionally click Assistant for guided setup.
Why: The Risk Policy Assistant is worth showing to a non-technical audience — it makes the tuning look approachable rather than arcane.
Enter a unique name in the Name field.
Why: Name it after the story, e.g. 'Demo - Customer Sign-on', so the audience can connect the policy to what they're watching.
Choose the Flow type checkboxes: Registration, Authentication, Authorization, Access, or Transaction.
Why: Flow type is how one environment can score a registration differently from a sign-on — that distinction alone often sells the fraud team.
Choose the Applications (all or specific) and Groups (all or specific) this policy targets.
Why: Scoping to one demo application keeps the policy from affecting anything else in the tenant while you experiment on stage.
Click Add Predictor, select one from the Risk Model list, and set its score — maximum 100.
Why: Repeat per predictor. Only predictors you add here contribute to the total; everything else is inert for this policy.
Set the total risk score values for the High and Medium final risk levels.
Why: These two numbers are the entire mapping from score to level, and they're the dial you'll turn during beat 3.
Click Apply to save the policy.
Why: Verify by running one evaluation and confirming the returned level matches what your score sheet predicts.
Concept
Scores are where your company's judgment lives. The policy asks: when this predictor says medium or high, how many points is that worth?
A useful default philosophy is baked into Ping's own default policy: non-IP-based predictors are scored higher than IP-related signals, because they're considered stronger risk indicators.
That's a defensible position and worth explaining. An IP is shared, NATed, and changes constantly; a device fingerprint or a behavioral deviation is much closer to being about the actual human.
The maximum score for a single predictor is 100, which means one predictor can be made decisive on its own if you want it to be.
Hypothesis
Predict first
A worked score sheet is about to be worked. State your hypothesis first: which rule or definition decides this one, and what is the first move it forces? Then watch whether the example agrees with you.
Correct: Set the Medium threshold at 50 and the High threshold at 80.
Why: Now one strong signal alone reaches Medium, and any two signals together reach High — which is exactly the aggregation story you want to tell.
A hypothesis you wrote down is falsifiable; a vague sense of how it will go is not. If the example opens somewhere else, that gap is the thing worth chasing.
Worked example
Here is a concrete, defensible starting policy for a demo built on the three recommended stories. Walk the audience through the arithmetic — it demystifies the whole product.
| Predictor | Score if medium/high | Rationale |
|---|---|---|
| New Device | 50 | Strong, non-IP signal about the actual endpoint |
| Geovelocity Anomaly | 50 | Physically impossible, so hard to explain innocently |
| Anonymous Network Detection | 30 | IP-derived, and has legitimate uses like corporate VPNs |
| IP Reputation | 20 | IP-derived and shared; weakest of the four alone |
Set the Medium threshold at 50 and the High threshold at 80.
Why: Now one strong signal alone reaches Medium, and any two signals together reach High — which is exactly the aggregation story you want to tell.
Trace the boring login: no predictor fires, total 0, final level LOW.
Why: Beat 1 of the arc now has a number behind it instead of just a claim.
Trace the attack: New Device (50) plus Geovelocity Anomaly (50) totals 100, above the High threshold of 80.
Why: The audience watches two independent signals combine — this is the single clearest way to show why aggregation beats a tripwire.
Now raise the High threshold to 120 live and re-run the same attack.
Why: Total is still 100, so the result drops to MEDIUM and the flow steps up to MFA instead of denying. That's beat 3, and it takes fifteen seconds.
Discrimination
Sort into buckets
Sort these by Score if medium/high, from memory, without looking back at A worked score sheet. Telling them apart on the spot is the skill; the table is only where the answer happens to be written down.
Concept
Sometimes a single signal should be decisive regardless of arithmetic. That's what an override is for.
Overrides let you assign a specific final risk level regardless of what the overall calculated risk score was. Ping's own example is exactly the useful one: a geovelocity anomaly forcing HIGH no matter what the total says.
In the policy's rules, select Risk Level Override and click Add Rule.
Why: Overrides live alongside the scores rather than replacing them, so normal aggregation still applies to everything else.
Choose the predictor, select the Score level that triggers it, and select the Return level.
Why: Read as: when this predictor hits this level, return this final level — bypassing the thresholds entirely.
Demo value: overrides are how you answer "but what if it's just one really bad signal?" without a slide. You show the rule.
Concept
Beyond the level, a policy can return a recommended action — a machine-readable instruction your flow can branch on directly.
In the policy, under Mitigation, click Add and select the Rule criteria.
Why: Criteria are what the rule watches — a predictor result or a risk characteristic.
Set the Operator and the Value/Level that trigger the rule.
Why: This is the same shape as the override rule, which makes the two easy to teach together.
Select the Returned Action, and add optional Notes.
Why: The action is what your flow reads from result.recommendedAction — actions seen in the Protect connector include APPROVE, DENY, MFA, and BOT_MITIGATION.
Branching on recommendedAction instead of on the level is the more mature integration: the policy owner can change the response without anyone redeploying the flow.
Trap
The config: High threshold set to 200 because "we want to be sure."
Your policy scores four predictors at 50, 50, 30, and 20 — a maximum possible total of 150.
Why: The High level is now mathematically unreachable; no combination of signals can produce it.
On stage, your carefully staged attack returns MEDIUM and the deny branch never fires.
Why: You debug live, and the honest explanation — 'my thresholds were impossible' — is not one you want to give in front of a buyer.
The config: thresholds derived from the score sheet, not from a feeling.
Add up the maximum possible total first, then place High and Medium inside that range.
Why: With a 150 maximum, thresholds of 80 and 50 leave room for both a single-signal Medium and a two-signal High.
Prove each threshold is reachable by running one evaluation per branch before the demo.
Why: Three test runs — low, medium, high — confirm every branch your story needs actually fires.
Pattern
The order matters. Doing these out of sequence is why tuning feels like guesswork.
After deployment the loop continues: Ping's guidance is to run, analyze via the Threat Protection Dashboard, and adjust predictor scores iteratively.
Edge cases
Discussion prompt
Policy tuning recipe works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".
Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.
Answer:
The order matters. Doing these out of sequence is why tuning feels like guesswork.
Commit first
Predict first
A targeted policy scores New Device at 50, Geovelocity Anomaly at 50, and IP Reputation at 20. Medium threshold is 50, High is 80. A sign-on fires New Device and IP Reputation only. What is the final risk level?
Commit to an answer, then rate it — certain, fairly sure, or guessing — and write the rating down before you turn the page.
Correct: MEDIUM — the total is 70, which clears the Medium threshold but not the High threshold
Why: The policy sums the scores of every predictor that returned medium or high: 50 for New Device plus 20 for IP Reputation gives 70. That total is compared to the thresholds — it is at or above Medium (50) but below High (80), so the final level is MEDIUM. Count of predictors never matters; only the summed score does.
The rating matters as much as the answer: confident-and-wrong is the combination that survives revision, because nothing about it feels like it needs revisiting.
Check
Do the arithmetic before you look at the options.
Check your understanding
A targeted policy scores New Device at 50, Geovelocity Anomaly at 50, and IP Reputation at 20. Medium threshold is 50, High is 80. A sign-on fires New Device and IP Reputation only. What is the final risk level?
Answer: A
Why: The policy sums the scores of every predictor that returned medium or high: 50 for New Device plus 20 for IP Reputation gives 70. That total is compared to the thresholds — it is at or above Medium (50) but below High (80), so the final level is MEDIUM. Count of predictors never matters; only the summed score does.
Section
Part 6
Concept
Start here even if you'll eventually demo DaVinci. A curl command that returns a risk level is the most reliable artifact you will build, and it's your fallback if anything visual fails.
Creating an evaluation is a POST to the environment's risk evaluations collection:
POST /v1/environments/{environmentID}/riskEvaluations
Host: api.pingone.com # .eu / .asia / .ca for other regions
Authorization: Bearer $ACCESS_TOKEN
Content-Type: application/jsonConfirm the host against your own tenant's region before scripting — a wrong regional host fails in a way that looks like an auth problem but isn't.
Ranking
Put in order
Put the moves of The request body, field by field into the order they have to happen.
event.ip is the originating IP address, and it is required.event.user.id and event.user.type identify the subject; type is PING_ONE or EXTERNAL.event.targetResource names the application being accessed, by id or name.event.flow.type categorizes the interaction — AUTHENTICATION, REGISTRATION, TRANSACTION and others.event.sdk.signals.data carries the payload from the Signals SDK.201-class response with an evaluation id before reading anything else.Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. This one field alone drives IP Reputation, Anonymous Network Detection, and Geovelocity — which is why it's the easiest thing to vary in a demo.
Worked example
Here is a minimal but realistic body. Every field earns its place; walk the engineers through it once and they'll stop asking whether this is real.
{
"event": {
"ip": "203.0.113.45",
"user": {
"id": "c1f6e0a2-2b4d-4f8a-9e21-7d3c5a9b1e04",
"type": "PING_ONE"
},
"targetResource": {
"id": "9b2a77d1-4c33-4e5f-8a10-2c6f4b8d9e77",
"name": "Demo Customer Portal"
},
"flow": { "type": "AUTHENTICATION" },
"session": { "id": "demo-session-0001" },
"browser": { "userAgent": "Mozilla/5.0 ..." },
"sdk": { "signals": { "data": "<payload from the Signals SDK>" } }
}
}event.ip is the originating IP address, and it is required.
Why: This one field alone drives IP Reputation, Anonymous Network Detection, and Geovelocity — which is why it's the easiest thing to vary in a demo.
event.user.id and event.user.type identify the subject; type is PING_ONE or EXTERNAL.
Why: Use EXTERNAL when the identity lives in your own directory rather than in PingOne — a detail that matters for companies not fully migrated.
event.targetResource names the application being accessed, by id or name.
Why: This is what lets a targeted policy scope itself to specific applications.
event.flow.type categorizes the interaction — AUTHENTICATION, REGISTRATION, TRANSACTION and others.
Why: Flow type is how a targeted policy decides whether it applies at all, so getting it wrong silently selects a different policy.
event.sdk.signals.data carries the payload from the Signals SDK.
Why: Omit it and the SDK-dependent predictors have nothing to work with — they fall back rather than fail loudly, which is the confusing part.
Verify the call by confirming a 201-class response with an evaluation id before reading anything else.
Why: A 403 here is almost always a missing role on the worker app; a 400 is almost always a malformed user id or type.
Estimation
Predict first
The response is what your flow branches on. Three fields carry all the weight.
Commit before you compute: what does Reading the response come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.
Correct: Save the evaluation id from the response.
Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. You need it for the update call, and without the update the models never learn from this event.
Worked example
The response is what your flow branches on. Three fields carry all the weight.
{
"id": "7e1c9a45-3b62-4d08-91ff-5a0e2c7b6d31",
"createdAt": "2026-08-03T17:04:22.118Z",
"result": {
"level": "HIGH",
"type": "VALUE",
"recommendedAction": "DENY"
},
"details": { }
}result.level is LOW, MEDIUM, or HIGH — the aggregated verdict.
Why: This is the field most demos branch on, and the one to read aloud on stage.
result.recommendedAction carries the action a mitigation rule produced.
Why: Branch on this when you can: the policy owner can then change the response without a flow redeploy.
details carries the supporting evidence — geolocation, device info, per-predictor analysis.
Why: This is your 'show your work' field. Expanding it on stage converts a black box into an explainable decision.
Save the evaluation id from the response.
Why: You need it for the update call, and without the update the models never learn from this event.
Concept
A risk evaluation is not finished when you read the level. The flow must tell Protect how the event actually ended.
{
"completionStatus": "SUCCESS"
}The documented values are SUCCESS and FAILED; the DaVinci connector also exposes IN_PROGRESS for multi-step flows.
This is what closes the learning loop. Without it, Protect knows it scored an event but never learns whether the user was genuine — so the behavioral models stop improving.
Say this out loud in the demo. "The system learns from outcomes" is a strong claim, and showing the call that makes it true is much better than asserting it.
Anomaly
Predict first
A student writes this, and it looks reasonable:
The build: you create evaluations and branch on the level. Everything looks fine.
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Protect scores each event but never finds out whether the sign-on succeeded or failed.
The build: every path in the flow ends by updating the evaluation.
Why: Protect scores each event but never finds out whether the sign-on succeeded or failed.
Trap
The build: you create evaluations and branch on the level. Everything looks fine.
You never call the update endpoint with a completion status.
Why: Protect scores each event but never finds out whether the sign-on succeeded or failed.
Weeks later the behavioral predictors haven't improved at all.
Why: The customer concludes the ML claims were marketing, when in fact the integration was incomplete.
The build: every path in the flow ends by updating the evaluation.
On the success branch, update with completionStatus of SUCCESS.
Why: The model learns this context was legitimate for this user, which reduces future false positives.
On the deny or failed-MFA branch, update with FAILED.
Why: Now the negative case is labeled too — a model trained only on successes learns much less.
Concept
Once the API works, DaVinci gives you the thing executives actually respond to: a flow diagram where you can point at the branch.
The connector's stated purpose is to improve user experience, reduce MFA fatigue, lower the probability of unintentional push approvals, and issue challenges or deny access in high-risk situations.
It exposes three capabilities:
| Capability | What it does |
|---|---|
| Create Risk Evaluation | Evaluates risk for a transaction using the configured predictors |
| Update Risk Evaluation | Sends the completion status so the system can learn |
| Send Risk Evaluation Feedback | Submits a category and reason to refine future classification |
Prerequisites are the ones you've already built: a Protect license, a Protect-enabled environment, a worker application, and a risk policy.
Step zero
Discussion prompt
Building the DaVinci flow — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Add the Create Risk Evaluation node after credential collection.
Answer:
Worked example
Five nodes. Build it once, and you can edit it live during beat 3 of the demo arc.
Add the Create Risk Evaluation node after credential collection.
Why: Risk must be evaluated before the access decision, otherwise you're auditing rather than protecting.
Populate its inputs: User ID, User Name, IP address, User Type, and the SDK payload.
Why: User Type is EXTERNAL or PING_ONE — the same distinction as the raw API, because the connector wraps the same endpoint.
Leave Risk Policy ID empty to use the default, or set it to target a specific policy.
Why: With a targeted policy this can stay empty, which is one fewer thing to get wrong on stage.
Branch on the output: Recommended Action first, falling back to Risk Level.
Why: The connector exposes recommended action, risk level, and numeric risk score as branch options; action is the most maintainable.
Route LOW to success, MEDIUM to an MFA node, HIGH to a deny node.
Why: This is Ping's own documented example: prompt for MFA at medium or high, grant access automatically at low.
End every branch with an Update Risk Evaluation node carrying the completion status.
Why: Every branch, including the deny path — the failure signal is as valuable to the model as the success one.
Verify by running the flow once per branch and checking the audit log for matching events.
Why: Three runs, three audit entries: this is the proof that the flow and the service are genuinely talking.
Concept
There's a third capability most demos never mention, and it's the one the fraud-operations person cares about most: telling Protect it got something wrong.
Send Risk Evaluation Feedback takes an evaluation id, a feedback category, and a reason. The documented categories are:
FALSE_HIGH_RISK — the event was flagged but was legitimateFRIENDLY_BOT — automated, but authorized automationNEW_ACCOUNT_FRAUD — fraudulent registrationCOMPROMISED_ACCOUNT — confirmed account takeoverAUTOMATED_ATTACK — confirmed hostile automationShowing this converts the demo from "a scoring engine" into "a system your analysts can teach" — which is the difference between a tool and a platform in a fraud team's mind.
Constraint
Discussion prompt
Run Integration checklist with this step confiscated:event.targetResource matches the application the policy targets.
Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.
Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.
Answer:
event.ip reflects the real originating address, not your load balancer's.event.flow.type matches the flow type your targeted policy scopes to.event.targetResource matches the application the policy targets.Pattern
Before you consider the wiring done, confirm every line.
event.ip reflects the real originating address, not your load balancer's.event.flow.type matches the flow type your targeted policy scopes to.event.targetResource matches the application the policy targets.The middle three are the ones that produce the maddening failure mode: everything returns LOW because your targeted policy never actually matched the event.
Prediction
Predict first
Your targeted policy scopes to flow type TRANSACTION. Your API calls send flow.type of AUTHENTICATION. Every evaluation returns LOW despite deliberately hostile IPs. What is happening?
Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.
Correct: The targeted policy never matches the event, so a different policy — likely the default — is scoring it
Why: Targeted policies apply automatically based on the flow types, applications, and groups configured on them. If the event's flow type is not among the policy's targets, that policy simply does not apply, and the evaluation is scored by whatever policy does — typically the default, which carries different predictors and thresholds than the one you carefully tuned.
Check
This is the failure people spend hours on. See if you can spot it from the symptom.
Check your understanding
Your targeted policy scopes to flow type TRANSACTION. Your API calls send flow.type of AUTHENTICATION. Every evaluation returns LOW despite deliberately hostile IPs. What is happening?
Answer: A
Why: Targeted policies apply automatically based on the flow types, applications, and groups configured on them. If the event's flow type is not among the policy's targets, that policy simply does not apply, and the evaluation is scored by whatever policy does — typically the default, which carries different predictors and thresholds than the one you carefully tuned.
Section
Part 7
Concept
Server-side, Protect sees an IP address and an HTTP request. That's enough for reputation and geography, and nothing else.
The PingOne Signals (Protect) SDK runs on the client and reports what the server cannot see: browser fingerprint, device attributes, and behavioral telemetry — how the user interacts with the app.
Four predictors require it: Adversary-in-the-Middle, Bot Detection, Suspicious Device, and User-Based Risk Behavior. New Device is documented as optional but recommended.
So: if any of those four appear in your story, the SDK is not optional work you can defer. It is the story.
Intuition
Ping's guidance is that the earlier you can initialize the Signals SDK, the more data it can collect to make a risk evaluation.
Behavioral telemetry is a recording, not a snapshot. Initialize on page load and by the time the user clicks Sign In you have several seconds of typing rhythm, mouse movement, and focus changes.
Initialize in the click handler instead and you have a fraction of a second of nothing — technically present, analytically empty.
This is why the SDK script goes in the page head, before your application code, rather than lazily loaded when the form is submitted.
Missing information
Discussion prompt
For the PingFederate Protect Integration Kit, the documented approach is three script references on the sign-on page, loaded in this order:
What do you need to know — or decide — before the first line can be written? List everything the problem has to hand you.
Hint: Anything you would have to invent to get started is a thing the problem must supply.
Answer:
This is the SDK itself; the other two depend on it existing, so order is not cosmetic.
Worked example
For the PingFederate Protect Integration Kit, the documented approach is three script references on the sign-on page, loaded in this order:
<script type="text/javascript" src="signals-sdk-<version>.js"></script>
<script type="text/javascript" src="pingone-protect-device-profiling-implementation.js"></script>
<script type="text/javascript" src="signals.js"></script>Load signals-sdk-<version>.js first.
Why: This is the SDK itself; the other two depend on it existing, so order is not cosmetic.
Then the device-profiling implementation script.
Why: For integration kit versions 1.0.1 or earlier this file is named pingone-protect-device-profiling.js instead.
Then signals.js, which drives collection for the page.
Why: This is the piece that ties the SDK to the specific sign-on template.
Verify the three scripts load before your sign-on form renders.
Why: Late loading is the same failure as late initialization — the SDK exists but has nothing recorded by the time the user submits.
Cost model
Annotate
In Adding the SDK to a browser sign-on page, before reading the notes: mark where the time actually goes. Which line dominates?
pingone-protect-device-profiling.js instead.Estimation
Predict first
With the scripts loaded, initialize with your environment id. In the earlier Risk SDK generation the documented call is initSilent:
Commit before you compute: what does Initializing the browser SDK come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.
Correct: Verify by confirming the SDK payload is non-empty in the request you send to riskEvaluations.
Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. An empty payload is the silent failure here — evaluations still succeed, the SDK predictors just quietly fall back.
Worked example
With the scripts loaded, initialize with your environment id. In the earlier Risk SDK generation the documented call is initSilent:
_pingOneSignals.initSilent({
envId: "<envid>",
deviceAttributesBlackList: []
});Pass envId — the same environment GUID from your worker app setup.
Why: Reusing one GUID across the SDK, the API call, and the console is a useful consistency check when debugging.
Leave deviceAttributesBlackList empty unless privacy review requires exclusions.
Why: Every excluded attribute is one less input the device predictors can use, so exclusions trade detection for privacy deliberately.
Verify by confirming the SDK payload is non-empty in the request you send to riskEvaluations.
Why: An empty payload is the silent failure here — evaluations still succeed, the SDK predictors just quietly fall back.
Blank canvas
Draw it
Draw what Initializing the browser SDK just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.
Step zero
Discussion prompt
The modern JavaScript SDK: starting collection — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: PIProtect.start({ envId }) begins collection.
Answer:
PIProtect.start({ envId }) begins collection.start() runs before the sign-on form is interactive.Worked example
For applications using the Ping SDKs, the package is @forgerock/ping-protect and the class is PIProtect. Start collection as early as you can:
import { PIProtect } from '@forgerock/ping-protect';
try {
PIProtect.start({ envId: '3072206d-c6ce-ch15-m0nd-f87e972c7cc3' });
} catch (err) {
console.error(err);
}PIProtect.start({ envId }) begins collection.
Why: Call it at application startup, not at form submission — see the previous slide on why timing changes what gets collected.
Wrap it in try/catch and actually surface the error.
Why: A swallowed start() failure is indistinguishable at the server from a user who simply had nothing suspicious about them.
Verify by confirming start() runs before the sign-on form is interactive.
Why: If it runs after, the behavioral window is effectively zero even though no error was thrown.
Reverse engineer
Discussion prompt
Work backwards. The example finished here:
Verify by confirming start() runs before the sign-on form is interactive.
What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.
Hint: Every quantity in the result had to enter somewhere. Account for each one.
Answer:
For applications using the Ping SDKs, the package is @forgerock/ping-protect and the class is PIProtect. Start collection as early as you can:
Ranking
Put in order
Put the moves of The modern JavaScript SDK: retrieving the payload into the order they have to happen.
await PIProtect.getData() returns the signals payload.callback.setClientError(err.message).callback.setData(data) and continue the flow.Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. That value is what lands in event.sdk.signals.data on the risk evaluation request.
Worked example
When the flow reaches the evaluation step, retrieve what the SDK has collected and hand it to the callback:
let data;
if (step.getCallbacksOfType('PingOneProtectEvaluationCallback')) {
const callback = step.getCallbackOfType('PingOneProtectEvaluationCallback');
try {
data = await PIProtect.getData();
} catch (err) {
callback.setClientError(err.message);
}
}
callback.setData(data);
FRAuth.next(step);await PIProtect.getData() returns the signals payload.
Why: That value is what lands in event.sdk.signals.data on the risk evaluation request.
Handle the error path with callback.setClientError(err.message).
Why: A client that fails silently produces the empty-payload problem; reporting the error at least makes it diagnosable.
Pass it on with callback.setData(data) and continue the flow.
Why: Forgetting this line is the classic version of the empty-payload bug: collection worked, transport never happened.
Verify by logging the payload length once in a test build before removing the log.
Why: A payload of a few characters means collection never really started, even though no exception was thrown.
Error analysis
Annotate
Walk the callouts on The modern JavaScript SDK: retrieving the payload. Each one is a place this is easy to get subtly wrong.
event.sdk.signals.data on the risk evaluation request.Concept
There is a privacy control worth demoing, because someone in the room will ask about keystroke collection and a password field.
The SDKs provide pauseBehavioralData() and resumeBehavioralData() to pause and resume the capture of behavioral data.
const callback = step.getCallbackOfType('PingOneProtectEvaluationCallback');
const shouldPause = callback.getPauseBehavioralData();
if (shouldPause) {
PIProtect.pauseBehavioralData();
}Note the flow itself can request the pause via getPauseBehavioralData() — so the decision is configurable server-side rather than hard-coded in the client. That's the detail that satisfies a privacy reviewer.
Trap
The symptom: the SDK script is on the page, no console errors, but the device predictors never fire.
The payload is collected but never attached to the evaluation request.
Why: event.sdk.signals.data is absent, so from the server's point of view no SDK exists at all.
Evaluations still return 200 with a LOW level.
Why: Nothing fails loudly — the SDK-dependent predictors just apply their fallback value, which is why this bug survives so long.
The fix: treat the payload as a required field and assert on it.
Log the payload length in the client and the received length on the server, once, during integration.
Why: Two numbers that match prove the whole chain — collection, retrieval, transport — is intact.
Fail your own integration test if event.sdk.signals.data is empty.
Why: You want this to break in CI rather than degrade silently into a demo where nothing ever looks risky.
Concept
If the company runs PingOne Advanced Identity Cloud, the integration is journey nodes rather than a DaVinci flow. The shape is the same, split across three nodes:
| Node | Job |
|---|---|
| PingOne Protect Initialization | Initializes the PingOne Protect Web SDK on the client device |
| PingOne Protect Evaluation | Calculates the risk level for this journey |
| PingOne Protect Result | Updates the risk evaluation configuration with the outcome |
Note how the three nodes map exactly onto the three things you've already learned: initialize the SDK, create the evaluation, update it with the result. Every integration surface is the same three moves in different clothes.
You can validate it the same way too — check the PingOne audit log for Risk Evaluation Created events to confirm the Evaluation node is working.
Comparison
Comparison matrix
From Advanced Identity Cloud: three nodes: refill the Job column from what you know. The rest of the table is as it appeared.
| Node | Job |
|---|---|
| PingOne Protect Initialization | Initializes the PingOne Protect Web SDK on the client device |
| PingOne Protect Evaluation | Calculates the risk level for this journey |
| PingOne Protect Result | Updates the risk evaluation configuration with the outcome |
Section
Part 8
Concept
This is the table nobody writes down and everybody needs. Rehearse each trigger you plan to use, on the network you'll actually be on.
| Predictor | How to trigger it | Reliability on stage |
|---|---|---|
| Anonymous Network Detection | Sign on through Tor or a commercial VPN exit | High if pre-tested; VPN egress IPs change |
| IP Reputation | Use a known-bad IP from a public reputation feed | High — deterministic given the IP |
| Geovelocity Anomaly | Two sign-ons minutes apart from far-apart IPs | High — needs the first sign-on staged in advance |
| New Device | Private window, cleared cookies, or a second machine | Very high — simplest trigger available |
| IP Velocity | Same user, several different IPs in quick succession | Medium — depends on learned thresholds |
| User Velocity | Several users from one IP in quick succession | Medium — depends on learned thresholds |
The last two use dynamic thresholds adjusted per user, which is exactly why they're less reliable to stage: what counts as suspicious is learned, not fixed.
Concept
For an API-path demo there's a trigger that never fails, because it doesn't depend on your network at all.
event.ip is a field you populate in the request body. Change the value, change the geography, change the reputation, change the result.
# beat 1 - the boring login
curl ... -d '{"event":{"ip":"198.51.100.20", ... }}' # office IP -> LOW
# beat 2 - the attack
curl ... -d '{"event":{"ip":"203.0.113.99", ... }}' # hostile IP -> HIGHTwo commands, two levels, zero dependence on conference wifi. Be transparent that you're supplying the IP — an audience respects "I'm simulating the network layer" far more than a demo that mysteriously breaks.
Anomaly
Predict first
A student writes this, and it looks reasonable:
The plan: fire up Tor Browser on stage to trigger Anonymous Network Detection.
It is wrong. Say what breaks — and say it before you turn the page.
Correct: You are now watching a progress bar in front of the people you're selling to.
The plan: API-driven IP variation live, with a recorded Tor run as the backup.
Why: You are now watching a progress bar in front of the people you're selling to.
Trap
The plan: fire up Tor Browser on stage to trigger Anonymous Network Detection.
The venue blocks Tor, or the circuit takes ninety seconds to build.
Why: You are now watching a progress bar in front of the people you're selling to.
You fall back to explaining what would have happened.
Why: The demo's most dramatic moment becomes a description, which is worth almost nothing.
The plan: API-driven IP variation live, with a recorded Tor run as the backup.
Drive beat 2 by supplying a hostile event.ip in the request.
Why: Deterministic, instant, and independent of the venue's network policy.
Keep a short screen recording of a real Tor sign-on to play if someone asks for the end-to-end version.
Why: You answer the harder question without ever putting the venue's network on your critical path.
Two truths and a lie
Sort into buckets
Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.
Concept
After the drama, the evidence. Go to Monitoring → Threat Protection in the admin console.
The Risk totals chart summarizes all risk events analyzed in the selected period across five metrics:
A slider under the Risk summary chart switches between the current day, past week, past month, or past six months — so you can show your demo's spike against a quieter background.
Concept
Beyond the totals, the dashboard carries expandable graphs. Know the names; several of them answer questions before they're asked.
| Graph | The question it answers |
|---|---|
| Risk heat map | Where geographically is risk concentrated? |
| Risk events | How is risk trending over time? |
| High risk models | Which predictors are actually driving our high-risk verdicts? |
| Top 20 high risk users | Who should an analyst look at first? |
| Risky IP | Which sources are repeat offenders? |
| Browser / OS distribution | What does our normal client population look like? |
High risk models is the one to linger on: it shows which predictors earn their keep, and it's the natural bridge into the tuning conversation.
Concept
Above each risk data table there's a search bar with filter checkboxes for User, IP, Country, Target Application, User Agent, OS, and Browser.
Three constraints to know before you type on stage: no wildcards, spaces are significant, and quotation marks are not supported. Left-hand filters apply first and create cascading subsets.
When a User Based Risk Behavior score is Medium or High, click the score to open the Risk Details window.
| Column | Shows |
|---|---|
| Attribute | The transaction category being compared |
| Normal | The typical value for this user |
| Anomaly | The anomalous value on this event |
| Score | The risk level for that attribute |
This window needs the dir:read:user permission — one more reason the Identity Data Admin role was in your prerequisites.
Trade off
Comparison matrix
From Investigating a single event: every row here is a choice with a cost. Fill the Shows column, then say which row you would actually pick and what you give up for it.
| Column | Shows |
|---|---|
| Attribute | The transaction category being compared |
| Normal | The typical value for this user |
| Anomaly | The anomalous value on this event |
| Score | The risk level for that attribute |
Concept
Dashboards aggregate; the audit log records. Someone on the call is responsible for evidence, and this is their slide.
Filter the PingOne audit log for these two event types:
Seeing both, in order, for the sign-on you just performed is the cleanest possible proof that the integration is real and complete.
It's also your debugging tool during the build: no Created event means your flow never called Protect, and a Created with no Updated means you skipped the update call.
Explain it
Discussion prompt
Explain The audit log — proof for the compliance seat to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Dashboards aggregate; the audit log records. Someone on the call is responsible for evidence, and this is their slide.
Concept
If you'd rather not build from zero, Ping publishes example integration packages that combine Terraform with the products, so a whole demo environment is provisioned as code.
| Package | What it combines |
|---|---|
pingone_protect_api-pkg | Terraform, PingOne Protect, and the Signals SDK — threat detection only |
davinci_api-pingone_protect-reg-authn-pkg | Terraform, DaVinci, Protect, and the Signals SDK — registration and authentication |
davinci-oidc_sdk-pingone_protect-reg-authn-pkg | The above plus PingOne SSO and the OIDC SDK — full end-to-end |
Terraform matters here beyond convenience: a demo you can destroy and recreate is one you can rehearse aggressively, and one a customer can take home and run themselves.
Recommended approach: build the API path by hand first so you understand every field, then adopt a package for repeatability.
Analogy
Discussion prompt
Explain Prebuilt example packages by analogy to something with no Identity & Access Management in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
If you'd rather not build from zero, Ping publishes example integration packages that combine Terraform with the products, so a whole demo environment is provisioned as code.
Pattern
The final artifact. Twelve minutes, rehearsed, with a fallback at every risky step.
result.level and recommendedAction aloud; show the branch fire.Minute 7-9 is the one people remember. Everything before it is setup for the moment the buyer realizes they control the dial.
Real world
Discussion prompt
Outside this lesson: where does Building a PingOne Protect Demo for Your Company actually turn up? Name one concrete situation — a job, a piece of software someone ships, a decision somebody has to make — and say which part of Run of show is doing the work in it.
Hint: Vague is the failure mode here. "Engineering" is not a situation; "deciding whether this build is fast enough to ship" is.
Answer:
An end-to-end guide, in applied mode, to building a credible PingOne Protect demo. It starts with what Protect is and is not, then lays out the three-beat demo arc, the licence tiers, and the eight Risk-tier predictors as against the six Protect-tier ones. From there it walks through standing up the environment and the worker app, building a targeted risk policy with scores, thresholds, overrides, and mitigation, wiring it up through the riskEvaluations API and a DaVinci flow, adding the PingOne Signals SDK, triggering each predictor live, and proving the result on the Threat Protection dashboard and in the audit log. The deck includes nine traps, six checks, a full run of show, and two closing slides of cited documentation links.
Elimination
Eliminate the wrong options
Which single demo moment best answers a CX stakeholder's fear that Protect will add friction for legitimate users?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: A
Why: The CX fear is false positives on legitimate users, and the canonical example is a workforce behind a corporate VPN. Adding that range to the allow list and watching the identical sign-on drop from high to low demonstrates the control directly rather than promising it — and it takes about thirty seconds.
Check
Last one. It's about what a demo has to prove, not about a config field.
Check your understanding
Which single demo moment best answers a CX stakeholder's fear that Protect will add friction for legitimate users?
Answer: A
Why: The CX fear is false positives on legitimate users, and the canonical example is a workforce behind a corporate VPN. Adding that range to the allow list and watching the identical sign-on drop from high to low demonstrates the control directly rather than promising it — and it takes about thirty seconds.
Section
Sources
Concept
Every product-behavior claim in this deck traces to a page below. Hand these to the skeptic in the room instead of asking them to trust the deck.
These seven share one base path: docs.pingidentity.com/pingone/threat_protection_using_pingone_protect/
| What it backs up in this deck | Page (append to the base above) |
|---|---|
| Prerequisites, roles, adding the service, licence tiers, ML training periods | p1_protect_getting_started.html |
| Every predictor, fallback values, allow lists, composite and custom predictors | p1_protect_risk_predictors.html |
| Scores, thresholds, overrides, global vs targeted, default policy contents | p1_protect_risk_policies.html |
| The click-by-click policy build, flow types, mitigation rules | p1_protect_adding_risk_policy.html |
| What an evaluation is; completion status SUCCESS / FAILED | p1_protect_risk_evaluations.html |
| Monitoring > Threat Protection, the charts, the filters, Risk Details | p1_protect_dashboard.html |
| Which predictors require the Signals SDK | p1_protect_signals_sdk.html |
The deck's JSON carries all sixteen entries with full URLs in its sources block — that's the copy to paste into an email.
Comparison
Comparison matrix
From Sources: the PingOne Protect product docs: refill the Page (append to the base above) column from what you know. The rest of the table is as it appeared.
| What it backs up in this deck | Page (append to the base above) |
|---|---|
| Prerequisites, roles, adding the service, licence tiers, ML training periods | p1_protect_getting_started.html |
| Every predictor, fallback values, allow lists, composite and custom predictors | p1_protect_risk_predictors.html |
| Scores, thresholds, overrides, global vs targeted, default policy contents | p1_protect_risk_policies.html |
| The click-by-click policy build, flow types, mitigation rules | p1_protect_adding_risk_policy.html |
| What an evaluation is; completion status SUCCESS / FAILED | p1_protect_risk_evaluations.html |
| Monitoring > Threat Protection, the charts, the filters, Risk Details | p1_protect_dashboard.html |
| Which predictors require the Signals SDK | p1_protect_signals_sdk.html |
Concept
The remaining pages live on other hosts, so these are shown in full. Each one was fetched and confirmed to resolve.
| What it backs up in this deck | URL |
|---|---|
| The riskEvaluations endpoint, event fields, result.level and recommendedAction | developer.pingidentity.com/pingone-api/protect/risk-evaluations.html |
| The Protect API reference root — schemas, the PING_ONE_RISK BOM requirement | developer.pingidentity.com/pingone-api/protect/ |
| PIProtect.start, getData, pauseBehavioralData (@forgerock/ping-protect) | docs.pingidentity.com/sdks/latest/sdks/integrations/pingone-protect/03-app.html |
| DaVinci connector: Create / Update / Feedback capabilities and branch options | docs.pingidentity.com/connectors/p1_protect_connector.html |
| Advanced Identity Cloud: Initialization / Evaluation / Result nodes | docs.pingidentity.com/pingoneaic/integrations/pingone-protect.html |
| Terraform-provisioned Protect demo packages | github.com/pingidentity-developers-experience/ping-integration-example-packages |
The two PingFederate integration-kit pages behind the Signals SDK slides have filenames too long to read off a slide. They sit under docs.pingidentity.com/integrations/pingone/ — search the docs for these exact titles:
initSilent call.One honest note to close on: the demo craft here — the three-beat arc, the run of show, the trigger-reliability ratings — is not from Ping. That's judgment layered on top of the documented behavior, and it's labelled as such in the deck's sources block.
Counterexample
Discussion prompt
The remaining pages live on other hosts, so these are shown in full. Each one was fetched and confirmed to resolve.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — What You're Actually Demoing · Designing the Narrative · Standing Up the Environment · Predictors, In Depth · Building the Risk Policy · Wiring It Into a Login. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can build and run a PingOne Protect demo end to end — and, more importantly, explain every number it puts on screen.
The three rules that carry the most weight, if you keep only three:
event.ip yourself.Everything here is sourced from Ping's own documentation, listed in this deck's sources block — so when someone asks "where does that number come from?", you have a link, not an opinion.
Want this taught 1-on-1? Alexander tutors Identity & Access Management — $55/session, free consultation.