Risk-Based & Adaptive Authentication
One-line relationship: C8 — the compensating control for the entire diagnosis this portal opens with. The browser has no hardware root of trust; adaptive authentication is how the web offsets that gap dynamically instead of trying to close it once at login.
What it is
Rather than applying one fixed authentication bar to every action, a risk-based system varies the challenge based on real-time signal: a login from a recognized device, in the usual location, doing a routine action, sails through; the same login from a new device, in an unusual country, attempting a large payment, gets challenged with a stronger factor before proceeding. Step-up authentication is the mechanism — escalating mid-session to a stronger factor (a fresh passkey ceremony, an OTP) only when the risk score crosses a threshold, rather than demanding maximum friction on every action regardless of actual risk.
Continuous authentication extends the same idea through the session rather than just at its start — re-evaluating trust as behavioral biometrics and other signals accumulate, not only at the login moment.
Try it — the risk decision, live
⚠ Step-up required (SCA)
No TRA exemption requested — SCA is required for this payment by default.
The lesson: PSD2 defaults to requiring Strong Customer Authentication on every payment — the TRA exemption is opt-in per transaction, and only holds if the real-time risk score and the amount both clear the issuer's bar. A single hard signal (a RAT/malware indicator) vetoes the exemption outright, regardless of how low the amount is. This is the compensating control for the web's missing hardware root of trust: where mobile leans on the enclave key, the web leans on this risk decision firing correctly, every time.
The PSD2 angle: TRA as the regulatory expression of this idea
PSD2’s Transaction Risk Analysis (TRA) exemption is risk-based authentication written into regulation: it explicitly permits skipping Strong Customer Authentication for payments where the payment service provider’s real-time risk analysis clears the transaction as low-risk, below an amount threshold, and within the PSP’s regulatory fraud-rate limits. It’s the clearest case in this entire portal of “risk decisioning isn’t a nice-to-have, it’s load-bearing under the actual regulation” — a good risk engine measurably reduces customer friction under the same legal requirement a worse one has to satisfy with blanket step-up.
What to take to the client
This is the layer that makes the rest of the stack livable. Perfect authentication at every step, on every action, is both unnecessary and bad UX; risk-based authentication is what lets a bank apply passkeys and DPoP’s full strength exactly where risk warrants it, and skip the friction everywhere else — which is precisely what the TRA exemption rewards when the risk engine backing it is good enough to trust.