Skip to main content

Signals

A signal is a piece of evidence that shifts an identity's risk score. Every authentication event triggers one or more signals. Signals accumulate into a risk score (0–100) that drives enforcement decisions.

Three Types of Signals​

1. Canonical Signals​

Built-in, pre-defined events with fixed names and risk deltas. These map directly to standard authentication events.

Examples: AUTH_LOGIN_FAILED (+0.5), AUTH_MFA_SUCCESS (−25), AUTH_ACCOUNT_LOCKED (+20)

→ Canonical Signals Reference

2. Derived Signals​

Computed by the engine from patterns across multiple events. You don't send these — the engine detects them automatically.

Examples: impossible travel, velocity burst, new device fingerprint, Tor exit node, brute force pattern

→ Derived Signals Reference

3. Custom Mapped Events​

Your application sends custom event names (e.g. okta.login.failed). You map them to canonical signals in the dashboard. The engine then applies the corresponding risk delta.

→ Custom Event Mapping

How Signal Weights Feed the Score​

Each signal carries a weight — a numeric value that represents how strongly it influences the final score. The engine evaluates all active signals and computes a single 0–100 score.

Example A — low risk:

Signal                          Weight
──────────────────────────────────────
AUTH_LOGIN_SUCCESS              +2.0    (login from new country)
AUTH_IMPOSSIBLE_TRAVEL          +15.0   (geo anomaly detected)
AUTH_LOGIN_FAILED ×3            +1.5    (prior failed attempts)

→ computed score: ~18  →  LOW risk  →  ALLOW

Example B — high risk:

Signal                          Weight
──────────────────────────────────────
AUTH_TOR_EXIT_NODE              +35.0   (Tor exit node detected)
FEAT_VELOCITY_BURST             +12.0   (request velocity anomaly)
AUTH_NEW_DEVICE                 +8.0    (unknown device fingerprint)

→ computed score: ~55  →  HIGH risk  →  CHALLENGE_MFA or BLOCK
note

Signal weights are not added up. The engine uses account takeover proof models to compute the final risk score.

Score Decay​

Risk scores are not permanent. They decay over time when no new suspicious signals arrive. A clean user who triggered a false positive returns to low risk automatically within hours or days (configurable per tenant).

Key Design Principle​

Humifortis uses an evidence accumulation model: no single signal blocks a user. Multiple signals must converge before enforcement kicks in. This minimizes false positives while still catching real attacks.

Exception: some high-confidence signals (Tor exit node, known attacker IP from threat intel) can trigger enforcement alone, depending on your playbook configuration.