One policy, every customer. DefensX now lets partners define a set of rules once in the partner console and deploy it across their entire customer base, then keep all of them aligned from a single place.

Templates live under → and hold the same rules as a customer policy group. Build one, select the customers that should receive it, and deploy. Changes made to the template afterwards can be pushed to every customer on it.

Deploying locks the customer's default policy and replaces any customer-specific changes made there. Custom URL Groups are preserved.

For configuration details, see the Policy Group Templates knowledge base article.

A watermark turns any screenshot or photograph into evidence. When the page carries identifying details about the viewer and the moment it was loaded, whatever leaves the screen points back to the person who captured it, and users know that before they capture it.

Watermarking has been rebuilt around a live preview that renders on a real page, so every change is visible before it reaches users. Configuration now lives at Policies → Watermark and applies to every enabled group; enablement stays per Custom URL Group under Web Filters in the relevant policy group.

Repeat switches between a tiled pattern that covers the whole viewport and a single badge.

Content is either custom text assembled from template variables ({email}, {username}, {email_or_username}, {userid}, {date}, {datetime}) or the user's email address or ID. In text mode a company logo can be uploaded and inserted as a separate row with {logo}.

Appearance covers opacity, angle, size, color, background color, border color, border width, and font.

Layout controls animation: a static watermark holds its place, while a moving one jumps to a new random location on a configurable interval, making it harder to crop out of a screenshot consistently. A single static badge can also be pinned to any of nine positions and shifted from there with the horizontal and vertical space sliders.

For configuration details, see the Watermark knowledge base article.

This feature requires a CORE+ subscription or higher and is available in extension version v4.2.222 / v4.3.222 or later.

Employees paste customer data, source code, and internal documents into AI tools every day. What happens to that content afterward often comes down to a detail nobody at the organization is watching: whether the person was signed in. Google Gemini does not use prompts or responses to train its models while a user is signed in, but a signed-out session carries no such assurance.

DefensX now closes that gap. Under AI Protections, Disable Data Sharing for Model Improvements can be enabled for Google Gemini. Once enabled, users must log in to Gemini before they can use it, so every prompt is submitted under an authenticated session and stays out of model training.

This feature requires a CORE+ subscription or higher and is available in extension version v4.2.222 / v4.3.222 or later.

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.