AuthGuard Request a demo

RBA with AI · risk-based authentication

Every sign-in has context. The response follows it.

The AuthGuard risk engine assesses every sign-in, phone approval and privileged-access request using device, network and location signals. Rules and a decision-tree model decide; an AI layer can ask for more verification. The response is graded, explained and kept in the signed receipt.

Rolling out The risk engine and the AI layer are in final integration on AuthGuard SaaS.

Talk to us about risk See how it works
  • Eleven signals
  • Graded response
  • Shadow mode first
  • Explained reasons
Risk · console sign-inillustrative example
Person
ana@example.com
Score
742 / 1000 · high

Why we ask for your attention

  • A new device for youdevice
  • A hosting provider’s networknetwork
  • Impossible travel: Lisbon → Singapore in 2 hlocation
  1. Allow
  2. Passkey
  3. Phone with code
  4. Second approver
  5. Deny
  6. Deny and lock
Ask for phone approvalrisk summary in the signed receipt
  1. Signals
  2. Score
  3. Policy
  4. Decision

Watch

Context for every sign-in, a reason for every response.

Narrated in English, with English and Portuguese subtitles. Real product screens; people, organisations and amounts are fictitious.

How it works

Signals, model, response.

The assessment runs inside the service on every sign-in, approval and privileged-access request, and is recorded even before it is enforced.

  1. 01 · Signals

    Eleven signals, in the moment

    New device, network and country, anonymous networks (Tor, hosting, VPN), impossible travel, distance between browser and phone, repeated push requests, repeated failures, a compromised password, a dormant account, and requests the person said were not theirs.

  2. 02 · Baselines

    What is normal for each person

    Usual devices, networks and countries, kept as per-organisation digests with no IP addresses. Until there is enough history, novelty signals are informational only.

  3. 03 · Model

    Rules and an integer GBDT

    A decision-tree model gives the same score on any machine. It was trained on synthetic data only, and it can only ask for more verification, never lower what the policy requires.

  4. 04 · Response

    A ladder, not a switch

    Allow, ask for a passkey, ask for phone approval with a code, require a second approver, deny, or deny and lock. The policy decides, rule by rule.

AI layer Rolling out

A second opinion that can only ask for more.

The AI layer uses a specialised language model, fine-tuned from an open encoder, to recognise combinations of signals that are unusual for each person. It runs in its own process next to the service, on CPU, and calls no outside service. On AuthGuard SaaS, that means inside the EU.

Rules and the GBDT decide first. The AI can only add one step: a passkey at an approval, a second approver for privileged access, or ending the session at a continuous check. It never denies, never lowers the level and does not act on the sign-in screen.

The model receives a closed list of numeric values: names, IP addresses and free text never reach it. It was fine-tuned on synthetic data only, not on customer data. When it steps in, the reason is given in plain words: “An unusual combination of signals for you, flagged by the AI model.”

Each organisation can also turn on an hour-of-week baseline (weekday or weekend, hour by hour) that feeds only the AI layer. It is off by default.

Illustrative example

“This isn’t what I’m doing.”

At 11:40 p.m., Ana’s phone receives an approval request to sign in to the console. The card shows why: a new device, a hosting network, a new country. Ana is not signing in anywhere.

She chooses “This isn’t what I’m doing” and confirms. The request is declined, the browser session that made it is ended and, if that session used the password, the password is marked as compromised. The engine records a critical signal.

For security teams

Test, enforce, prove.

Response policy Rolling out

Test before you enforce

  • Start in shadow mode: everything is assessed and recorded, nothing is enforced
  • Replay a policy over the last 1 to 30 days without changing anything
  • Rules by risk level, by signal or by number of signal families
  • Trying usernames locks nobody out: a lock needs signals tied to the person’s secret or session
Sessions Rolling out

Continuous checks

  • A network change in an open session triggers a new assessment, at most every 5 minutes
  • If the assessment requires more than the session holds, the session ends
  • Revocation reaches OpenID Connect applications (back-channel logout) and SSF/CAEP receivers
  • On a lock, privileged-access sessions end too
Evidence and privacy Rolling out

Explained and verifiable

  • Every assessment with its reasons, in Portuguese and English
  • A compact risk summary in signed receipts for approvals, third-party requests and privileged access, verifiable offline
  • Geolocation runs locally: no IP address leaves the installation
  • Per-organisation baselines that never cross organisations

Worth knowing

  • The risk engine and the AI layer are in final integration and arrive on AuthGuard SaaS (Standard profile). The Sovereign profile is not included.
  • The response is enforced at console sign-in, step-up, phone approval, privileged access and sensitive administrative actions. For OpenID Connect, SAML and Microsoft 365 application sign-in, RADIUS and Windows, the assessment is recorded but not enforced yet.
  • SAML and WS-Federation have no single logout: when a session is revoked, those applications keep their session and only the next sign-in is refused.
  • Geolocation uses files the operator supplies and keeps up to date. Without them, the country, travel and anonymous-network signals are not assessed.
  • The AI layer is optional, starts in shadow mode and never replaces the rules or the GBDT.

In the help centre

Pilot

Start in shadow mode.

Turn on assessment, let it record for a few weeks and replay the policy you want against those days. Only then decide what is enforced.

geral@authguard.pt