Skip to main content

Derived Signals

Derived signals are computed by the Humifortis engine by analyzing raw events against entity baselines, behavioral patterns, and contextual enrichment. You do not send these — the engine detects them automatically from the events you submit.

Derived signals fall into two layers:

  • AUTH_ signals — operator-visible, playbook-addressable, directly impact the risk score
  • FEAT_ signals — engine-internal detectors that feed into AUTH_ signals; not exposed in playbook rules

AUTH_ Signals — Operator-Visible​

These signals appear in dashboards, can be referenced in playbook rules, and directly influence enforcement decisions.

SignalWhat it detects
AUTH_IMPOSSIBLE_TRAVELSame user authenticated from two locations that are geographically impossible to reach within the elapsed time
AUTH_NEW_DEVICELogin from a device fingerprint not seen for this entity in the past 30 days
AUTH_ANONYMOUS_NETWORKConnection via Tor exit node, known VPN provider, or anonymizing proxy
AUTH_BRUTE_FORCEMultiple failed logins from the same IP or entity within a short window
AUTH_DEVICE_COUNTRY_MISMATCHDevice geolocation inconsistent with login location
AUTH_ANOMALOUS_HOURSAuthentication outside the entity's established activity window
AUTH_OFF_HOURS_ADMINPrivileged action (password reset, policy change) performed outside business hours
AUTH_ACCOUNT_LOCKEDAccount locked due to repeated authentication failures
CREDENTIAL_STRIPPINGPassword change followed immediately by MFA device removal — high-confidence account takeover pattern
ATO_CONSOLIDATIONEmail change within minutes of login — account consolidation pattern associated with takeover
MFA_FATIGUE_PATTERNRepeated MFA push denials followed by an approval — indicates push fatigue attack

FEAT_ Signals — Internal Detectors​

These are low-level technical detectors used internally by the engine. They are not exposed in dashboards or playbook rules — they feed into AUTH_ signals and are filtered before reaching the policy layer.

SignalPurpose
FEAT_BOT_USER_AGENTSuspicious automation signatures in the user agent
FEAT_VELOCITY_BURSTUnusual request rate from the same IP
FEAT_SESSION_ANOMALYSession duration or concurrency outside baseline
FEAT_IDP_SWITCHIdentity provider changed between consecutive events
FEAT_ANOMALOUS_HOURRaw hour-of-day deviation from entity baseline
FEAT_NO_MFA_AMPLIFIERMFA not used in a context where it was expected
FEAT_MATH_FPU_COLLISIONFPU class inconsistent with declared platform (e.g. ARM FPU on a reported Windows device)

How They Work Together​

Raw events (from your connector or API)
         │
         ▼
  FEAT_ detectors run first
  (noise filtering, baseline checks, device integrity)
         │
         ▼
  AUTH_ signals computed
  (visible, playbook-addressable)
         │
         ▼
  Risk score updated
         │
         ▼
  Playbook evaluated → ALLOW / CHALLENGE_MFA / BLOCK

The separation keeps the policy layer clean: playbook rules only reference AUTH_ signals, which are stable and meaningful. FEAT_ signals handle the messy low-level work internally.

See Also​