Defender 6.0.1 introduces full Dynamic Fingerprint v2 (FPv2) support and Authenticity Challenge policies, which provide WebAuthn-based human verification. This release also includes security hardening for script sandboxing, sensitive data masking corrections, and Mitigator stability improvements.
New features
Authenticity Challenge policies
Authenticity Challenge policies address cases where legitimate users are misclassified as bots. When a Challenge mitigation policy is triggered, Defender redirects the user to a WebAuthn biometric verification flow rather than blocking them outright. Supported authenticators include device biometrics such as fingerprint readers and Face ID.
Authenticity Challenge policies include the following capabilities.
- WebAuthn-based biometric authentication for human verification
- JWT token validation and secure cookie management
- Challenge action support in mitigation policies
- Configurable Helm values for identity provider integration
The following limitations apply to Authenticity Challenge policies in this release.
- Supports GET requests only.
- Requires HTTPS.
- No fallback is available for users whose devices do not support biometric authentication.
Related issues: DEF-2013, DEF-2030, DEF-2014.
Dynamic Fingerprint v2 (FPv2)
FPv2 enables custom fingerprint algorithms that can be deployed and updated at runtime without restarting Defender. Algorithms execute in a sandboxed environment, and an integrated caching layer supports efficient fingerprint lookups and policy evaluation.
FPv2 includes the following capabilities.
- Runtime computation of dynamic fingerprints via custom algorithms
- Policy-driven configuration for fingerprint matching criteria and actions
- Dynamic clearing of FPv2 fingerprints and associated policies
- Sensor-level support for computing and forwarding dynamic fingerprint data
- FPv2 data inclusion in mitigation data streams, enabling downstream analytics and policy enforcement
- Prometheus metrics for monitoring FPv2 computation performance, including calculation success and failure rates and latency
Related issues: DEF-1887, DEF-1888, DEF-1890, DEF-1891, DEF-1892, DEF-1893, DEF-1894, DEF-1895, DEF-1896, DEF-1897, DEF-2024.
Relaxed rule configuration
Connector rule configuration validation is now more lenient, reducing deployment failures when optional or partial rule fields are absent.
Related issue: DEF-2020.
Latency statistics in the sensor-connector
The sensor-connector now reports latency metrics for request processing, providing visibility into performance bottlenecks in the data pipeline.
Related issue: DEF-2005.
Fixed issues
Lua script sandbox security enforcement
The Lua script sandbox now enforces restrictions that prevent filesystem access and block remote code execution. Previously, sandbox boundaries were not fully enforced, creating a potential security exposure.
Related issue: DEF-1992.
Lua script loading errors on dynamic fingerprint updates
Lua scripts now load correctly when dynamic fingerprint configurations are updated at runtime. Previously, script loading errors occurred during dynamic fingerprint updates.
Related issue: DEF-2022.
Response cookies scanned for sensitive data
The Sensitive Data Protection engine now scans response cookies for sensitive data. Previously, response cookies were not included in sensitive data detection.
Related issue: DEF-1933.
20-digit ICCID masking
The Sensitive Data Protection engine now correctly recognizes and masks 20-digit telecom ICCID values using Format Preserving Encryption when Luhn check validation is enabled. Previously, 20-digit ICCID values were not recognized by the Luhn validation logic and were not masked.
Related issue: DEF-1991.
Sensitive data masking in response headers
Masked response headers are now correctly substituted before being forwarded to downstream data topics. Previously, original unmasked response headers were forwarded despite Sensitive Data Protection masking being configured.
Related issue: DEF-1944.
Sensitive Data Protection statistics counters
Sensitive Data Protection statistics counters now correctly report zero activity when masking or transform configuration is disabled. Previously, disabling the configuration caused incorrect metric values to be reported.
Related issue: DEF-1941.