Policy Configuration
Policies control how Humifortis scores risk and triggers adaptive authentication actions. The system evaluates every login event in real time, computes a 0–100 risk score, and enforces the configured playbook rule (Allow / Require MFA / Block).
Enforcement is always proportional to current risk. A user on a known device at a normal hour gets a frictionless Allow. The same user appearing from a new country at 2 AM via a Tor exit node gets blocked — automatically, without manual intervention.
Policy Components
1. Global Sensitivity
A master multiplier applied uniformly to every risk signal before scoring. This does not change individual signal weights; it scales the entire engine proportionally.
| Level | Multiplier | Posture | Recommended for |
|---|---|---|---|
| Low | ×0.7 | Permissive | Low-risk environments, initial rollout |
| Medium | ×1.0 | Balanced | Most production deployments |
| High | ×1.3 | Aggressive | Regulated industries |
| Very High | ×1.6 | Maximum | Zero-trust / active incident response |
Changes take effect on the next authentication event — no restart required.
2. Risk Thresholds
Define the score boundaries between risk levels. Enforcement actions are triggered when a score crosses a threshold.
| Level | Default Range | Typical enforcement |
|---|---|---|
| Minimal | 0–20 | Allow |
| Low | 20–40 | Allow with monitoring |
| Medium | 40–60 | Allow or soft MFA challenge |
| High | 60–80 | Require MFA |
| Critical | 80–100 | Block or lock account |
Configure exact boundaries in Policies → Thresholds.
3. Signal Rules
Custom signal weight overrides. Each signal has a base deltaRisk value. Rules let you amplify or suppress specific signals without touching the engine config.
Configured in Policies → Signal Rules.
4. Derived Signals
Engine-computed signals that combine base events with temporal patterns, velocity analysis, and contextual enrichment. These are the core of the adaptive authentication engine.
Key signals to know:
| Signal | Type | ΔRisk | What it detects |
|---|---|---|---|
AUTH_BRUTE_FORCE | velocity | +15 | 5+ failed logins in 60s |
CREDENTIAL_STRIPPING | sequence | +55 | MFA deleted after credential update — near-deterministic ATO |
ATO_CONSOLIDATION | sequence | +40 | Email changed within 5 min of login — account takeover |
MFA_FATIGUE_PATTERN | velocity | +20 | Push denial storm |
AUTH_DEVICE_COUNTRY_MISMATCH | sequence | +15 | Known device from new country |
BROWSER_TOKEN_TRUSTED | sequence | −20 | Recognised device trust token (reduces risk) |
5. Enforcement Mode
Controls whether playbook actions are actually applied to users.
| Mode | Effect |
|---|---|
| Enforce | Playbook actions fully applied (block, MFA, lock) |
| Dry-Run | Risk scores computed — no action taken on users. Use for onboarding. |
| Shadow | Risk + webhooks fire for SOC visibility — users never blocked. |
Dry-Run and Shadow modes do NOT protect users. Set to Enforce in production.
Playbook Rules
The Playbook is the enforcement logic on top of Policy. Each rule maps a risk level or derived signal to an action.
- name: "block critical risk"
priority: 100
risk_levels: ["CRITICAL"]
actions: ["DENY"]
- name: "MFA for ATO consolidation signal"
priority: 90
derived_signals: ["ATO_CONSOLIDATION", "CREDENTIAL_STRIPPING"]
actions: ["REQUIRE_MFA"]
- name: "bypass trusted device"
priority: 80
derived_signals: ["BROWSER_TOKEN_TRUSTED"]
actions: ["ALLOW"]
Rules are evaluated in descending priority order — first match wins. Changes hot-reload immediately — no server restart required.
Keycloak Connector Integration
The Keycloak connector calls POST /evaluate on every login event and receives the playbook decision:
ALLOW→ login proceeds normallyCHALLENGE_MFA→ Keycloak prompts the configured MFA methodBLOCK/LOCK_ACCOUNT→ Keycloak shows the configured error page
Humifortis decides whether to challenge; Keycloak decides how.
Best Practices
Start in Dry-Run, then switch to Enforce. Deploy in Dry-Run for 1–2 weeks. Review the risk score distribution in the Dashboard and Rule Telemetry. Switch to Enforce once you're confident in the baseline.
Tune thresholds for your user base. A security-sensitive environment (banking, healthcare) should use High or Very High sensitivity. A developer tools product may start with Low.
Add signal weight overrides sparingly. The defaults are calibrated for most environments. Override individual signals only when you have evidence that the default weights are causing too many false positives or false negatives.
See Also
- Playbook Engine — full rule reference and available actions
- Signals Overview — what signals are and how they accumulate
- Self-Hosted — how to apply policy configuration in production