Turn signals into a decision
Watch device recognition, alert history, velocity and a simulated impossible-travel flag combine into one explainable risk score — and one decision.
Enrol TOTP on your account page first. The medium band asks for a fresh second-factor proof, and the risk engine will not wave a medium-risk action through when there is no factor to check — with nothing enrolled you get step_up_unavailable, which is a wall, not a lesson.
- 1
On the Risk lab, run the live assessment and read the reasons list.
The score is never a black box: every contributing signal (device recognition, alert history, sign-in velocity, step-up freshness) names itself and its exact weight in the reasons list.
- 2
Try the protected action with everything quiet — with a low score it goes straight through.
A low band (score < 30) decides allow — the same request the engine will refuse below, just with none of its risk signals lit up. "Quiet" is a real precondition, not a figure of speech: recent activity counts, and revoking a device in P30 alone adds +40, which is already the medium band. Read your own score first; if it is not low yet, the signals decay within 24h.
- 3
Flip the impossible-travel toggle on and try again — watch it get refused.
This one signal is an HONEST SIMULATION (there’s no real IP-geolocation here) standing in for a geo-IP mismatch since your last sign-in — but the block, and the ITDR alert it raises, are both real.
- 4
Turn the toggle back off, get asked to step up, then re-prove TOTP and retry.
A medium band demands a fresh second-factor proof — the exact stepUpState gate every other sensitive action in the Lab already uses — and a fresh step-up is the strongest mitigator the score has.
Learn the theory
🩻 X-ray — what actually happened
Your own insert-only audit trail — the real server events, sanitized (never a secret), each linked to the lesson that explains it.