Findings so far

What the RBA (risk-based authentication) tests on SAP Customer Data Cloud have shown, in short. Everything here was measured on test sites, with test accounts, from a browser; the detail (dates, tenants, what each run did) is on the Tests page. Values that come from the product documentation are marked (doc); the rest was observed.

How the risk score works

• CDC's risk score is 1 − Google reCAPTCHA v3 score (doc). A clean login from a normal browser scores 0; the dashboard confirms it.
• A "high risk score" rule at threshold 0.8 fires only for traffic Google is almost sure is a bot. For human-looking traffic it never fired. A strict value sits around 0.2.
• The scores of every attempt are visible in the console, Security dashboard, "Login Risk Score" (doc); that chart is the only place where the number itself can be read.

Failed-login counters

• The rule fires on the Nth failure itself, not after it: with a threshold of 3, the third wrong password already gets the rule's answer.
• Wrong-password failures count, even though the API masks them as "invalid login or password".
• Counters with a global scope (network protected identity) ignore the reset interval (doc); the flag they raise expired by itself between about 2.5 and 13 hours later. Counters with account or IP scope honour the interval.
• An IP-scoped counter challenges every identity from that address, including login names that do not exist.

Captcha rules

• The answer code 401020 means "this login needs a captcha token", not "the user sees a box". The screen-set attaches an invisible reCAPTCHA token on every submit; a legitimate user with a flagged account usually passes with no visible challenge.
• The visible "I'm not a robot" box appears when a failed attempt precedes the login by a few seconds. Reproduced on demand, and the effect is server-side: a failure sent from one device makes the box show on another.
• Captcha credentials are per site and are not inherited from the site group. A captcha rule on a site without them is a dead end: 401020 with nothing to solve.

Lockout rules

• The answer is 403120, "account temporarily locked out".
• The lock lasts while the failure counter stays over the threshold, not the configured duration: every attempt re-evaluates the rule, and attempts made during the lock count as failures too. For a literal "lock for N seconds" the reset interval has to be N as well.
• The account does not need to exist to be locked, and an IP-scoped lock blocks every identity from that address.

Account takeover protection (ATO)

• With ATO on, normal logins get a floor of 0.3 in the risk score; with it off they score 0. At a rule threshold of 0.8 that changes nothing.
• ATO reacts to bursts of failures: five failures from one address within about twenty seconds, across different accounts, raised the score over 0.8 and fired the high-risk rule. Failures spread over several minutes still counted.
• It did not react to a new device plus a new network for a known account.
• The raised score is bound to the address that produced the failures, not to the account: the attacked account logged in from another network with no challenge.
• No measurable latency cost on login with ATO on.

Rule configuration, where it bites

• The rule name is not the action. Several rules named "force CAPTCHA" have the action lockout; read the policy, not the name.
• "Specific API keys" and an inclusive IP list silently exclude the site or the tester: a rule that lists only some sites never fires on the others.
• A threshold typed in the console can be saved as 0 (challenge everyone); the stepper applies the value. Re-read the policy after saving.
• Rules live on the site group's parent and apply to every member; a site of its own inside the group is the way to test rules without touching the members.

Akamai in front of CDC (pre-production)

• In pre-production the CDC calls traverse Akamai; in production they do not. The difference is visible in the DNS route and in the cookies the CDC responses set.
• With Akamai in the path, CDC records the Akamai edge as the client IP; the real address only survives in a secondary field. Whether the IP-scoped rules use one or the other is undocumented and still to be shown.
• Switching the Akamai Account Protector integration on in CDC gave normal logins a fixed high risk score, also on a sibling site where Akamai is not in the path. Raised with the vendor; not a measurement of Akamai's own scoring.
• Headless browsers are cut by Akamai on those hosts; the tests need a real browser.