Consents keep a block page from becoming a dead end. The user accepts the risk, the decision is logged, and work continues. Until now that decision was permanent, staying in effect long after the circumstances that justified it had changed.

DefensX now lets consents expire. Under Policies → Consents, Consent Duration sets how long a consent stays valid, from 1 hour up to 12 months. When the period elapses, the user is asked again the next time the same action is blocked. Never keeps the previous behavior, where consents do not expire.

For configuration details, see the Consents knowledge base article.

This feature is available in extension version v4.2.222 / v4.3.222 or later.

Device code authentication is a legitimate Microsoft flow for devices with limited interfaces, like a smart TV or a printer, that cannot support a standard interactive login: the device displays a short code, and the user enters it in a browser on a separate device to finish signing in. Device code phishing abuses that flow. The user reaches microsoft.com through a lure, but the sign-in itself is a real Microsoft flow, with a real password prompt and real MFA. The code is real too, requested from Microsoft by the attacker for a session the attacker started, so entering it signs the attacker in rather than a device of the user's own. Microsoft's April 2026 research documented campaigns running this at scale.

DefensX now cuts the flow off at the browser. Under Management → Settings → SaaS Restrictions, Device Code Authentication Restriction blocks web-initiated Microsoft device code authentication, which is Microsoft's own recommendation wherever the flow is not required.

Organizations that still need web-based device code sign-in for specific sites can list those domains, with wildcards such as *.example.com supported. Everything else is blocked, so a code arriving from a phishing page has nowhere to be used.

For configuration details, see the SaaS Restrictions knowledge base article.

This feature is available in extension version v4.2.221 / v4.3.221 or later.

Blocking AI assistants outright rarely holds, because people need them to do their work. The exposure is not the tool, it is the account. A user signed in with a personal account is on the same site, using the same interface, but outside the retention, audit, and data handling terms the organization negotiated.

DefensX now enforces which organizations and workspaces can be used. Under Settings → SaaS Restrictions, access can be limited to your own tenants by entering the Allowed Organization IDs for Claude, found on its Settings → Account page, and the Allowed Workspace IDs for ChatGPT Enterprise, found on its Admin Settings page. Users signing in from anywhere else are prevented from doing so, while the service itself stays available.

For configuration details, see the SaaS Restrictions knowledge base article.

The new Windows Agent v2.4.100 introduces the following improvements:

Improved Secure Access Tunnel workflows for better compatibility across different network environments.

Added support for retrieving full computer hostnames, rather than only NetBIOS names.

Improved client identification when multiple clients share the same egress IP address, enabling more accurate rate-limiting.

Added support for GET requests in the DoH (DNS over HTTPS) module, which may be used by newer versions of Firefox.

Fixed an issue where a catch-all DNS NRPT policy received from a network interface could interfere with DNS queries sent from browsers to the DefensX DoH module.

Added support for VMware virtual machines running in NAT mode in environments where the provided DNS proxy is not fully RFC-compliant.

Improved Windows driver HVCI compliance, ensuring better compatibility with Windows Memory Integrity and other virtualization-based security features.

Improved driver-level compatibility when DefensX and other ZTNA solutions are running simultaneously on the same computer.

DefensX now supports refreshing the Autotask field lists on demand. The Sync button on the Tickets tab of the Autotask integration updates the field lists used in the ticket configuration, so issue types and other values newly created in Autotask become available for selection immediately.

A Ticket Source can also be selected when configuring the Autotask ticket integration. Tickets opened by DefensX are then created with the selected source, so they can be identified and filtered by source in Autotask. Tickets created before this release have no source set.

Values that have been disabled in Autotask are no longer listed, and dropdown lists across the Autotask ticket configuration are sorted alphabetically. This keeps the selection limited to values that are currently in use and makes them easier to find in longer lists.

DefensX now helps organizations control which email domains can be used when signing in to websites. Login Guard can require users to sign in with approved company email domains or prevent company email addresses from being used on selected websites.

Company email domains are defined under Email Domains, while Login Guard is enabled and applied through the Credential Policy. This allows organizations to enforce the appropriate sign-in rule for selected website categories or Custom URL Groups.

For configuration details and example scenarios, see the Login Guard knowledge base article.

DefensX PSA ticket integrations (ConnectWise, HaloPSA, and Autotask) now support two-way closure sync, keeping request status in DefensX and ticket status in your PSA aligned without closing the same work in both places. Each direction can be turned on independently, so you decide exactly how the two systems track each other.

When a request is resolved in DefensX, the corresponding ticket can be automatically closed in your PSA. And in the other direction, when a ticket is closed in your PSA, the corresponding request can be automatically resolved in DefensX.

ConnectWise:

HaloPSA:

Autotask:

Both behaviors are managed per integration under the Ticket settings tabs, allowing each PSA connection to follow its own closure rules.

Starting from , DefensX can enforce DNS policies on macOS through a DNS Proxy network extension, without modifying the system's interface DNS settings.

On MDM-managed devices, the DNS Proxy extension permission can be pushed via a configuration profile, and the required permissions are granted silently.

On non-MDM devices, the extension can be enabled manually by the end user. If it is not enabled, the agent continues to operate in the previous mode where interface DNS settings are modified directly. Once permissions are granted, the agent status displays , indicating that the DNS Proxy network extension is active.

The DNS Proxy Network Extension can be disabled at the deployment level or per individual agent, similar to the Kernel Driver setting on Windows. If needed, it can be disabled regardless of whether permissions were granted via MDM or by the end user.

Step-by-step instructions are available for both Manual Deployment and MDM Deployments.

Additionally, the macOS installer is no longer marked as requiring Rosetta, the DefensX Agent now installs natively without the Rosetta compatibility layer.

DefensX now helps protect users from sponsored search ads that may lead to malvertising, impersonation, or malware delivery campaigns. Since paid search results often appear at the top of search pages, attackers may abuse sponsored placements to mimic trusted brands and redirect users to malicious or deceptive websites.

When a user clicks a sponsored result on Google Search or Bing Search, DefensX detects the ad-based navigation and blocks access before the page loads. A clear warning informs the user about the potential risk and encourages them to continue with organic search results instead.

This protection can be managed at the policy level under Adware Blocker / Malvertising Protection, with dedicated controls for Google Search and Bing Search. This allows organizations to apply sponsored search ad protection according to their security requirements and reduce user exposure to threats commonly delivered through paid search advertising.

Support access is now guided by the DefensX Customer Success Agent, powered by Nexi AI, our new in-product assistant built to help users reach the right information faster.

With this update, the previous Create Ticket button in the lower-right corner has been replaced by the Support button in the upper-right corner of the console. When users open the agent and enter a question, it provides AI-assisted guidance based on DefensX Knowledge Base articles and frequently asked questions.

If additional help is needed, users can continue from the same conversation by selecting Submit as a ticket. This keeps the support flow simple and efficient by combining quick self-service answers with a clear path to the DefensX Support team.